Is an authnContextClassRef of "unspecified" the same as "PasswordProtectedTransport" ?

1,788 views
Skip to first unread message

Terry Fleury

unread,
Jan 27, 2012, 5:45:55 PM1/27/12
to us...@shibboleth.net
During my InCommon SP Assurance Use Case testing, I discovered that passing
authnContextClassRef="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified"
from SP to IdP resulted in the IdP responding with
Shib-AuthnContext-Class="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport".
Is this the expected behavior?

I thought that if the SP requested a specific authnContextClassRef, the IdP
had to respond with that same value, or respond with an error if unable to
fulfill.

Terry Fleury
tfl...@illinois.edu

--
To unsubscribe from this list send an email to users-un...@shibboleth.net

Chad La Joie

unread,
Jan 27, 2012, 5:50:30 PM1/27/12
to Shib Users
"unspecified" means "any that you (the relying party) choose". So if
the IdP support username/password then it's free to respond with that.

Terry Fleury

unread,
Jan 27, 2012, 6:07:25 PM1/27/12
to Shib Users, Chad La Joie
Upon further testing, I discovered that when the SP requests "unspecified"
for authnContextClassRef, the IdP responds with the first
"AuthenticationMethod" configured for the given LoginHandler.

In other words, when the IdP is configured with the following in handler.xml:

<ph:LoginHandler xsi:type="ph:UsernamePassword"

jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config">

<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod>

<ph:AuthenticationMethod>http://id.incommon.org/assurance/bronze-test</ph:AuthenticationMethod>

<ph:AuthenticationMethod>http://id.incommon.org/assurance/silver-test</ph:AuthenticationMethod>
</ph:LoginHandler>

It returns
"urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" in
response to
authnContextClassRef="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified".

If I reorder the configuration in handler.xml as follows:

<ph:LoginHandler xsi:type="ph:UsernamePassword"

jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config">

<ph:AuthenticationMethod>http://id.incommon.org/assurance/silver-test</ph:AuthenticationMethod>

<ph:AuthenticationMethod>http://id.incommon.org/assurance/bronze-test</ph:AuthenticationMethod>

<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod>
</ph:LoginHandler>

The IdP returns "http://id.incommon.org/assurance/silver-test" in response
to authnContextClassRef="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified".

So semantically, requesting "unspecified" means "give me the first
configured authn".

Does this mean sending
authnContextClassRef="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified" to
the IdP is the same as not sending authnContextClassRef at all?

Terry Fleury
tfl...@illinois.edu

Tom Scavo

unread,
Jan 27, 2012, 6:25:28 PM1/27/12
to Shib Users
On Fri, Jan 27, 2012 at 5:50 PM, Chad La Joie <laj...@shibboleth.net> wrote:
> "unspecified" means "any that you (the relying party) choose".

Chad, can you provide a reference, please? Section 3.3.2.2.1 of SAML
Core suggests otherwise.

Tom

Tom Scavo

unread,
Jan 27, 2012, 6:28:37 PM1/27/12
to Shib Users
On Fri, Jan 27, 2012 at 5:45 PM, Terry Fleury <tfl...@illinois.edu> wrote:
> During my InCommon SP Assurance Use Case testing, I discovered that passing
> authnContextClassRef="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified"

You mean all by itself? I'm not sure why you'd do that...what semantic
are you trying to convey?

Tom

Terry Fleury

unread,
Jan 27, 2012, 7:09:04 PM1/27/12
to Shib Users
On 1/27/2012 5:28 PM, Tom Scavo wrote:
> On Fri, Jan 27, 2012 at 5:45 PM, Terry Fleury<tfl...@illinois.edu> wrote:
>> During my InCommon SP Assurance Use Case testing, I discovered that passing
>> authnContextClassRef="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified"
> You mean all by itself? I'm not sure why you'd do that...what semantic
> are you trying to convey?

