Shibboleth Developers

[Von Welch <>]

I agree that Authn Strength != LOA, but I would say that in our  
experience the user authentication step is generally by far the  
weakest link in the chain to such an extent that authn strength has a  
dominate impact on LOA.

We haven't had any CAs or Kerberos servers compromised yet, or any  
vetting procedures get so screwed up as to issue the wrong identifier  
to the wrong person, but user's passwords and private keys get stolen  
all the time, so expressing whether a user used a static password or  
a OTP hardware token gives one a good ideal for the LOA that can be  
assumed.

Von


On Feb 15, 2006, at 3:53 PM, Scott Cantor wrote:

> > Yes, I understand, but somehow LOA needs to be communicated back to
> > the SP.
>
> At the moment, attributes are probably the best way to do that, or  
> some
> community would need to profile AuthenticationMethod to be,  
> essentially, a
> 2.0 context class or declaration, because it's normal 1.1 meaning  
> is not
> LOA.
>
> The Feds use an attribute, FWIW.
>
> > Grid SPs wish to base access control decisions on
> > "authentication strength."
>
> But that is not LOA. That is one small part of LOA. If that isn't
> understood, mistakes will ensue. Strong PKI + anybody gets a cert  
> with no
> proof = low LOA. SAML 1.1's strings don't communicate anything I  
> would call
> LOA.
>
> > So IdP deployments SHOULD populate AuthenticationMethod with values
> > SPs MAY use to make access control decisions.  These values MUST be
> > consistent across IdPs.  For example, what are the semantics of
>
> This is not fodder for Shibboleth, it's fodder for InCommon or  
> whatever your
> deployment vehicle of choice is. What people SHOULD do is not  
> something we
> can decide here. We CAN help them implement their choice.
>
> > I don't quite know what 'password' means in this case.  SAML 2.0 does
> > a better job of this (Password, InternetProtocolPassword,
> > PasswordProtectedTransport, SecureRemotePassword) so I guess my
> > question is how do we make these kind of fine-grain distinctions in
> > SAML 1.1?
>
> See above, attributes or a shoehorning of stuff into  
> AuthenticationMethod.
> Or sure, if it's static, somebody could decide on a metadata  
> extension. I
> had a conversation with Ian about potentially extracting  
> saml:Attribute
> elements from entity metadata and publishing those alongside user
> attributes, just to keep things relatively automatic.
>
> > The other way to look at this is in terms of federation policy.
>
> That's the *only* way to look at this, IMHO.
>
> > I see that InCommon (e.g.) has a notion of "level of assurance"  
> > but is
> > participation in InCommon based on LOA?
>
> Not really, just sign the agreement and you document your  
> practices, which
> is essentially self-asserting the raw data that tends to impact LOA.
>
> > If so, how is this notion
> > captured in static metadata?  If not in metadata, how is LOA
> > transported over the wire in SAML assertions?
>
> It's not right now. It's handled OOB on the presumption that accepting
> somebody's assertions is the result of due diligence. Understanding  
> that for
> many real world apps, zero effort is usually considered due diligence
> because of where they started from.
>
> -- Scott