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.