Shibboleth Developers

[Keith Hazelton <>]

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