Re: [saml-dev] AuthnContext for WebSSO

[Peter Major <peter.major@forgerock.com>]

Hi,

OpenAM by default always sends the RequestedAuthnContext, yes, but which 
one it should request should be matter of configuration (by the way the 
default comparison method is also configurable).
Anyways I've just filed 
https://bugster.forgerock.org/jira/browse/OPENAM-6416 so that the 
default behavior is improved - at the very least, to minimum PPT.

Personally I find AuthnContexts a bit awkward though... You can request 
minimum PPT, and then that will allow the IdP to choose something 
better, but at the end of the day it will be up to the SP to decide 
whether the received AuthnContext is actually acceptable (which then 
means that SP needs to have the same kind of "strength ordering" as the 
IdP)..

Regards,
Peter

2015. 07. 17. 20:16 keltezéssel, prabhat chaturvedi írta:
> 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
> <mailto:cantor.2@osu.edu>> wrote:
>
>     On 7/16/15, 1:40 AM, "prabhat chaturvedi"
>     <chaturvedi.prabhat@gmail.com <mailto: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