Guest
Welcome login
Share/Save
Share/Save
TIBCOmmunity > Products > ActiveMatrix SOA > BusinessWorks > Conversations
Home   Members Communities
Conversations () Resources () Blogs ()

BusinessWorks

Up to Conversations in BusinessWorks

This Question is Answered

1 "correct" answer available (4 pts) 1 "helpful" answer available (2 pts)

HTTP Authentication Issue

Created on: Mar 24, 2009 9:05 AM

Hi,

 

I am experimenting with HTTP authentication and have a problem which is driving me nuts. Using an HTTP Receiver, I have "HTTP Authentication" enabled. As I understand it when this is enabled it authenticates to the valid users in a BW administration domain. What's driving me nuts is that when deployed in my local development environment it works fine, but when I deploy it to our test environment it does not work. I've tried every variation on the HTTP Connection configuration that I can think of. The only major difference that I can see between the 2 environment is that in my development environment everything (deployed app, administrator, etc.) is on one server but in the test environment, the administrator is on a separate server. The only error that I'm getting in my deployed application

is

 

"Authentication attempt [user=testuser, deployment=MyApplication, authentication_succeeded=false]"

 

One idea was to deploy the application to the server where the BW administrator was running, but can't deploy apps to the server where the BW administrator is installed.

 

Any ideas?

 

Regards,
Ed

Click to view Carlo Milono's profile Aficionado 327 posts since
Apr 29, 2008
1. Mar 24, 2009 3:06 PM in response to: Ed Murphy
Re: HTTP Authentication Issue

The way this works is that when you deploy a BW Project to a bwengine, it is part of a specific domain that is conditioned by the "AuthenticationDomain.properties" file for that domain.

 

If ID/PW (e.g., testuser/secret) worked on DomainA, it will work only if testuser/secret is also on DomainB when you deploy to DomainB. Another issue is whether or not you have LDAP and how your domain is configured (Database vs. File).

 

Have a look at the Administrator's audit.log, you should be able to see BW making access if you have an RV-based domain.

Click to view Carlo Milono's profile Aficionado 327 posts since
Apr 29, 2008
3. Mar 25, 2009 1:13 PM in response to: Ed Murphy
Re: HTTP Authentication Issue

Yes, the user must be defined in the domain. If you are using Designer, you can copy the AuthorizationDomain.properties file from the specific domain (TRA Directory) to the <version> directory of TRA; that way you can test HTTP Basic Authentication and WSSE Username Token Profile scenarios in Designer without having to deploy. yes, the user must be defined in that domain.

 

Here is how this works under the covers:

A BW Project contains a service that requires Basic Authentication. The engine looks for the above mentioned file and reads it. If the domain is configured with a Database the bwengine gets the JDBC information, if it is configured for a File, it gets a Repo URL. It will access the source of authentication data, and if it finds the ID, it fetches the password and does the comparison, if it doesn't find the ID, it looks to see if LDAP is configured and then contacts LDAP directly. So, in the case where you have an LDAP-enabled domain and the AD/AU information is in a DBMS, BW completely bypasses the TIBCO Administrator - contacting the DBMS directly and (if necessary) contacting the LDAP. The LDAP information is in the AD tables/file, not in the AuthorizationDomain.properties. In all cases, the result of the Basic Authentication is in the log of the bwengine, not in TIBCO Administrator.

 

That said, IF you have an RV-based/File-based domain, you will see the bwengine contacting TIBCO Administrator directly and the string in 'audit.log' would look like:

 

"<date/time> <other stuff> User admin requested authentication using TIBCO-repository-Server and the operation was successful"

This is the bwengine authenticating itself to TIBCO Administrator and does NOT reflect the success/failure of the HTTP Basic Authentication attempt.

 

Re-reading your original post, it makes me wonder if your AuthorizationDomain.properties is actually set up for 'localhost'?



More Like This

  • Retrieving data ...