Shibboleth Developers

[Tom Scavo <>]

If various Grid/Shib discussions at GGF16 this week are any
indication, it seems grid architects are VERY concerned with the
"authentication strength" of a Shibboleth IdP.  Is there anything that
can be done to alleviate this problem in the short term (while SAML
2.0 matures)?

AuthenticationStatement/@AuthenticationMethod is "supported" by
Shibboleth 1.3 (i.e., HTTP header SAMLAuthenticationMethod is captured
by the Shib 1.3 SSO protocol handler), but since a Shib 1.3 IdP is
protected by local authn, population of the SAMLAuthenticationMethod
header is a deployment issue.  Unfortunately this is not discussed in
the Shib documentation (AFAIK) so typically the AuthenticationMethod
attribute comes across as unspecified in practice, which renders it
useless.

Possible values of the AuthenticationMethod attribute are defined by
the SAML 1.1 spec but Shibboleth protocols do not profile this
attribute.  It would be helpful to relying parties if the specified
values of AuthenticationMethod were mapped to federation levels of
assurance.  Not sure if this is a Shibboleth protocol issue or a
federation policy issue, but somewhere a mapping from
AuthenticationMethod to LOA should be specified.

So there are two things that could be done to address concerns
regarding strength of authentication:

1. Document HTTP header SAMLAuthenticationMethod in the Shib 1.3
deployment guides.
2. Either profile the use of the AuthenticationMethod attribute in the
Shibboleth profiles or map the SAML 1.1 values to LOA at the
federation level.

This is seen as a stopgap measure in anticipation of SAML 2.0, at
which point the rich AuthnContext framework becomes available.

Tom