How to put an authentication statement in a SAML 2.0 Token issued by picketlink STS ?

[dcarniel]

Hi,

I'm working on building an STS for strong authentication solution at my company, so far I've managed to do everything I needed, but now I face a problem to which I don't seem to find a good answer.

The goal is to have an "AuthenticationStatement" issued in my SAML 2.0 token as this is requested by the receiving application. Though looking into the code it does not seem possible to do that by simply extending the standard SAML20TokenProvider; that class provides means to generate "AttributeStatement" entries via the "claims" map of the context, but I haven't found a similar mechanism to produce an AuthenticationStatement.

I know I could copy the entire content of the issue method from the SAML20TokenProvider and make changes in there, but that sounds like a bad practice altogether.

If anyone already had the issue I'd be happy to here from them, otherwise I'll have to work out the code a bit and propose a patch for a further release.

Thanks in advance for your help.

[anil.saldhana]

You are free to extend the token provider to add the auth statement.

[dcarniel]

Hi,

I actually started on that path as a side-track, though it appears that the AuthnStatementType actually generates the follow type of element:

                  <saml:AuthnStatement AuthnInstant="2012-02-21T15:03:36.236Z">

                     <saml:AuthnContext>

                        <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:cm:bearer</saml:AuthnContextClassRef>

                     </saml:AuthnContext>

                  </saml:AuthnStatement>

Whereas the example I was given as a valid element is:

      <saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant="2012-02-14T15:53:38.929Z">

        <saml:Subject>

          <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">jQs1n5IS0EKf4byoSsOr6A==</saml:NameIdentifier>

          <saml:SubjectConfirmation>

            <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod>

          </saml:SubjectConfirmation>

        </saml:Subject>

      </saml:AuthenticationStatement>

They indeed share the AuthenticationInstant attribute element, and the "bearer" reference, but as it doesn't issue the same element in the end (AuthnStatement where I'd need an AuthenticationStatement) I guess this is not exactly what I'm looking for.

If you have some more details on where I should look for to get what I need I'll be happy to contribute it back to the project.

[dcarniel]

Looking deeper into the matter I realized that the AuthenticationStatement element does not exist anymore in SAML 2.0 and has been replaced by the AuthnStatement one. What I needed is indeed to include an AuthnStatement in my SAML 2.0 token so it can turned into an AuthenticationStatement when the token is converted from SAML 2.0 to SAML 1.1 (that's done by Microsoft ADFS in my use case).

I've looked into the code and the change is actually quite simple, just one line to add to the SAML20TokenProvider class. I'll send a proposed fix for a future version by e-mail.

[anil.saldhana]

You can propose a fix in this forum thread rather than an email.  Open Source development is all about openess and discussion in forums/mailing lists.

I am unsure why a SAML20TokenProvider that is meant to work with SAML2 has to issue a SAML11 bit.  It is not intuitive.

Anything you can do on the ADFS side of the house to get SAML2?

[anil.saldhana]

By the way, have you tried our SAML11 token provider that is present in PL?

http://anonsvn.jboss.org/repos/picketlink/federation/trunk/picketlink-fed-core/src/main/java/org/picketlink/identity/federation/core/saml/v1/providers/SAML11AssertionTokenProvider.java

[dcarniel]

Hi,

You're right, maybe I need to give a bit more background... The overall point is that my STS is providing tokens to ADFS which converts them into whatever input is required by the applications (in the initial case SAML 1.1 tokens, but could be different with other applications).

The issue I face is that when I generate a token today and have it transformed from SAML 2.0 to SAML 1.1 by ADFS is that is lacks an <AuthenticationStatement> element; and it seems to be linked with the absence of an <AuthnStatement> element in the emitted SAML 2.0 token. Hence my proposal to add this element to the tokens generated by the SAML20TokenProvider.

Looks like this can be done by adding the following line in the code at line 203 (after attribute statements generation):

     // add authnstatement

     statements.add( StatementUtil.createAuthnStatement( lifetime.getCreated(), confirmationMethod) );

If others can give their opinion on the matter I'd be happy to get more knowledgeable input (I've started to work with SAML tokens only recently).

Regards.

[anil.saldhana]

We will take a look as to whether there is a requirement for AuthnStatement to be present when the STS generates saml20 tokens.  The STS token provider has access to the principal/username to generate the authn statement.  Question is whether it is required/allowed by the spec.  We will take a look and make the change.

[anil.saldhana]

The SAML2 Assertion has the subject which contains the username.  Why not try to get ADFS to use the subject available in the assertion rather than an explicit AuthnStatement?

[dcarniel]

I'm first trying to stick to the standard behaviour of ADFS if possible. As AuthnStatement is the natural replacement of AuthenticationStatement I'd expect that having it present in my SAML 2.0 token will have it transformed into an AuthenticationStatement when ADFS converts the token from SAML 2.0 to SAML 1.1.

If that isn't a viable option I'll try to figure a different way but I'd rather not setup custom transformation rules if the standard process covers my needs.

[dcarniel]

Hi Anil,

I finally got the opportunity to test my change and I can confirm it works like a charm when ADFS 2.0 converts the token without any extra rule to setup. It would be really helpful for me if this could be added to a future release as I'm maintaining my own copy of the code only for that purpose.

I'm happy to provide a patch file if need be.

Regards,
Denis