1 / 17

EMI Development Plans for Identity Management

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

hiero
Download Presentation

EMI Development Plans for Identity Management

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. EMI Development Plans for Identity Management Henri Mikkonen / HIP Moonshot, Grid and HPC Workshop 7.7.2011 London, UK

  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) Henri Mikkonen@ Moonshot, Grid and HPC Workshop

  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. Henri Mikkonen@ Moonshot, Grid and HPC Workshop

  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 Henri Mikkonen@ Moonshot, Grid and HPC Workshop

  5. AAI use cases [2] Henri Mikkonen@ Moonshot, Grid and HPC Workshop

  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 Henri Mikkonen@ Moonshot, Grid and HPC Workshop

  7. WS-Trust schema fragment (1/2) • RequestSecurityToken (RST) <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> Henri Mikkonen@ Moonshot, Grid and HPC Workshop

  8. WS-Trust schema fragment (2/2) • RequestSecurityTokenResponse (RSTR) <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> Henri Mikkonen@ Moonshot, Grid and HPC Workshop

  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) Henri Mikkonen@ Moonshot, Grid and HPC Workshop

  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) Henri Mikkonen@ Moonshot, Grid and HPC Workshop

  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 Henri Mikkonen@ Moonshot, Grid and HPC Workshop

  12. STS Example Use Case – SAML to X.509 – (1/2) Henri Mikkonen@ Moonshot, Grid and HPC Workshop

  13. STS Example Use Case – SAML to X.509 – (2/2) Henri Mikkonen@ Moonshot, Grid and HPC Workshop

  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 Henri Mikkonen@ Moonshot, Grid and HPC Workshop

  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 Henri Mikkonen@ Moonshot, Grid and HPC Workshop

  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/ Henri Mikkonen@ Moonshot, Grid and HPC Workshop

  17. Thank you!

More Related