Another common question on the internal mailing list:
Why do we need an OID authenticator when I have the OAM Asserter enabled? The user has already been authenticated when the request gets to WebLogic.
The short answer is that all an Identity Asserter does is says "the request is authenticated and the username is Chris". WebLogic then needs to know how to find "Chris" and to do that it needs an Authenticator.
The longer answer is available on the net already... it's just a matter of finding it.
The old O'Reilly WebLogic book says
Identity Assertion Providers help secure access to the entry points of a WebLogic deployment. Instead of using usernames and passwords, an external client may use tokens to establish trust with a WebLogic Server. The Identity Assertion Provider verifies a token and, if successful, maps it to a valid WebLogic user. Once the token is mapped to a valid user, an Authentication Provider can then generate the principals for the user. This mechanism is called perimeter authentication, so you can consider an Identity Assertion Provider a special type of Authentication Provider. The key point here is that an external agent is responsible for authenticating the user, and then for conveying the user data to WebLogic.
Robert's Professional WebLogic Server book says
This security provider maps an outside authentication token to a username. This allows for functions like perimeter authentication. The identity asserter provides an implementation of a JAAS CallbackHandler. The default identity asserter supports WebLogic Server security tokens, X.509 certificates, CSIv2, and WS-Security password digest.
Without an Authenticator that can find the user there's no way for WebLogic to create the Subject and Principals.
I wasn't going to include this, but there is a little fine print: Identity Asserters can assert the identity without an Authenticator. These are pretty rare so let's leave that for a different post.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.