I've been looking at a way to transform a claim attached to the SAMLv2 token request in a attribute statement in the issued token. My first attempt was to create an implementation of the SAML20TokenAttributeProvider, but from the getAttributeStatement() I don't find a way to access the WSTrustRequestContext that would allow me to access the request claims.
Then I've noticed that the STS can be configured to use arbitrary claim processors (via the ClaimsProcessor interface and PicketLinkSTSConfiguration, although I've not found the exact documentation on how to do so). The configured claims processors are then invoked by the StandardRequestHandler which allows them to fill the request context claimed attributes map.
Unfortunately, the map is finally processed only by the SAML20TokenProvider which can't be configured in order to transform those claimed attributes into attributes statements. Even worse, if any claimed statement is found it is transformed using the
StatementUtil.createAttributeStatement() method, which only recognizes a bunch of attributes and throws an exception if any unknown claimed attributed is found.
Am I missing something here? Isn't it possible to define custom attribute statements starting from claims? Of course I could create a new token provider, but the SAML20TokenProvider works just fine for me.
Well, while trying to do some tests, I've discovered that what is done on the server is actually irrelevant. As the STSClient strips the claims out of the request when it sent to the server. In fact, the WSTrustRequestWriter which is used to serialize the request context, just ignores them
Are claims not supported then?
PL2 work is currently being undertaken in the trunk.http://anonsvn.jboss.org/repos/picketlink/federation/trunk/
So if you have suggestions/bugs/patches, now is the time.
Each of our token providers are supposed to do one thing and one thing well. Any enhancements or customizations can be done with extended token providers (that need to be written). We do not want to carry fat chicken around as token providers.