Security Token Server over http

[anil.saldhana]

Now that we have validated the PicketLink STS  WS-Trust bindings, it is now time to talk more.  We have OpenID bindings in PicketLink that work on the http protocol.  We also have demand for oauth support from resteasy (even though Sergey has an implementation there).

Both OpenID and oAuth operate on the http layer.  They do work on token. OAuth has the request and access tokens.

Since PicketLink STS is capable of generating any token, it should not be difficult for it to manage the openid/oauth tokens.   But the current WSTrustClient/STS combo is tailored toward JAX-WS (SOAP/HTTP) binding.

Proposals:-

• I would like to propose modifications to the STS such that we really have the token generation logic outside the JAX-WS bindings.  I think we are already there with the pluggable token providers.
• Have a pseudo http application fronting the STS to field calls from openid/oauth clients.  For this, we need a new custom client class called PicketLinkHttpClient that has both the openid and oauth calls (internally does the marshalling magic).

At this time, I think the calls will only come on http.  We can think of other transports and utilize JBoss Remoting.

[sergeyb]

Hi

Just wanted to post this link here :

http://www.soatothecloud.com/2010/02/restful-sts.html

I'll be commenting later on as well once I'm a bit more up to speed :-)

[sergeyb]

Hi Anil

Can you expand a bit please on the possible value of having STS OAuth token providers ?

I haven't had time yet to think properly about this kind of integration - at the moment I'll be just dealing with OpenId or SAML by reference driven authentication, without this integration, just to get a better appreciation of how the things are fitting together.

See, OAuth request token is a transient piece of information which is needed to help the client/consumer to prove to the server provider, at the point of requesting an access token, that the end user authorized this request. I guess STS can indeed issue any kind of token, but I'm not yet sure, it will fit neatly into the OAuth (1.0) flow.

But what I'd really like us to discuss is whether it is even worth STS extending to do OAuth. If you'd like to turn STS into the common tokens hub so that PicketLink's capabilities to have token and especially service providers easily configured can be utilized, then may be it can become a really good strategy - but I'd like a bit more discussion around this issue

I'd probably consider prioritizing on REST-ifying PicketLink STS first which is what you suggested above - and I expect RestEasy client support will make it easy to do all the marshalling, etc; this will benefit STS consumers anyway, regardless of how else it may get enhanced 

thanks, Sergey

[anil.saldhana]

In my view, OAuth as we know it, is just a couple of tokens that the token provider has to maintain and then a marshalling layer to deal with the token serialization over http.

The STS as a generic token server is perfectly geared toward this.  Rather than having multiple token server solutions deployed, you can utilize the STS to issue oauth tokens along with any other token that you need.  It is based on the xml namespaces as you know.

One other point that I want to raise is that openid typically covers the authentication aspects whereas oauth is more of an authorization type of specification.

[sergeyb]

Hi

ok, thanks for the comments.

As far as OpenId is concerned, it is indeed about the authentication, about the federated one.

Everyone is saying about OAuth being about authorization which is fine but it is a bit confusing in that it is indeed about the end user authorizing the consumer to access the resources on its behalf, but obviously, the client/consumer needs to authenticate itself as well, when taking part in the OAuth flow.

Example, the client requesting a request token - this is part of OAuth (1.0) flow but the client has to be able to authenticate itself. No authorization token is available in this request. The client is essentially authenticating itself using its client id. But after the client has obtained the access token, and tries to access some resource, the access token will indeed represent the permission to access the resource but as far as the authentication is concerned, it is still the client id.

This is a bit off topic, sorry, but as far as my OAuth-related task (push-messaging related , etc) is concerned, there's a number of issues which needs to be addressed. First is how the consumer will authenticate itself without knowing about sink servers in advance - OpenId and SAML by reference are of interest to me here and I'll be looking into utilizing either of these approaches.

The question about an OAuth provider being a STS token provider is rather orthogonal. This is just one possible option with regard to implementing the provider. Example, OAuth provider can be just backed by DB, as far as keeping the tokens is concerned, which is probably ok, given that OAuth token are 'tied' to specific resources and as such they do not need to be federated or it can be dealt with at the DB layer.

My understanding is that STS is really a trust mediator who can help with building the chains of trust or replace some primitive info like name+password for the SAML assertion by interfacing with some identity managers. Thus having OAuth filter which protects the resources relying on OAuthProvider which in turn needs to do the remote invocation to STS needs to justified and I'm trying to find the very good reasons for doing it.

Hopefully I'll get there :-). As far as STS & HTTP is concerned, I'd consider RESTifying the STS first - this is nothing to do with OAuth per se, but it will make it easier for OAuth filter (through its STS-aware client-side provider) to interact with STS when needed. Note that with JAXRS clients, JAXB is handled OTB, so if a SAML assertion is returned by STS without a SOAP envelope then the JAXRS client will just unmarshall it as needed.

OAuth 2.0 is talking about various types of authorization (access) tokens, some of them can be 'assertions'. Including SAML asserions by value in the HTTP request is problematic/tricky given that either multiparts or some SOAP or ATOM-like envelope structure needs to be utilized, when application-specific messages are also included. Thus SAML by reference might be used as an access token and then OAuth filter would validate it with STS, using either SOAP or plain HTTP (once STS is enhanced) for the authorization decisions to be made.

To summarize, here are the issues which I need to solve/investigate :

- use OpenId or SAML by reference to have all the OAuth players authenticating to each other, without the browser/human user being involved; this is orthogonal to OAuth

- investigate if SAML by reference can be used as the authorization (access) token; usually, OAuth access tokens are randomly generated and may be viewed as SAML assertion references. Thus having an STS OAuthProvider may help to validate such tokens in distributed cases;

thanks,

Sergey