Shibboleth Developers

["Tom Scavo" <>]

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
>
>
>