The reality though is that even when the OBSSO cookie is the configured token for invoking the identity asserter, the asserter itself is simply asserting the value of the OAM_REMOTE_USER header. So, what about all the configuration for the connection to the access gate? The access gate connection only comes into play in an OAM/OWSM integration scenario where there is no webgate on a web server in front of WLS. If you are using the identity asserter to propagate an identity to an OAM protected web app then you don’t even need to fill in all that info.
If you had the wrong impression, don’t feel too bad. It is an easy and common mistake to make. The documentation touches on this here as step 2 is about establishing trust with WLS, but glosses over it in its description (10.2.2.2) of how the identity asserter works, which is why I thought this blog post was necessary.
So, given that the OAM identity asserter is asserting an identity contained in a clear text header that is inserted into the request at the web server, it is vitally important that measures are taken to ensure that all requests to OAM protected WLS resources come through the OAM webgate enabled web server.
As Chris mentioned in his post a few weeks ago this can be done by:
- Taking network security measures.
- Two-way SSL.
- Utilizing the WLS connection filter to lock down what IP addresses WLS will service requests from.
Posts
Hi,
ReplyDeleteI've been researching something that I'm seeing in a configuration that has the 10.1.4.3 ID Asserter and OAM Authenticator in a WL realm, and found your blog post above. In my case, I have an Apache proxy proxying in front of the WebLogic server, and in OAM I have an application domain for the Apache, and for the Weblogic. I have basically no ATN policies in the Weblogic application domain.
The problem I'm seeing is that on this one configuration, the OAM server is invoking the LDAPNoPasswordValidationScheme to authenticate the already-authenticated (via the Apache webgate) user (I checked and the LDAPNoPasswordValidationScheme is pointed to the User Identity Store 1 (i.e., the embedded LDAP) by default, so the authentication on the WL domain is failing. This is happening only in one test environment, and I can't figure out why. Shouldn't the ID Asserter and/or OAM Authenticator authenticate the user directly with the OAM server, w/o regard to any authentication scheme?
Any ideas?
Jim,
ReplyDeleteIf you have WLS behind Apache and there is a webgate on Apache, then what you want to do from a WLS perspective is to use the OAM identity asserter with an LDAP authenticator and not use the OAM authenticator.
In such a setup the OAM identity asserter will assert the user identity based on the OAM_REMOTE_USER header and then the standard LDAP authenticator will search LDAP to verify that the user exists and to build the JAAS principal based on the user's groups.
There are very few use cases where you actually want to use the OAM authenticator itself.
Good luck,
Brian
Brian,
ReplyDeleteWe have the setup you descibed, i.e. WebGate in front of WLS, identity propagated via OAM_REMOTE_USER and asserted via OAM Identity Asserter. We have OAM 11.1.1.5, WLS 11.1.1.5.
However, we found that the OAM Identity Asserter does not work if the Access Server connectivity details are omitted. It does look at though there must be some sort of obSSOCookie validation happening.
Do you have some thoughts on this please?
Hi, I am also using OAM and OVD in a project. I need to retrieve some user details from LDAP server after authentication. How can I retrieve user details programatically?
ReplyDeleteAny ideas?
Francis
Francis, you can either use straight JNDI or the User/Role api. Look here: http://fusionsecurity.blogspot.com/2011/08/couple-of-things-you-need-to-know-about.html
ReplyDeleteAndre.
Thanks Andre.
ReplyDelete