Security Token Service (STS)Design & Development Plans

Henri Mikkonen / HIP3rd EMI All-Hands Meeting

17.-19.10.2011, Padova, Italy

EMI I

NFS

O-R

I-261

611

Content

• Short Recap• Overall Architecture for STS• WS-Trust Profile Handler Design• Token Authority Design• Client Toolkit• Schedule

17/10/2011 STS Design & Development Plans 2

EMI I

NFS

O-R

I-261

611

Recap: Security tokens? STS?

• Security token is a collection of statements/claims about a user or resource, attached into a message– X.509, SAML assertion, Kerberos ticket, Username/Pwd– Defined in the WS-Security specification & profiles

• STS is a service used to issue, renew, validate and cancel security tokens– “Transforms security tokens from one format into

another format”– Defined in the WS-Trust specification

17/10/2011 STS Design & Development Plans 3

EMI I

NFS

O-R

I-261

611

Issue Operation Sequence

1. Decode the request: decode, decrypt, etc2. Validate the request: signatures, SSL/TLS, replay,

timestamps, policy conformancy..3. Validate the claims: extract & validate4. Resolve attributes: resolution & filtering5. Issuance of the security tokens: use the collected

data & possibly use external sources6. Create the response: generate the RSTR, possibly

encrypted & signed

17/10/2011 STS Design & Development Plans 4

EMI I

NFS

O-R

I-261

611

Overall Architecture (1/2)

17/10/2011 STS Design & Development Plans 5

Components in green boxes are provided by Shib3, yellows to be implemented

EMI I

NFS

O-R

I-261

611

Overall Architecture (2/2)

• SOAP Client: Any client holding a security token and capable of producing RST messages and understanding RSTR messages

• WS-Trust Profile Handler: Orchestrates the profile sequence between the components

• Token Authority: Issues the requested security tokens by using appropriate token generators

• Token Generator: Issues a requested security token, possibly exploiting external sources

17/10/2011 STS Design & Development Plans 6

EMI I

NFS

O-R

I-261

611

WS-Trust Profile Handler

• Shib3 Request Dispatcher sends the appropriate requests to the profile handler

• Profile consists of a sequence of states in a flow• Implementation uses Spring WebFlow

– Set of actions containing the logic of the flow

• All the actions exploits (possibly updates) profile request context, the current “state” of the profile

17/10/2011 STS Design & Development Plans 7

EMI I

NFS

O-R

I-261

611

Token Authority Overview

17/10/2011 STS Design & Development Plans 8

Components in green boxes are provided by Shib3, yellows to be implemented

EMI I

NFS

O-R

I-261

611

Token Generators

17/10/2011 STS Design & Development Plans 9

• Three supported security token formats– X.509, X.509 proxy, SAML assertion– Plugin-mechanism for supporting additional formats

• X.509 generator already implemented, CMP protocol currently supported for online CA connection– Support for MyProxy and others possible

• SAML assertion will be constructed using existing Shib3 WebFlow actions

EMI I

NFS

O-R

I-261

611

Client Toolkit

• Client Toolkit is a Java-library, helping in:– Generating the security tokens

• From file system: X.509 certificate, proxy• From an IDP: SAML assertion (ECP profile)• From a KDC: Kerberos ticket

– Generating the request messages– Communicating the messages with STS– Extracting the response messages

• Storage of the security tokens

• Toolkit can be utilized in client UI or in the integration with services (e.g. portals)

17/10/2011 STS Design & Development Plans 10

EMI I

NFS

O-R

I-261

611

Schedule

• Shib3 is in development phase, full functionality expected during the autumn– The most important APIs are already stable– First release expected 2012Q1

• Current allocations for the development– Henri Mikkonen / HIP, 60%– Valery Tschopp / SWITCH, 30%

• First version of STS scheduled to 2012Q2

17/10/2011 STS Design & Development Plans 11

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

Thank you!

17/10/2011 12STS Design & Development Plans