I noticed that some picketlink classes expect user roles as values to an attribute named "roles" but PicketLinkSTS does not return attributes.
1- It took me a few lines of code to get PicketLinkSTS to return the attribute values under JBoss. Is this something that is meant to be supported or done by PicketLinkSTS or am I taking the wrong approach?
2- At first glance, it appeared that SAML2STSLoginModule and/or SAML2LoginModule would extract the roles from the attribute and insert them as standard JAAS principals but this did not happen and upon closer inspection, I found that they require the SamlCredential to have been set in the JAAS options as the password and none of the login modules I know of do that. Any advice on this?
1- The STS *does* return attributes if the original WS-Trust request
contains a Claims section and the respective ClaimsProcessor has been implemented to
parse the Claims and obtain the attributes. Now, we can change the SAML token provider
to use something like an AttributeProvider. Such provider would be configured as one of
the SAML20TokenProvider options and would be used to include attributes in the
generated assertions, irrespective of whether a Claims section has been specified
in the request or not. I think we should do this as the whole Claims thing is often
a source for confusion and complexity.
<TokenProvider ProviderClass="org.picketlink.identity.federation.core.wstrust.plugins.saml.SAML20TokenProvider" TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0" TokenElement="Assertion" TokenElementNS="urn:oasis:names:tc:SAML:2.0:assertion"> <Property Key="AttributeProvider" Value="com.mycompany.MyAttProvider"/> </TokenProvider>
The class com.mycompany.MyAttProvider would be responsible for retrieving and returning the
attributes that can applied to the assertion principal.
2- The SAML2STSLoginModule does extract the roles from the assertion in the getRoleSets methods
and those roles will ultimately end in the JAAS subject. This module is meant to be used in
scenarios in which a token has been obtained by the client and supplied to JBAS as part of an
EJB invocation. In this case, once the invocation reaches the container, the assertion is extracted
from the invocation and then set in the callback handler before the login process takes place.
Anil, I noticed something we need to fix: STSIssuingLoginModule and STSValidatingLoginModule
can be used to issue and validate an assertion via JAAS. The problem with these modules is that
they don't seem to extract roles from assertions and they share the issued assertion using a
different key than the one used by SAML2STSLoginModule. We need to agree on a common key to be
used by all modules to store security tokens - I think password is fine.
The STS is supposed to issue tokens alone. We can bring in the concepts of attributes to the STS as a value added feature. It has to be done via pluggable providers.