requested AuthnContextClassRef from SP is ignored?

[Keith]

(v 1.8.0)

I'm dealing with a SP who requests that AuthnContextClassRef is set to
"urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport",
instead of the default that we are passing.

Indeed, using the Firefox SAML tracer plugin, or by dumping
SAML2_AuthnRequest, it looks like the SP is requesting "unspecified"
or "PasswordProtectedTransport" but that simpleSAMLphp completely
ignores this and always sends back "Password" (e.g. the AC_PASSWORD
default). (Why this is a problem for them, I have no idea.)

I guess my question is similar to this one:

http://groups.google.com/group/simplesamlphp/browse_thread/thread/79a4493ec6014a7

... except that I want simpleSAMLphp to honor the request of the SP,
rather than wanting to change the global default. Even with the
version of AuthnContextClassRef.php from trunk, I'm not sure how I
would add the filter to the single SP in question, because the
metadata is being auto-generated with metarefresh.

So, is simpleSAMLphp ignoring this? Have I misconfigured something?

[Tom Scavo]

On Mon, Feb 6, 2012 at 6:06 PM, Keith <keith....@gmail.com> wrote:
>
> Indeed, using the Firefox SAML tracer plugin, or by dumping
> SAML2_AuthnRequest, it looks like the SP is requesting "unspecified"
> or "PasswordProtectedTransport" but that simpleSAMLphp completely
> ignores this and always sends back "Password" (e.g. the AC_PASSWORD
> default). (Why this is a problem for them, I have no idea.)

Well, it doesn't really matter why the SP is requiring a specific
AuthnContext. The only thing that really matters is that the SAML
specification REQUIRES the IdP to honor the request or return an
error.

Tom

[Paul Hethmon]

Just a note that "unspecified" means the IdP chooses. It should return a SAML error if it cannot honor a specific context that has been requested.

(Sent from a phone that doesn't have a keyboard)

> --
> You received this message because you are subscribed to the Google Groups "simpleSAMLphp" group.
> To post to this group, send email to simple...@googlegroups.com.
> To unsubscribe from this group, send email to simplesamlph...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/simplesamlphp?hl=en.
>

[Olav Morken]

Yes. SimpleSAMLphp does not currently have a proper understanding of
authentication contexts. The infrastructure for adding it is in place,
but the glue between authentication sources and SAML 2.0 authenticaiton
contexts is missing.

(The plan is to implement it as an authentication source that uses the
requested authentication context together with its configuration to
dispatch the authentication request to the appropriate authentication
handler.)

Best regards,
Olav Morken
UNINETT / Feide

[Peter Schober]

* Keith <keith....@gmail.com> [2012-02-07 00:06]:

> Even with the version of AuthnContextClassRef.php from trunk, I'm
> not sure how I would add the filter to the single SP in question,
> because the metadata is being auto-generated with metarefresh.

That's a general problem of SSP (using metadata as policy
configuration). IMHO that's the same with attribute release policies
-- how do you deal with those currently?
The usual method seems to be to refresh metadata automatically with
some (other) local process and manually (or programmatically) merge
with local modifications, as to not overwrite your configuration.
-peter

[Keith]

Okay, so the conclusions I'm drawing from this disccusion are:

1. The SP is technically wrong to advertise that they accept
"unspecified" while rejecting "Password"? (and also may be wrong to
request "unspecified" *and* something else?)
2. SSP is wrong to ignore the request completely, and always reply
with the AC_PASSWORD constant, even though it might be *technically*
correct in the case of "unspecified" context from the SP, as in this
case?

While looking through the code some more, I see what Olav is talking
about; e.g., that the AuthnContext data is present in the object, and
that there is even a getRequestedAuthnContext() [that is never called,
anywhere that I can see]. So it looks like the functionality is
present, but not currently being used.

At the suggestion of the other thread that I referenced, I have tried
the AuthnContextClassRef authproc filter from trunk, which is setting
the global AuthnContext to "...PasswordProtectedTransport". This does
indeed solve the hiccup with the SP in question, and doesn't seem to
break any of the other SPs that we use, so I'm okay with this as a
solution for now. It also feels less hack-ish than changing
AC_PASSWORD ;-)

I suppose that it would be nice, as a long(er)-term solution, if we
could somehow override and/or "add to" the metadata that is generated
by the metarefresh module, e.g., to correct something like this for a
specific SP in InCommon, without affecting the global IdP settings.

Peter: to answer your question... we don't have a great way to deal
with attribute release policies on a per-SP basis. Our global release
list ends up being a combination of the attributes that every SP
requires (which hasn't been a problem [yet?]).