Teach an Old Dog New Tricks - SAML Name Mappers

A few weeks ago, I said that I was sure that there was some way to get custom attributes passed in and out of SAML Assertions for the purpose of Federated Authorization. Well, at that time I was under the impression that this would require the creation of custom identity asserter that would some how clevery extend the OOTB SAML Identity Asserter. This still seems doable, but it felt pretty invasive...inelegant...ok, let's be honest, a hack. But, once again the core security team has come through, even if I didn't know it at the time :)

The key is the weblogic.security.providers.saml package. WebLogic Server for some time has had the concept of NameMappers. These are used by things like the DefaultIdentityAsserter to convert X.509 Subjects to username. Using the OOTB implementation of this interface, you can just choose and element from the DN - like email address. By implementing your own, you can get full access to the X.509 certificate and use things like SubjectAlternateName. The SAMLProviders have taken the NameMapper concept to whole new level.

In the weblogic.security.saml.providers package there are 4 name mappers. The SAMLCredentialNameMapper is used by the CredentialMapper to convert the current Subject to a SAML NameMapperInfo. A SAMLNameMapperInfo is really just a container for the username and optionally their groups. There is a corresponding name mapper for the SAML IdentityAsserter that converts the information found in the SAMLAssertion to users and groups. So, 2 of the 4 name mappers are really "meat and potatoes" NameMapper - one used in-bound (SAMLIdentityAssertionNameMapper) and one used out-bound (SAMLCrdentialNameMapper).

The remaining two NameMappers are the juicy ones. These two - the SAMLCredentialAttributeMapper and the SAMLIdentityAssertionAttributeMapper can be used to handle the attributes of the SAMLAssertion. As people will recall, this is the key to the Federated Authorization with OSB - the ability to produce and consume attributes for the purposes of authorization.

Looking at the SAMLIdentityAssertionAttributeMapper, there is just one method - mapAttributeInfo.
The interface provides full access the the attributes in the SAML Attribute Statements and expects that an implementation will map the AttributeStatements into Principals and add those back by placing them in a collection in the ContextElementDictionary.SAML_ATTRIBUTE_PRINCIPALS name in the ContextHandler. If the principals that are added implement the WLSGroup interface - the simplest is of course the WLSGroupImpl - then these principals will be picked-up as groups, and can be used very easily in either role or authorization policy.

Once again, the SSPI comes through...making it relatively simple to solve a rather complicated problem...I just wasn't sure how ;)