Enhancing Identity Management with WS-Trust Protocol
170 likes | 280 Vues
Develop identity management plans for AAI using WS-Trust protocol. Discuss motivation, questionnaires, AAI use cases, technology, and implementation security measures. Presentation at Moonshot, Grid, and HPC Workshop 7.7.2011 in London, UK. Explore STS, interoperability, and token profiles.
Enhancing Identity Management with WS-Trust Protocol
E N D
Presentation Transcript
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 • Security Token Service (STS) Henri Mikkonen@ Moonshot, Grid and HPC Workshop
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
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
AAI use cases [2] Henri Mikkonen@ Moonshot, Grid and HPC Workshop
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
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
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
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
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
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
STS Example Use Case – SAML to X.509 – (1/2) Henri Mikkonen@ Moonshot, Grid and HPC Workshop
STS Example Use Case – SAML to X.509 – (2/2) Henri Mikkonen@ Moonshot, Grid and HPC Workshop
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
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
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