Shibboleth Developers

[Keith Hazelton <>]

*- If -* the Identity Provider system has all the processes in place to 
determine an appropriate value to place in an attribute like authnLoa 
for a Shib IdP authentication event (big "if" since none that I know of  
have that in place today),

*- and -* the Shib Attribute Authority can populate and transmit the 
attribute/value pair (one way would be to have such an attribute defined 
in an LDAP repository that the AA is configured to pull from),

*- Then -* Shib 1.3 could provide that attribute/value pair to a 
requesting SP.

As I said, authnLoa is still just a proposal under discussion.  So 
IdP/SP pairs that want to use authnLoa or something like it would have 
to profile it, set up the processes & machinery at both ends, and just 
agree to use it bilaterally for now.

    That's how I see it, there may be other views,   --k
_________________

Tom Scavo wrote:

> Hi Keith,
>
> Thanks for sharing this information.  For what it's worth, I think the
> LOA attribute you propose will satisfy the general grid use case.
>
> A possible problem is the apparent dependence on SAML 2.0.  Will Shib
> 1.3 eventually carry this attribute?
>
> Thanks,
> Tom
>
> On 2/16/06, Keith Hazelton 
> <>
>  wrote:
>  
>
> > Assuming that the AuthN factor in LOA is one important piece of
> > information to convey, here are some possibly relevant notes.
> >
> > 1) Support for this gets lots better in SAML 2.0. Work on OpenSAML 2.0
> > is well underway. Meanwhile,
> >
> >
> > 2) For some work with the federal e-auth project, some of us MACE-oids
> > have been working on an attribute to carry LOA associated with the AuthN
> > event in the interaction in question between a Service Provider (Agency
> > Application in US E-Authentication-speak; could be a Grid resource,
> > though that hasn't been our design center) and an Identity Provider
> > (Credential Service Provider in E-Auth-speak). It's a work in progress,
> > but here's what we've said in the latest draft proposal within the
> > working group:
> >
> >    
> >
> > > authnLoa
> > >      
> > >
> > > The values of this new attribute are intended to convey to the relying
> > > party an overall level of assurance for the /authentication step/ in
> > > the current interaction with the user. Conditions under which a
> > > credential service provider is permitted to assert a given level will
> > > likely be spelled out in interfederation or bilateral agreements.
> > >      
> > >
> > > There are multiple conventions for quantifying and expressing levels
> > > of assurance. Values of authnLoa consist of two components. The first
> > > component is an identifier for the level of assurance convention being
> > > used, and the second is the asserted level within that convention.
> > > There is a controlled vocabulary for both components.
> > >      
> > >
> > > The identifier for the level of assurance conventions defined in this
> > > document is that spelled out in NIST Special Publication 800-63. The
> > > identifier is "nist-sp-800-63."
> > >      
> > >
> > > Values for the second component of the NIST levels of assurance are a
> > > single character, "1," "2," "3" or "4."
> > >      
> > >
> > > There will be a registry of identifiers for LOA conventions, here are
> > > the seed values...
> > >      
> > ...[TBD]
> >
> > Note that this wording is from an information model level treatment.
> > Bindings to LDAP attributes would be specified in another document. For
> > SAML bindings we recommend following the SAML 2.0 "X.500/LDAP Attribute
> > Profile," specified in the OASIS Standard, /Profiles for the OASIS Security
> > Assertion Markup Language (SAML) V2.0/," Document identifier:
> > saml-profiles-2.0-os, location:
> > http://docs.oasis-open.org/security/saml/v2.0/.
> >
> > This profile basically says, the name of the attribute is whatever it's
> > OID is (all X.500 and LDAP attributes should have OIDs), and the value,
> > if it is UTF8, is just the UTF8 string, unaltered. If we create an LDAP
> > attribute to carry AuthnLOA, it will have an OID, and a two-part string
> > value (syntax TBD) corresponding to the two components, LOA convention
> > identifier and LOA value within that convention.
> >
> > e.g. For the X.520 "givenName" attribute, the SAML 2.0 Attribute element
> > asserting a given name of "Steven" would read:
> >
> > <saml:Attribute
> > xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
> > NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
> > Name="urn:oid:2.5.4.42" FriendlyName="givenName">
> > <saml:AttributeValue xsi:type="xs:string"
> > x500:Encoding="LDAP">Steven
> > </saml:AttributeValue>
> > </saml:Attribute>
> >
> > _________
> >
> > Von Welch wrote:
> >
> >    
> >
> > > 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
> > > >
> > > >        
> > --
> > ________________________________________________________
> > Keith Hazelton                  Senior IT Architect, UW-Madison
> > (608) 262-0771                  Division of Info. Technology
> > (608) 205-2022 (home)           1210 W. Dayton St., rm. 2164
> > http://arch.doit.wisc.edu/keith      Madison, WI  53706
> >
> >
> >
> >    


--
________________________________________________________
Keith Hazelton                  Senior IT Architect, UW-Madison
(608) 262-0771                  Division of Info. Technology
(608) 205-2022 (home)           1210 W. Dayton St., rm. 2164
http://arch.doit.wisc.edu/keith      Madison, WI  53706