1 / 35

Levels of Assurance and Reauthentication in Federated Environments

Levels of Assurance and Reauthentication in Federated Environments. Manuel Sánchez Óscar Cánovas Gabriel López Antonio F. Gómez Skarmeta University of Murcia. Agenda. Introduction Level of Assurance eduGAIN Use Case Infrastructure for re-authentication

nelia
Télécharger la présentation

Levels of Assurance and Reauthentication in Federated Environments

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. Levels of Assurance and Reauthentication in Federated Environments Manuel Sánchez ÓscarCánovas Gabriel López Antonio F. GómezSkarmeta University of Murcia

  2. Agenda • Introduction • Level of Assurance • eduGAIN • Use Case • Infrastructure for re-authentication • Support for different Levels of Assurance • Related work • Conclusions

  3. Introduction • Issue 1: • Organizations offer more and more on-line authenticated services • Level of Security based on the consequences derived from an authN error and misuse of credentials (Newspaper vs bank accounts) • Definition of the authentication strength required to assure that an entity is the claimed entity • Level of Assurance (LoA) • Issue 2: • Emergence of federated approaches to resource sharing • Organizations granting users in any of them access to resources with a single identity stated by the organization the user belongs to • Federations make use of SSO to avoid re-authentication • Service Providers (SP) and Identity Providers (idP). • InCommon, HAKA and SWITCH (Shibboleth) , eduroam

  4. Introduction • But there are situations where the user needs to re-authenticate: • Example 1: • Alice is browsing the Web at home, using the idP by the ISP, • She wants to access site restricted to users belonging to his work organization • She needs to authN again against her organization • Example 2: • Several authN mechanisms with different LoAs are available • For example: • Login/pwd  access the network or read an e-mail • PKC to digitally sign electronic documents

  5. Introduction • This work presents an infrastructure for re-authN process in federations • SSO is used and authN is required initially to access the network • Necessary to manage multiple user’s identities and LoAs • Important : this functionality should be added without modifying the existing IdMs, such as Shibboleth, PAPI, etc.. • New services should be included at a confederation level • Connecting different existing federations • Without modifying their internal protocols • We make use of the eduGAIN middleware • Work developed under the DAMe project • Goal: to define a unified authN and authZ system for federated services hosted in the eduroam network

  6. Agenda • Introduction • Level of Assurance • eduGAIN • Use Case • Infrastructure for re-authentication • Support for different Levels of Assurance • Related work • Conclusions

  7. Level of Assurance • Strength of authentication required for a relying party to be assured that an entity is indeed the claimed entity • Two factors: • Degree of trust to which the credential being presented actually represents the entity named in it  identity proofing • Degree of confidence to which the represented entity actually is the entity engaging the electronic transaction  identity binding • For IdP  Discrete assurance indicators that quantify the degree of protection the organization provides in the identity management • For SP  Measures of the authN trustworthiness required to authorize the access to resources • Higher LoAs are required to mitigate higher levels of risk

  8. Level of Assurance • US federal government (continuation of a UK gov. framework): • minimal assurance of identity • moderate assurance of identity • substantial assurance of identity • high assurance of identity • Each LoA is appropriate for a different kind of electronic transaction • National Institute of Standards and Technology (NIST) contributed with supplementary guidelines • technical authentication requirements for the authentication • simple password challenge-response  level 1 • password through a secure authN protocol  level 2 • soft cryptographic tokens  level 3 • hard cryptographic tokens  level 4

  9. Agenda • Introduction • Level of Assurance • eduGAIN • Use Case • Infrastructure for re-authentication • Support for different Levels of Assurance • Related work • Conclusions

  10. eduGAIN • eduGAIN: GÉANT Authorisation INfrastructure for the research and education community • Defined by the TERENA GN2 project • Objective: to build an interoperable AuthN and AuthZ Infrastructure (AAI) to interconnect different existing federations • eduGAIN is responsible for: • To find the federation where a roaming user belongs to • To translate the messages between the federation internal protocols and eduGAIN and vice versa • To establish the trust fabric among the participating institutions

  11. eduGAIN • Architecture overview

  12. Agenda • Introduction • Level of Assurance • eduGAIN • Use Case • Infrastructure for re-authentication • Support for different Levels of Assurance • Related work • Conclusions

  13. Use Case • Alice requests a Service1 (network, web, etc) at a Remote Institution • Alice is redirected and authenticated in her Home Institution • She obtains an authN token with LoA=1 (login/pwd) • Contains data about the authN process (idP, LoA, …) • Then she tries to access Service2 that requires LoA=2 (PKC) • She presents her authN token • Alice does not have a valid token • She is redirected to the appropriate authN service for LoA=2 to be re-authenticated • She obtains a new token • Alice is redirected and she gains access to Service2

  14. Agenda • Introduction • Level of Assurance • eduGAIN • Use Case • Infrastructure for re-authentication • Support for different Levels of Assurance • Related work • Conclusions

  15. Architecture • Several organizations acting as idP and SP • IdPs are equipped with different authN methods • She can try to access the resources using different identities • SP must check that Alice makes use of the proper identity • An authZ process may be necessary • Validation process proposed must be transparent to the SP • SP only has to deal with authN and attribute queries to the appropriate BE

  16. Architecture • BE are responsible for: • recovering token • validating • redirecting Alice to the appropriate authN service • Decisions can be delegated to a PDP (policies required) • Confederation Metadata Service (MDS) to locate authN services • Validation of the token and the re-authentication processes are carried out at the (con)federation level  they depend on global agreements among all the organizations.

  17. Communication profile • Initial network authentication and token delivery (eduroam-based) 1. AuthNrequest 3. UserisauthN 2. Forwardedtothe home institution (AAA) 4. AuthNtoken generatedby BE (transparentto service) 5. Token (LoA) issent back to the user

  18. Communication profile • Token • SAML-based • Extension defined for LoAs • Included in SAML 2.0 AuthnStatement

  19. Communication profile • LoAmessageprofile (Access and Validation) 1. Useraccesesprotected service (LoA=2) 2. Service (through BE) requestsavailableuser’s authNtoken 3. Tokenisvalidated by PDP (XACML)

  20. Communication profile • LoAmessageprofile (redirection and re-authentication) 1. SP looks for a valid user’sidPforLoA=2 2. UserredirectiontoidP 3. UserisauthNbyidP and a new token (LoA=2) is generated and sent back

  21. Communication profile • LoAmessageprofile (Validation and optional Local AuthZ) 1. Useraccesesprotected servicewith new token (LoA=2) 2. Optional local AuthZ based on user attributes from his home instit.

  22. Agenda • Introduction • Level of Assurance • eduGAIN • Use Case • Infrastructure for re-authentication • Support for different Levels of Assurance • Related work • Conclusions

  23. Metadata management • Defined by eduGAIN (based on SAML 2.0) • Each Auth Service (idP) is described by means of a EntityDescriptor

  24. LoA related policies • Defined via XACML • LoA hierarchical definition: • LoA(x) inherit permissions of LoA (x-1) • Two kind of policies: • LoA Definition Policy (global) • LoA Validation Policy (local)

  25. LoA related policies • LoADefinitionPolicyexample

  26. LoA related policies • LoAValidationPolicyexample

  27. Agenda • Introduction • Level of Assurance • eduGAIN • Use Case • Infrastructure for re-authentication • Support for different Levels of Assurance • Related work • Conclusions

  28. Related Work: FAME (Flexible Access Middleware Extension) • Shibboleth extension  provides multi-level user authN (LoAs) • Based on the cryptographic strength of the authN protocol • LoA value is added to the set of user’s attributes in the idP • Passed to authZ decision engine together with user’s attributes • Issue 1: it is oriented to web-based resources • it does not link the initial authN to access the network with the authN in the Shibboleth IdP • Issue 2: SP obtains LoA value after querying the idP for attributes • if only authN and not authZ is required, there is no need for this additional exchange of messages • Issue 3: How to locate idPs based on LoAs

  29. Related Work: Cardspace and Higgins • When the user tries to access some service, information card (IC) client recovers the SP policy to determine service reqs (authN) • IC app. displays to the user his ICs satisfying those reqs • IC app. contacts IdP that issued that card  gets signed token • Finally, token is sent to the SP to get access to the service • From the LoA point of view the use a SP policy provides the same functionality that the infrastructure that is described in this work • But: • They are user-centric solutions  open user communities • This work is based on the existence of previously established organizations with their own users • Organization must control the process to guarantee the existence and value of certain attributes and must maintain the control of the identification process

  30. Agenda • Introduction • Level of Assurance • eduGAIN • Use Case • Infrastructure for re-authentication • Support for different Levels of Assurance • Related work • Conclusions

  31. Conclusions • Existence of different situations in an SSO federated environment where it is necessary for a user to reauthenticate • related LoA is not secure enough to access the service • Proposal for improving SSO by means of an infrastructure for validation and re-generation of SSO credentials • Extending eduGAIN, a middleware for confederations, with the necessary services, protocols and policies for managing the validation of the user’s identity and the redirection process • Based on SAML and XACML standards • Covering from network service to application services • Different kinds of federations such as Shibboleth and PAPI can interact • Specific profile to base the identity validation in the LoA is described

  32. Levels of Assurance and Reauthentication in Federated Environments Questions? gabilm@um.es

  33. eduroam

  34. DAMe • Network authZ profile

  35. DAMe • Token-Based • Web AuthN profile

More Related