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
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.
Hi Carlos,
Thank you for your input. To address the points in your reply:
The user that I'm using is defined the test domain so that's not the issue. It is technically a different username from the one I'm using in my local development environment, but what I understand from the documentation is that the only requirement is that the user be define in the domain, correct?
The domain authentication does not use LDAP.
What difference would the domain being configured database vs. file make?
Regards,
Ed
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'?
Hi Carlos,
Thanks for the information (especially about what happens under the hood.)
Regarding your last note about whether the AP.properties is set up for "localhost", which particular setting would indicate this? I do not see any references to "localhost" in the AD.properties file on the server where my application is deployed.
However, using your explanation as a guide I beleive I have found the issue. Apparently the bwengine is not able to find the AuthorizationDomain.properties guide. A "file not found" error is being thrown in the administration logs when I attempt to login to my http connection. (This isn' surprising as the administrators have been moving some things around and I think this is simply an oversight.) I'll update this conversation with a follow up regarding whether this is the issue or not.
Regards,
Ed
Hi,
Yep. That was it. The bwengine simply could not find the AuthorizationDomain.properties file. Once I pointed it to the correct file, it works like a charm. Thanks for assistance!
Regards,
Ed
