EuroPKI 2008 Manuel Sánchez Óscar Cánovas Gabriel López Antonio F. Gómez Skarmeta University of...
-
Upload
sandra-reeves -
Category
Documents
-
view
218 -
download
3
Transcript of EuroPKI 2008 Manuel Sánchez Óscar Cánovas Gabriel López Antonio F. Gómez Skarmeta University of...
EuroPKI 2008
Manuel Sánchez
Óscar Cánovas
Gabriel López
Antonio F. Gómez Skarmeta
University of Murcia
Levels of Assurance and Reauthentication in Federated
Environments
EuroPKI 2008
Agenda
Introduction
Level of Assurance
eduGAIN
Use Case
Infrastructure for re-authentication
Support for different Levels of Assurance
Related work
Conclusions
EuroPKI 2008
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
EuroPKI 2008
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
EuroPKI 2008
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
EuroPKI 2008
Agenda
Introduction
Level of Assurance
eduGAIN
Use Case
Infrastructure for re-authentication
Support for different Levels of Assurance
Related work
Conclusions
EuroPKI 2008
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
EuroPKI 2008
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
EuroPKI 2008
Agenda
Introduction
Level of Assurance
eduGAIN
Use Case
Infrastructure for re-authentication
Support for different Levels of Assurance
Related work
Conclusions
EuroPKI 2008
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
EuroPKI 2008
eduGAIN
Architecture overview
HomeInstitution
RemoteInstitution
Internet
eduGAIN BE
eduGAINMDS
eduGAIN BE
Metadata publishMetadata search
Metadata response
Authn Request
AuthN Response
Attribute Request
Attribute Response
End User
EuroPKI 2008
Agenda
Introduction
Level of Assurance
eduGAIN
Use Case
Infrastructure for re-authentication
Support for different Levels of Assurance
Related work
Conclusions
EuroPKI 2008
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
EuroPKI 2008
Agenda
Introduction
Level of Assurance
eduGAIN
Use Case
Infrastructure for re-authentication
Support for different Levels of Assurance
Related work
Conclusions
EuroPKI 2008
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
EuroPKI 2008
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.
EuroPKI 2008
Communication profile
Initial network authentication and token delivery (eduroam-based)
1. AuthN request
2. Forwarded to the home institution (AAA)
3. User is authN
4. AuthN tokengenerated by BE(transparent toservice)
5. Token (LoA) is sent back to the user
EuroPKI 2008
Communication profile
Token SAML-based Extension defined for LoAs Included in SAML 2.0 AuthnStatement
<AuthenticationContextDeclaration ID="ID_1" xmlns="urn:um:SAML:2.0:ac:classes:LoA" xmlns:saml="...:SAML:2.0:assertion" xmlns:ds="..." xmlns:xsi="...">
<Extension> <saml:Assertion>
<saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier NameQualifier="universityA.org">Alice</saml:NameIdentifier> </saml:Subject> <saml:Attribute AttributeName="LoAValue"> <saml:AttributeValue>2</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement>
<ds:Signature/> </saml:Assertion>
</Extension></AuthenticationContextDeclaration>
AuthNStatement
handle
LoAAuthnCtx
EuroPKI 2008
Communication profile
LoA message profile (Access and Validation)
1. User acceses protected service (LoA=2)
2. Service (through BE)requests available user’s authN token
3. Token is validated by PDP (XACML)
EuroPKI 2008
Communication profile
LoA message profile (redirection and re-authentication)
1. SP looks for a valid user’s idP for LoA=2
2. User redirection to idP
3. User is authN by idP and a new token (LoA=2)is generated and sent back
EuroPKI 2008
Communication profile
LoA message profile (Validation and optional Local AuthZ)
1. User acceses protected service with new token (LoA=2)
2. Optional local AuthZ based on user attributesfrom his home instit.
EuroPKI 2008
Agenda
Introduction
Level of Assurance
eduGAIN
Use Case
Infrastructure for re-authentication
Support for different Levels of Assurance
Related work
Conclusions
EuroPKI 2008
Metadata management
Defined by eduGAIN (based on SAML 2.0)
Each Auth Service (idP) is described by means of a EntityDescriptor
<md:EntityDescriptor entityID="https://universityA/AuthNService" xmlns:xsi=".../XMLSchema-instance" xmlns:md="...:SAML:2.0:metadata" xmlns:loa="urn:um:schemas:loa" xsi:schemaLocation="...:SAML:2.0:metadata schemas/saml-schema-metadata-2.0.xsd" validUntil="2007-12-31T23:59:59.0Z">
<md:AuthnAuthorityDescriptor xsi:type="md:AuthnAuthorityDescriptorType" protocolSupportEnumeration="...:SAML:2.0:protocol"> <md:AuthnQueryService Location="https://server.univerityA.org/saml/AuthNService/LoA2service" Binding="...:SOAP"> <loa:LoAValue>2</loa:LoAValue> </md:AuthnQueryService> </md:AuthnAuthorityDescriptor>
<md:Organization> <md:OrganizationName xml:lang="en">universityA.org</md:OrganizationName> <md:OrganizationDisplayName xml:lang="en">University A</md:OrganizationDisplayName> <md:OrganizationURL xml:lang="en">www.universitya.org</md:OrganizationURL> </md:Organization>
</md:EntityDescriptor>
EuroPKI 2008
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)
PolicySet
Target Action validateLoA
PolicySet1n
LoA0
LoA1
LoA2
LoA3
LoA4
Resource A
Resource B
Resource C
Resource D
Resource E
Grants access
Grants access
Grants access
Grants access
Grants access
PolicySetIdReference
PolicySetIdReference
Includes
Includes
Includes
Includes
EuroPKI 2008
LoA related policies
LoA Definition Policy example
<PolicySet PolicySetId="LoA2" PolicyCombiningAlgId="….:permit-overrides"> <Target/> <Policy PolicyId="Policy_LoA2" RuleCombiningAlgId="...:permit-overrides"> <Target/> <Rule RuleId="Rule_LoA2" Effect="Permit"> <Target> <Subjects> <Subject> <SubjectMatch MatchId="...:string-equal"> <AttributeValue DataType="….#string">2</AttributeValue> <SubjectAttributeDesignator AttributeId="LoAValue" DataType="….#string"/> </SubjectMatch> </Subject> </Subjects> </Target> </Rule> <Rule RuleId="Rule_LoA2_Deny" Effect="Deny"/> </Policy> <PolicySetIdReference>LoA3.xml</PolicySetIdReference></PolicySet>
EuroPKI 2008
LoA related policies
LoA Validation Policy example<PolicySet PolicySetId="LoAValidationPolicy" PolicyCombiningAlgId="….:permit-overrides> <Target> <Actions> <Action> <ActionMatch MatchId="...:string-equal"> <AttributeValue DataType="...#string">validateLoA</AttributeValue> <ActionAttributeDesignator AttributeId="action-id" DataType="...#string"/> </ActionMatch> </Action> </Actions> </Target> <PolicySet PolicySetId="LoA1_Policy" PolicyCombiningAlgId="...:deny-overrides"> <Target/> <PolicySetIdReference>LoA1.xml</PolicySetIdReference> <PolicySetIdReference>LoAValidationPolicy_LoA1.xml</PolicySetIdReference> </PolicySet> <PolicySet PolicySetId="LoA2_Policy" PolicyCombiningAlgId="…:deny-overrides"> <Target/> <PolicySetIdReference>LoA2.xml</PolicySetIdReference> <PolicySetIdReference>LoAValidationPolicy_LoA2.xml</PolicySetIdReference> </PolicySet></PolicySet>
EuroPKI 2008
Agenda
Introduction
Level of Assurance
eduGAIN
Use Case
Infrastructure for re-authentication
Support for different Levels of Assurance
Related work
Conclusions
EuroPKI 2008
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
EuroPKI 2008
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
EuroPKI 2008
Agenda
Introduction
Level of Assurance
eduGAIN
Use Case
Infrastructure for re-authentication
Support for different Levels of Assurance
Related work
Conclusions
EuroPKI 2008
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
EuroPKI 2008
Questions?
Levels of Assurance and Reauthentication in Federated
Environments
EuroPKI 2008
eduroam
EduRoamRADIUS
AP
NRENRADIUS
NRENRADIUS
InstitutionalRADIUS
InstitutionalRADIUS
Institution A Institution B
EuroPKI 2008
DAMe
Network authZ profileHome Institution
Remote Insitution
SAMLResp.
AttributeStat.attributes
Access-Accept (with handle)
translateobligations
ACCESS-ACCEPT+ propertiesEAP-SUCCESS
eduroam
SearchRequest(uid:handle, action,
resource)
SearchResult(obligations)
Network authentication
RADIUSRADIUS
End User
NAPeduGAIN
BE
PDP(AuthZEngine)
eduGAINBE
idPAuthn
Attrib.
SAMLRequest
AttributeQueryhandle
EAPOL
EAP
RADIUS
Federation specific
RADIUS / EAP
SOAP
LDAP SOAP
XACMLResourceAccessPolicy
SAMLResponse
XACMLAuthZDecSt.XACMLResponse
result obligs.
SAMLRequest
XACMLAuthZDecQXACMLRequest
handle
res. action
evidenceattrs.
EuroPKI 2008
DAMe
Token-Based
Web AuthN profile
User’s Device
Service Provider Domain
Request Access
Receive eduToken
User
NAP SPR-BE
(token-enabled)
uSSOClient
Supplicant
Token Manager
RMI PEAP
Browser(Java
plugin)
Network authentication
Encrypt and store eduToken
Redirect
WAYF
Redirect
Select „via eduToken“
Token Fetcher Applet
Fetch eduToken
Decrypt eduToken
Return eduToken
POST eduToken
ValidateeduToken
Create Assertion
Send Assertion
Grant Access
HTTPS
HTTPS
HTTPS
HTTPS HTTPS