Download ppt - EMI Development Plans for Identity Management

EMI Development Plans for Identity Management

Henri Mikkonen / HIPMoonshot, Grid and HPC Workshop

7.7.2011 London, UK

EMI I

NFS

O-R

I-261

611

2

Content

• Motivation– Questionnaires to potential customers– AAI use cases

• Technology– Introduction to WS-Trust– WS-Trust interoperability & token profiles

• Implementation– Security Token Service (STS)

07/07/2011 Henri Mikkonen @ Moonshot, Grid and HPC Workshop

EMI I

NFS

O-R

I-261

611

3

Background

• AAI needs of the DCIs -workshop held at EGI Technical Forum (September / 2010) [1]

• Questionnaires for projects crossing national boundaries and NGIs– 3 User communities

• Biomed, Earth Sciences, HEP

– 5 ESFRI projects• CLARIN, Lifewatch, ELIXIR, EuroFEL, ILL

– 2 NGIs• Italy, U.K.


EMI I

NFS

O-R

I-261

611

4

Results for the questionnaire [2]• Grid users do not want to handle credentials themselves• Grid users would like to obtain X.509 credentials and

VOMS attributes from other credentials and vice-versa• Projects would like to use federated identities• Projects recognize that both national and international

identity federations will become more important• User identities and actions on a Grid should be protected

(anonymized)• Projects realize that access to the majority of Grid

infrastructures requires and will require in the future X.509 credentials


EMI I

NFS

O-R

I-261

611

5

AAI use cases [2]Use-case

Description Status

1 X.509 issuance based on AAI(another security domain)

„Solved“ (but needs improvement!)

2 AAI-enabled portals to Grid infrastructures

Solutions existSAML delegation new

3 AAI-enabled Grid information portals

Low priority

4 Security Token Service New, general purpose service, high priority

5 Use of AAI attributes in Grid Interesting, potentially very important

6 VO registration using AAI (identity vetting)

Low priority


EMI I

NFS

O-R

I-261

611

6

WS-Trust specification [3]

• Builds on WS-Security specification– Methods for issuing, renewing, validating, and

canceling security tokens– Trust relationships brokering

• Security token: a collection of statements (claims) about a user or resource– X.509 certificate, SAML assertion, Kerberos

ticket, Username/Password, …

• Security Token Service (STS): a service used to issue, renew, validate and cancel tokens


EMI I

NFS

O-R

I-261

611

7

WS-Trust schema fragment (1/2)

<xs:element name="RequestSecurityToken" type="wst:RequestSecurityTokenType" /> <xs:complexType name="RequestSecurityTokenType"> <xs:annotation> <xs:documentation>Actual content model is non-deterministic, hence wildcard. The following shows intended content model: <xs:element ref='wst:TokenType' minOccurs='0' /> <xs:element ref='wst:RequestType' /> <xs:element ref='wsp:AppliesTo' minOccurs='0' /> <xs:element ref='wst:Claims‘ minOccurs='0' />  <xs:any namespace='##other‘ processContents='lax' minOccurs='0' maxOccurs='unbounded’ /> </xs:documentation> </xs:annotation> <xs:sequence> <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="Context" type="xs:anyURI" use="optional" /> <xs:anyAttribute namespace="##other" processContents="lax" /> </xs:complexType>

• RequestSecurityToken (RST)


EMI I

NFS

O-R

I-261

611

8

WS-Trust schema fragment (2/2)

<xs:element name="RequestSecurityTokenResponse" type="wst:RequestSecurityTokenResponseType" /><xs:complexType name="RequestSecurityTokenResponseType"> <xs:annotation> <xs:documentation>Actual content model is non-deterministic, hence wildcard. The following shows intended content model: <xs:element ref='wst:TokenType' minOccurs='0' /> <xs:element ref='wst:RequestType' /> <xs:element ref='wst:RequestedSecurityToken' minOccurs='0' /> <xs:element ref='wsp:AppliesTo' minOccurs='0' />  <xs:any namespace='##other' processContents='lax' minOccurs='0' maxOccurs='unbounded’ /> </xs:documentation> </xs:annotation> <xs:sequence> <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="Context" type="xs:anyURI" use="optional" /> <xs:anyAttribute namespace="##other" processContents="lax" /> </xs:complexType>

• RequestSecurityTokenResponse (RSTR)


EMI I

NFS

O-R

I-261

611

9

WS-Trust profiles [4]

• The specification provides an open content model for messages– Provides maximal extensibility, but theoretically

infinite number of messages can be compliant– Profiles need to be defined for achieving

interoperability

• This effort was already started by Chad La Joie in the EGEE-III project– WS-Trust interoperability profile– Token-specific profiles (X.509, SAML, Username)


EMI I

NFS

O-R

I-261

611

10

WS-Trust Interoperability profile

• Base protocol requirements– SOAP-binding, common message format

requirements and processing rules

• Operation-specific requirements• Also, profiles for

– XML-Signature– XML-Encryption– Proof of key possession– Message security (integrity / confidentiality)


EMI I

NFS

O-R

I-261

611

11

STS functionality overview

• Authenticates and “authorizes” users based on security tokens

• Transforms the security token into another security token

• Aggregates required information from external sources

• Establishes a trust relationship between different application domains


EMI I

NFS

O-R

I-261

611

12

STS Example Use Case – SAML to X.509 – (1/2)


EMI I

NFS

O-R

I-261

611

13

STS Example Use Case – SAML to X.509 – (2/2)


EMI I

NFS

O-R

I-261

611

14

STS Implementation Plan (1/2)

• The first version will support the ISSUE operation

• Supported inbound tokens (used for the user authentication):– X.509, X.509 Proxy, SAML, Kerberos

• Supported outbound tokens:– X.509, using external online CA– X.509 Proxy, exploiting VOMS– SAML


EMI I

NFS

O-R

I-261

611

15

STS Implementation Plan (2/2)

• Implementation is based on the upcoming Shibboleth IDP & OpenWS/SAML v3 (Shib3)– Existing building blocks for the service:

• Authentication Engine API• Attribute Authority

– Required extensions:• WS-Trust Profile Handler• Authentication Engine plug-ins for inbound tokens• Token Authority for outbound tokens


EMI I

NFS

O-R

I-261

611

16

References

• [1] EGI TF 2010: AAI needs of the DCIs– https://www.egi.eu/indico/sessionDisplay.py?

sessionId=11&confId=48#20100914

• [2] EMI AAI Working Group– https://twiki.cern.ch/twiki/bin/view/EMI/EmiJra1T4AAI

• [3] OASIS Standard: WS-Trust 1.3– http://docs.oasis-open.org/ws-sx/ws-trust/200512

• [4] Chad La Joie / SWITCH: WS-Trust 1.3 Interoperability profile– http://www.switch.ch/grid/support/documents/


EMI is partially funded by the European Commission under Grant Agreement RI-261611

Thank you!