emi development plans for identity management
DESCRIPTION
EMI Development Plans for Identity Management. Henri Mikkonen / HIP Moonshot, Grid and HPC Workshop 7.7.2011 London, UK. Content. Motivation Questionnaires to potential customers AAI use cases Technology Introduction to WS-Trust WS-Trust interoperability & token profiles Implementation - PowerPoint PPT PresentationTRANSCRIPT
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.
07/07/2011 Henri Mikkonen @ Moonshot, Grid and HPC Workshop
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
07/07/2011 Henri Mikkonen @ Moonshot, Grid and HPC Workshop
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
07/07/2011 Henri Mikkonen @ Moonshot, Grid and HPC Workshop
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
07/07/2011 Henri Mikkonen @ Moonshot, Grid and HPC Workshop
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' /> <!-- …22 other optional elements… --> <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)
07/07/2011 Henri Mikkonen @ Moonshot, Grid and HPC Workshop
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' /> <!-- …15 other optional elements… --> <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)
07/07/2011 Henri Mikkonen @ Moonshot, Grid and HPC Workshop
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)
07/07/2011 Henri Mikkonen @ Moonshot, Grid and HPC Workshop
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)
07/07/2011 Henri Mikkonen @ Moonshot, Grid and HPC Workshop
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
07/07/2011 Henri Mikkonen @ Moonshot, Grid and HPC Workshop
EMI I
NFS
O-R
I-261
611
12
STS Example Use Case – SAML to X.509 – (1/2)
07/07/2011 Henri Mikkonen @ Moonshot, Grid and HPC Workshop
EMI I
NFS
O-R
I-261
611
13
STS Example Use Case – SAML to X.509 – (2/2)
07/07/2011 Henri Mikkonen @ Moonshot, Grid and HPC Workshop
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
07/07/2011 Henri Mikkonen @ Moonshot, Grid and HPC Workshop
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
07/07/2011 Henri Mikkonen @ Moonshot, Grid and HPC Workshop
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/
07/07/2011 Henri Mikkonen @ Moonshot, Grid and HPC Workshop
EMI is partially funded by the European Commission under Grant Agreement RI-261611
Thank you!