1 / 12

LoA for Attributes

LoA for Attributes. David Chadwick University of Kent. Acknowledgements. This research has received funding from the European Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement n° 216287 (TAS³ - Trusted Architecture for Securely Shared Services).

ilori
Download Presentation

LoA for Attributes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LoA for Attributes David Chadwick University of Kent IDTrust 2010

  2. Acknowledgements • This research has received funding from the European Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement n° 216287 (TAS³ - Trusted Architecture for Securely Shared Services). • The information in this presentation is provided "as is", and no guarantee or warranty is given that the information is fit for any particular purpose. The above referenced consortium members shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials subject to any liability which is mandatory due to applicable law. IDTrust 2010

  3. Current NIST 800-63 LoA Model • Guidelines “to remotely authenticate a user’s identity to a Federal IT system”. • Two components • Identity Proofing and Registration of applicant • Authentication mechanism used • Combined into one LoA value in range 1 (lowest) to 4 (highest) • Designed for a single system that both registers the user and authenticates the user and provides the identity of the user to the Federal IT system (as an identifier and optional attributes) IDTrust 2010

  4. Deficiencies in NIST Model (1) • What if a user has multiple authentication mechanisms provided by an IdP e.g. un/pw and a hardware PKI token? • Different LoAs should be provided per login session • Leads to concept of Session LoA, which is dynamically computed from Registration LoA (fixed) and Authentication Mechanism LoA (variable) IDTrust 2010

  5. Deficiencies in NIST Model (2) • What if the system is distributed and the user’s identity attributes are provided by multiple authorities? Authorisation is what is actually required, not just authentication • So, you are David Chadwick? But what are you entitled to do? • In federated identity management, a user’s identity is now recognised as being a set of possibly distributed identity attributes, rather than an identifier and optional local attributes (which is assumed by NIST) • E.g. “the user is a student of university X”. This may be sufficient to authorise access to a resource (typical Shibboleth scenario). The resource does not need to know that the user is David Chadwick so the identifier is not needed. IDTrust 2010

  6. The Way Forward Today (for a single IdP) • In RBAC/ABAC systems access is granted based on the attributes of the user (one of which may, but need not, be a unique identifier) • We can supplement the set of user attributes with the existing NIST LoA value assigned to the current session in order to provide finer grained access controls • E.g. Students with Session LOA 1 can read the module syllabus. Students with Session LOA 2 can upload their assignments • We have had this implemented for several years in our open source software (PERMIS) IDTrust 2010

  7. A Way Forward Today (for multiple IdPs) • Users typically have accounts at multiple IdPs and need to provide attributes from several IdPs in order to gain access. The user configures a linking service to know (some of) these accounts • When the user logs in, a Session LoA is dynamically computed by the authenticating IdP Session LoA = Authentication LoA (if no attributes are asserted) Session LoA = Lowest of Authentication LoA and Registration LoA (if at least one registered attribute is asserted) • The linking service coordinates attribute assertion collection from the multiple IdPs • Each of these attribute assertions need their own LoA but currently we have to munge these to fit the single session LoA by excluding those assertions with a lower LoA IDTrust 2010

  8. And for Tomorrow - A Model • A user registers with each IDP and is assigned a Registration LoA (according to the procedure that is used) which is attached to the user’s registered attributes. • The user is given one or more authentication tokens/mechanisms by the IdP each with its own Authentication LoA • When the user logs in to an IdP, a Session LoA is dynamically computed for the session according to the formula Session LoA = Authentication LoA (if no attributes are asserted to service provider) Session LoA = Lowest of Authentication LoA and Registration LoA (if at least one registered attribute is asserted to service provider) • All other linked IdPs create their own attribute assertions for this session and include their own LoA in the attribute assertion Assertion LoA = Lowest of Session LoA and Registration LoA • Service Provider has a fine grained ABAC policy in which each identity attribute in a rule has a required LoA. For the rule to be passed the assertion LoA must be GE to the required LoA IDTrust 2010

  9. Example Use Case • Case: American Medical Schools (AAMC) • Scenario: The American Medicals Schools (AAMC) administer a test for admission into accredited US medical schools. Accounts are primarily given to users via e-mail verification to allow for the application process, but full identity proofing is then undertaken (fingerprinting and photo) when the students come to take the test. Campuses could benefit from capturing the value of the AAMC identity-proofing process. • LoA Details: The initial Registration LoA is low (1) due to email verification only, which means that the Session LoA will remain low no matter how good the authentication mechanism is. After the students have taken the test, the Registration LoA is now high (say 3) due to fingerprinting etc., so the Session LoA can rise to the lower of the Authentication LoA and Registration LoA. IDTrust 2010

  10. Example Use Case • Case: Students Using External Identities • Scenario: User creates an OpenID for a username you do not know and Provider does no checks as to who user is in the real world. However it has a good authentication mechanism (LoA 2). Any RP accepting the OpenID has reasonable assurance it is the same user each time (but not who the user is.) User then turns up as a student at University X. The university can do all its normal checks on the person e.g. have the right school exam results, have paid fees, am entitled to be in the UK, etc. (Registration LoA >2) but it does not need to issue its own authentication credentials. Instead it checks the technical quality of OpenID Provider, and that its processes are sufficiently robust to qualify as LoA 2, and then it can assert the student’s identity attributes to service providers with a Session LoA of 2, even though the OpenID Provider doesn’t know them. • LoA Details: Although the OpenID Registration LoA is the lowest, since no attributes are asserted the Session LoA is 2 due to its good authentication procedures. Once the user registers at the University and is verified she can continue to use the OpenID and the university asserts its own attributes with a Session LoA of 2 since its Registration LoA >2. IDTrust 2010

  11. Example Use Case • Case: E Commerce Site • Scenario: Online shopping at Amazon you provide a self assertion of your name and postal address (for delivery), a signed assertion from Visa that you have a credit card, and a signed assertion from IEEE that you are a member and thus eligible for a discount. Visa has provided you with a smart card and PIN for authentication • LoA Details: Your session LoA is relatively high (say 3) due to the smartcard authentication mechanism, but your name and address card is self asserted so this has the lowest LoA (1). Your credit card attribute is sent by the issuer with a high LoA (3) due to the rigorous registration checks the bank undertook before issuing the card, whereas the IEEE membership attribute has an LoA of 2 due to the limited amount of registration checking they did. IDTrust 2010

  12. Conclusions • Federated Identity Management systems recognise that users will need to provide attributes from multiple IdPs within a single session, but only need to authenticate once • The session LoA should be dynamically computed based on the authentication mechanism used, the IdP used, and what it asserts • Each IdP should be able provide its own Assertion LoA along with the attributes it asserts • This allows the SP to have a fine grained authorisation policy which places a LoA requirement on each identity attribute IDTrust 2010

More Related