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?

gabilm@um.es

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