OpenSAML user discussion

[Sidhartha Priye <>]

Thanks Scott,  Will look into that. Also will certainly add my findings to 
the wiki. I have to write one anyhow for my internal use. 


As for RESTful approach, I read on one of the blogs
http://weblogs.asp.net/cibrax/archive/2009/03/06/brokered-authentication-for-rest-active-clients-with-saml.aspx

that you can inject the token in the HTTP Header (Authorization field) .


WebRequest webRequest = HttpWebRequest.Create(address);
webRequest.Method = "GET";
webRequest.Headers["Authorization"] = token;

and implement a message interceptor on the Relying party Service end that 
will process the token and validate the request

    result.Interceptors.Add(new 
MessageInterceptors.SamlAuthenticationInterceptor(new 
TrustedIssuerNameRegistry()));

Is this viable approach given this blog talks about Geneva as their 
underlying implementation. 


Somewhere else I read about RESTful STS which talks about a similar approach 
- 

http://ws-security.blogspot.com/2010/02/integrating-rest-clients-with-sts-for.html

From the blog - 


"In such scenarios, following flow would be applicable

        1. REST 
client acquires token from the STS server preferably through REST 
binding of STS, but any other supported binding should also be okay.
        2. Once it receives the token, it adds it to the "Authorization" HTTP 
header of the REST request.
        3. REST service receives the request, and a 
security interceptor(agent) picks up the token to check for access 
validity. The interceptor can optionally assert the identity into the 
service for identity propagation needs."
I am speculating when they are talking about tokens, they are referring to 
SAML assertions. If that being the case, you did mention that SAML cannot 
adapt to OAuth because Assertions cannot be serialized into headers. 

Can you please throw some more light. 

thanks
Sid





----- Original Message ----
> From: Scott Cantor 
> <>
> To: 
> 
> Sent: Wed, March 3, 2010 4:35:39 PM
> Subject: RE: [OpenSAML] local part cannot be "null" when creating a QName 
> during unmarshalling an Assertion object
> 
> > I have managed to resolve the issues on my end and can assert and validate
> a
> > SAML2.3 token to the CXF webservice deployed on Websphere 6.1. The issue
> > turned out to be more a configuration one with some jars that were on the
> > classpath that was probably building a broken DOM. Its a nightmare getting
> > to deploy Spring/SAML/CXF on to Websphere 6.1 with the SUN jars in the
> mix.
> 
> One of the reasons for that is that people don't provide back any
> documentation on all the esoteric combinations they get working even though
> there's a wiki that anybody can register in and edit.
> 
> > That being said, I am now trying to implement a RESTful SAML approach and
> > looking for directions
> 
> REST has limited support for message-based security models. OAuth's
> unrelated portions that are really attempting to fix HTTP security are an
> example of one approach, but not one that SAML can adapt to because
> assertions don't fit into HTTP headers.
> 
> Our (Shibboleth's) approach has been to stick to models based on
> session-level security that are consistent with web SSO, posting assertions
> to get back a cookie and then relying on the cookie. This happens to be
> compatible with existing SP software and allows REST based services to be
> secured with the same code as browser facing services, or offer both at
> once.
> 
> https://spaces.internet2.edu/display/ShibuPortal/Home
> 
> -- Scott