Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Normalize Authn Service 1.1 to WRAP?

Hello,

I'm working on normalizing Authn Service 1.1 according to  Web Resource Authorization Protocol  (WRAP) v. 0.9.7.1 But I'd like to discuss Access Token format.

 WRAP does not define format of the Access Token, but mentions the Simple Web Token (SWT) like possible  Access Token formats (see 6.3, 4.1), btw,  higgins already has  SAML support, so let compare  them. 

WRAP (4.1)  defines the following  Access Token requirements:
 *  Protected Resources MUST be able to verify that the Access Token was issued by a trusted Authorization Server and is still valid. 
 * Access Tokens SHOULD periodically expire. 
 * Access Token may  be delivered by using HTTP Authorization header or URL parameter or POST parameter.

SAML token may be  the best choice for WS conversation by using SOAP header. However WRAP assumes to send Access Token by using HTTP header or URL parameter, but the size of all HTTP headers ranging from 4KB to 16KB. SAML is not compact so it may not so good choice to WRAP. We could use SAML without WRAP, when we was going to send Access Token just ones by using POST request, and after that using  the Session Token. 

Simple Web Token  is compact and formatted to be easily included in HTTP header.  Set of assertions (name/value pairs) should be encoded by using application/x-www-form-urlencoded per 17.13.4 of HTML 4.01. However SWT requires to use SHA 256 HMAC. It assumes that both Auth Service and Protected Service  (Attribute Service, CardSync) must know secret HMAC key for calculate/validate HMAC digest, but  SWT doesn't define how to distribute HMAC key between all services.   

Auth service may generate new  HMAC key each time,  encrypt it by using Protected Service public key and include it in the Access Token. 
 
The other option may be using RSA-SHA-256 signature instead of HMAC-SHA-256, but it will be incompatible with SWT.  I tend to implement it.


Latest WRAP and SWT specifications available  at http://groups.google.com/group/oauth-wrap-wg/files .

Please let me know your concerns, suggestions.

-- 
thanks,
Alexander Yuhimenko

On Mon, 9 Nov 2009 15:16:16 +0200
Alexander Yuhimenko <AYuhimenko@xxxxxxxxxxxxxx> wrote:

> Thanks Tom,
> 
> I'd like to update Auth Service 1.1 according to WRAP '5.3 Username and Password Profile'. 
> 
> We have to add the following changes:
>  * use  'application/x-www-form-urlencoded'  format for encoding request/response parameters (Auth Service supports XML and Protobuf);
>  * use SWT format for Access Token instead of SAML due to limited http header size, it's usually 8k-16k, but tomcat default is just 4k;
>  * use  Access Token instead of Session Token, so doesn't use Seesion token at all;
>  * add refresh Access Token method according to 5.3.7 - 5.3.9;
>  * update  request Access Token  method according to 5.3.3 - 5.3.6.
> 
> Paul, Valery are you agree?
> 
> 
> However, WRAP doesn't define API for provisioning and updating  user account, so we may leave it as is (using XML/Protobuf), or redefine it in WRAP way?
> 
> -- 
> thanks,
> Alexander Yuhimenko
> 
> On Thu, 5 Nov 2009 20:43:49 -0800
> Tom Carroll <TCarroll@xxxxxxxxx> wrote:
> 
> > Today I saw the WRAP protocol [1] presented at IIW. WRAP is a proposed new version of OAuth that separates the authentication service from the protected resource. If you take a look at WRAP's "username-password" profile, it looks incredibly similar to our Auth Service 1.1. It even contemplates that the client would have been provisioned with a unique identifier (eg 'serialized selector'), but doesn't get into the details of how this would happen, since the protect resource doesn't need to know anything about that.
> > 
> > One difference I see is that in Higgins Authn Svc 1.1, the Access Token (AT) is exchanged for a Session Token at the protected resource, while in WRAP, the AT is sent with every request, and the protected resource just responds. There is no session - it is stateless. Other than that, it seems virtually identical, just a matter of naming conventions.
> > 
> > Anyway, I was thinking that it might make sense to normalize the Authn Service 1.1 protocol to match a profile of the WRAP protocol, or perhaps suggest tweaks or a new profile to WRAP that fits our needs if the un/pw profile doesn't quite fit. It would be good to take a broader community approach, rather than a Higgins-only approach.
> > 
> > [1] http://groups.google.com/group/WRAP-WG
> > 
> > 
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> 



Back to the top