At this point, I'm just trying to understand how the
authnContextClassRef thing works. I doubt I would ever pass just
"unspecified" by itself. I really want to say "give me silver, bronze,
or anything else you can give me", in that order. Not sure how to
accomplish that.

In my brief amount of testing, it seems to me like if I request any of
silver, bronze, or PasswordProtectedTransport by themselves, the IdP
will respond with that if it is configured as such. "unspecified" gave
me the first configured method.

Terry Fleury
tfl...@illinois.edu

Chad La Joie

unread,
Jan 27, 2012, 7:18:34 PM1/27/12
to Shib Users
The IdP documentation details the process the IdP uses to select an
authentication method.

--
Chad La Joie
www.itumi.biz
trusted identities, delivered

Tom Scavo

unread,
Jan 27, 2012, 7:32:35 PM1/27/12
to Shib Users
On Fri, Jan 27, 2012 at 7:18 PM, Chad La Joie <laj...@itumi.biz> wrote:
> The IdP documentation details the process the IdP uses to select an
> authentication method.

I read the documentation. You said:

"unspecified" means "any that you (the relying party) choose"

and I'm asking you how you arrived at that conclusion? There's nothing
in the spec that I can find that comes close to that.

Tom

Tom Scavo

unread,
Jan 27, 2012, 7:35:44 PM1/27/12
to Terry Fleury, Shib Users
On Fri, Jan 27, 2012 at 7:09 PM, Terry Fleury <tfl...@illinois.edu> wrote:
>
> At this point, I'm just trying to understand how the authnContextClassRef
> thing works. I doubt I would ever pass just "unspecified" by itself.

Okay, I understand.

> I
> really want to say "give me silver, bronze, or anything else you can give
> me", in that order. Not sure how to accomplish that.

Right, I don't know how to do that either. Listing everything but the
kitchen sink doesn't seem right, but I don't have a better suggestion,
sorry.

AuthnContext sucks.

Tom

Terry Fleury

unread,
Jan 27, 2012, 9:11:34 PM1/27/12
to Shib Users
I successfully configured my SP to send errors to an absolute URL with
"redirectErrors"
(https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPErrors).
Upon error, several parameters get passed to this URL, as shown in the
"Internal Parameters" table. This all works just fine.

However, I noticed that the "now" value is terminated with a line feed
character (ascii char 10) as shown in
"Fri%20Jan%2027%2016%3A48%3A07%202012%0A". I have to strip this
character off in my code. None of the other values have this extra line
feed at the end. Is this intentional? If so, why?

Cantor, Scott

unread,
Jan 28, 2012, 12:52:20 PM1/28/12
to Shib Users
> However, I noticed that the "now" value is terminated with a line feed
> character (ascii char 10) as shown in
> "Fri%20Jan%2027%2016%3A48%3A07%202012%0A". I have to strip this
> character off in my code. None of the other values have this extra line
> feed at the end. Is this intentional? If so, why?

No, it's not intentional.

-- Scott

Cantor, Scott

unread,
Jan 28, 2012, 1:12:41 PM1/28/12
to Shib Users
> On Fri, Jan 27, 2012 at 5:50 PM, Chad La Joie <laj...@shibboleth.net> wrote:
> > "unspecified" means "any that you (the relying party) choose".
>
> Chad, can you provide a reference, please? Section 3.3.2.2.1 of SAML
> Core suggests otherwise.

The NameIDPolicy language is a better indicator of the logical intent behind an unspecified constant in a request. The only reason unspecified was defined as a context class was to address the requirement to have at least a class in every statement. It's the "null" indicator, and should work like the null indicator does in other areas.

Also happens to be a much better result, since it means you don't have to configure the IdP to explicitly handle it ahead of time.

I would hope that including it on the end of a list of other classes with exact matching would favor one of the others and then fall into picking one at random if that doesn't work. That's pretty much the best possible result for such a use case.

Reply all
Reply to author
Forward
0 new messages