PicketLink 2 :: STS API Discussion

[anil.saldhana]

I want to dedicate this thread to discuss the possibilities for a generic API for the STS to cater to the various FIM standards/tech available such as SAML2, WS-T, OpenID and OAuth.

It is my belief that all token formats can be captured into a select set of representation and can be handled by a generic STS.

The API needs to:

1. Issue a token
2. Validate a token
3. Renew a token
4. Cancel a token.

Let us look at the various technologies/standards that we want to support:

Standard	Token Format	Reference
SAML2	XML
WS-Trust	XML
OpenID	Binary	http://dev.aol.com/OpenidTokenExchange
OAuth	Binary	http://tools.ietf.org/html/draft-ietf-oauth-v2-10

My initial take is to go with the token format in the API to be byte[].

[anil.saldhana]

Currently the STS TokenProviders are wired to the WSTrustContext.  I think it makes sense to change the interface to use STSContext  and have:

• WSTrustContext implements STSContext.
• OpenIDContext implements STSContext   etc.

[mdecke]

I am currently working on WS-Trust Negotiation/Challenge for Picketlink, as mentioned here http://community.jboss.org/thread/155702

It is in a very early stage merely proof of concept.

I think it is good idea to have a interface STSContext and maybe a WSTrustNegotiationContext since there is a lot of extra communication between client and server. I think it makes sense to maybe distinguish WSTrust with and without Negotiation/Challenge.

[anil.saldhana]

Markus, are you planning to contribute your work to PL?  The reason is that we do plan to work on this in the near future.

[mdecke]

I would like to contribute to PL especially the WSTrust-Negotioation/Challenge Handling.

Currently my code is in a proof-of-concept state for Idemixtoken issuing, where I needed WSTrust-Negotiation/Challenge handling.

I added a lot of code directly into some classes for this, without changing the overall structure of PL.

I would like to add redesigned parts of it, so it fits nicer into PL.