OpenSAML user discussion

[Xavier Drudis Ferran <>]

On Fri, Apr 24, 2009 at 11:27:16AM -0400, 

 wrote:
> when I printout the opensaml SAMLRequest before it is send, I have this
> <Request xmlns="urn:oasis:names:tc:SAML:1.0:protocol" 
> xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" 
> xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" ...
> 
> the webserviceclient puts this in the body:
> <samlp:Request xmlns="urn:oasis:names:tc:SAML:1.0:protocol" 
> xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" 
> xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" ...
>
> which is also valid xml but the signature on the samlRequest is broken now 
> (samlRequest.verify() on serverside throws an exception).

I thought there was some canonicalization method that 
ignored those changes, but I don't remember which 
and maybe it is not usable for this case. But you may want
to have a look at the definition of canonicalization 
methods in XML-Signature if you can afford to change
it (I guess you can). 
 
> 
> Have you guys stumbled on this problem before ?

Not I.

> How to deal with namespace prefixes in signed samlRequests?

I think that by specifiying the right canonicalization, but I'm not sure.

> Is there anything I should do on clientside/serverside before 
> signing/verifying?

set some canonicalization attribute on the empty signature before
generatign the signature value, I guess.

> I think I can work around this by defining as input of my webmethod a 
> simple String in my wsdl instead of the saml request element of the saml 
> protocol schema but if possible, I want my interface to clearly define it 
> only accepts SAMLRequests.
> 

I hope you can do it. 

-- 
Xavi Drudis Ferran