Shibboleth Developers

[David Chadwick <>]

Dear All

sorry to come in late on this discussion, but we are currently
implementing LOA (which I assume means level of assurance) and coupling
it to authorisation decision making in the following way. (BTW, we are
using values 1 to 4 for LOA as provided by the NIST special report      Burr,
W. E., et al, Electronic Authentication Guideline, NIST Special
Publication 800-63,  Sept. 2004)

A new component called the FAME Login Server (which front ends the IDP
handle service) evaluates the LOA provided by the particular
authentication method chosen by the user, and sets the value for this.
The FAME LS is being built by Manchester University.

A custom data connector is being built that connects the FAME LS to the
AA. When the SP contacts the AA and asks for the user's attributes, the
LOA attribute is added to normal set (typically provided by the LDAP
directory) and returned to the SP.

We have defined the LOA as an LDAP attribute, so that it can be merged
into the SAML response in the same way as all the other LDAP attributes.

We have then connected PERMIS to the SP through the SAAM module for
Apache (which we released last year), and in the PERMIS policy we define
the LOA as a hierachical attribute (4>3>2>1) in just the same way as
other attributes/roles can be, such as doctor > health care
professional. In this way, a policy can be written such as “subjects
with the following attributes: affiliation=St Mary’s Hospital, LoA=4,
role=doctor may write to Patient Records, and subjects with the
following attributes: affiliation=St Mary’s Hospital, LoA=1, role =
health care professional, may read Patient Records”. Then a doctor with
a LoA of 2 would be able to read a patient’s records, but not be able to
write to it.

We plan to pilot this around mid-summer.

regards

David

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

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: 

Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************