OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [saml-dev] AuthnContext for WebSSO


Thanks Scott for your reply.

Here I am using an openAM default SP. By default, not only in this product but generally most of products which I have used, request PPT with exact comparison for WebSSO flow.

Also, I am curious to know a suitable example for 'exact'?

And is there any relation between WebSSO and PPT?

-Prabhat

On Jul 16, 2015 8:02 PM, "Cantor, Scott" <cantor.2@osu.edu> wrote:
On 7/16/15, 1:40 AM, "prabhat chaturvedi" <chaturvedi.prabhat@gmail.com> wrote:
>
>1) Can IdP send unspecified(urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified) authnContext, if the Authentication for WebSSO use-case happens using username/password over HTTPS. As per spec, it says it should send PasswordProtected if its password based authentication over HTTPS. We at SP are looking for PasswordProtected AuthnContext and we fail the assertion.

An IDP may send anything as long as it's not lying, and "unspecified" is by definition not lying. There is no language anywhere forcing the IdP to tell you this information. The AC classes are merely example constants for general use in situations in which the IdP does want to disclose that.

I tend to agree that it's a bit weird to worry about it, but one argument I've heard is that disclosing stronger methods when it's not necessary to do so provides information for later exploit about who has a stronger account and who doesn't (for example, maybe I phish only the password accounts). I'm stretching.

>2)We being an SP also send Required AuthnContext (which is PasswordProtected) in SAMLRequest, in this case, if IdP does not support this AuthnContext,
> it should reply with NoAuthContext. But IdP still sends the unspecified AuthnContext.

It must respond with an error. I don't believe the spec makes specific second-level statuses a MUST, but I'm going from memory and there may be a few cases where it does. In the end, those aren't really the point, the key is that you MUST fail the request. You are correct on that. if you send X with exact matching, the response MUST contain X or be an error.

>3)Can unspecified AuthnContext be used for any reason? As per spec it should be used for unspecified means of Authentication.
>This IdP is using unspecified for all the case.

Yes, it can be used for any reason since it essentially is just the absence of a context class. Like all the unspecified constants, it's dumb, but unlike most of them, this one actually has a purpose because the schema requires AuthnContext in a statement, so you have to send something back.

>They are asking us to not send RequestedAuthnContext which is optional. We being a SP had already integrated with well known IdPs and do not want to do this change for only this IdP.

You are in error here because it's a bad practice to ask for exact patch on PPT. That precludes stronger authentication. As I noted on another list just last night, when SPs do that to me, I force them to stop and explain why it's a dumb choice.

If you want to preclude something weaker than Password, the only way to do that without checking afterwards and enumerating methods (which is hopeless) is to ask for PPT with "minimum" instead of "exact". But your best option is to maybe check for a few weak methods and live with it. Asking for exact match on passwords is a bad thing to do.

-- Scott



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]