You are free to extend the token provider to add the auth statement.
I actually started on that path as a side-track, though it appears that the AuthnStatementType actually generates the follow type of element:
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">
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.
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.
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?
By the way, have you tried our SAML11 token provider that is present in PL?
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).
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.
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?
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.
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.