OpenSAML user discussion

[Sidhartha Priye <>]

Thanks Scott for the detailed explanation, 

In our case I am not sure if I can completely integrate the Shibboleth's 
WebSSO solution you are proposing because there is already IDP initialized 
through a third party IDP that provides us the NTLM token obtained through a 
windows logon. Our custom Spring SSO solution gives us the User Token and 
more specifically the principal. 

So all we have to do now is issue an HTTP POST (preferred to HTTPRedirect 
which uses a GET) binding to the Service Provider (SP) in the form of a 
<samlp:Response> and pass the serialized encoded signed assertion using the 
protocol message exchange. 

So here is what I am thinking I need to do 

1. Build the Assertion myself (rather than through asamlp:AuthnRequest to an 
IDP)
2. Serialize and encode the XML message and push it into the samlResponse 
hidden field (using HTTPClient. I think you already have a library that will 
give me an instance of HTTPClient through the SAMLSession)
3. Request the assertion consumer service with samlpResponse
4. Service creates a security context (is this the session affinity for 
future requests) and redirects to the target resource. 

Please confirm if this approach will work and I am looking for code samples 
to get me started. 

thanks
Sid



----- Original Message ----
> From: Scott Cantor 
> <>
> To: 
> 
> Sent: Wed, March 3, 2010 5:23:19 PM
> Subject: RE: [OpenSAML] local part cannot be "null" when creating a QName 
> during unmarshalling an Assertion object
> 
> > 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) .
> 
> Assuming you're ok with it breaking on a lot of web servers, sure. Headers
> are quite limited in size in many configurations.
> 
> > Is this viable approach given this blog talks about Geneva as their
> > underlying implementation.
> 
> If it works on IIS, then presumably they've left the header limits very
> relaxed, but it won't fly on Apache in most cases.
> 
> > 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.
> 
> You can put anything into a header but that doesn't make it fit. OAuth is
> optimized for small bearer tokens issued by the service you're sending the
> request to. Once you split the issuer off, you need a standard format, and
> you need semantics that bloat the size. More importantly, you need a
> signature and you're blown.
> 
> Besides that, you're gaining...nothing. Most use cases include messages back
> and forth and it's not efficient to process a signed token on every request,
> and you'll end up with a cookie-like thing anyway. So the choice is an
> inefficient mechanism that's proprietary and doesn't support sessions
> directly, or a mechanism based on a standard SAML profile and assumes
> session semantics already provided by the SSO software.
> 
> -- Scott