OpenSAML user discussion

[Scott Cantor <>]

> Generating a signature for a request (the same applies for 
> response/assertions) seems to be a two step process.
> 
> a) construct the SAMLRequest with a non-null XMLSignature object
> b) call the method 'sign' on that same XMLSignature object, after 
> optinally adding KeyInfo.

This has been significantly changed in the new version that's mostly in cvs 
now. Most of the dependencies on the XMLSignature
classes are internal to OpenSAML now, and the process is much simpler.

You basically just build your object now and call a sign() or verify() method 
directly on the SAMLSignedObject base class.

It's more or less working, but I have a few isolated bugs to iron out. It 
will be done shortly.

> Questions:
> 1. Are there plans to integrate signature 
> generation/verification into the OpenSAML library directly? Currently it
> appends the signature node with 
> the transformations defined but does not invoke the actual 
> signing, which is done outside.

Right. The signing is still triggered now by a separate method call, but it's 
not done with an xml-security class, only a SAML
class.

> 2. The SAML specs [cs-sstc-core-01] section 5.4.3 says we 
> must use the enveloped-signature transform 
> (http://www.w3.org/2000/09/xmldsig#enveloped-> signature). The 
> OpenSAML library seems to be using XPath 
> filters to achieve the same effect (remove the signature from 
> the request and sign the rest). I just wanted some 
> confirmation that the two methods are equivalent for a valid SAML 
> request/response. If not, are there any more transformations 
> we need to invoke before we sign the request?

SAML is underspecified with respect to signatures. This is being fixed for 
future versions of the spec. I wrote a draft which will
probably be a non-normative appendix to version 1.1 that you can find here:

http://www.oasis-open.org/committees/security/docs/draft-sstc-xmlsig-guidelines-03.pdf

The new guidelines highlight the fact that exclusive C14N is needed in many 
cases, and that for non-simple uses involving SOAP, much
more than the enveloped transform is needed. SAML doesn't yet contain XML ID 
attributes, so it's very non-trivial to properly build
the right transform, and that makes it equally problematic on the verifying 
end.

The new OpenSAML Java code follows these guidelines, and implements two 
different signature transform profiles, "simple" and
non-simple. Simple is just the enveloped transform, and is mainly for the 
POST profile. Otherwise, it uses the XPath2 transforms
that you're seeing now, plus exclusive c14n.

I believe that this will be both correct and secure for the majority of 
cases, while minimizing the work required by the
application.

-- Scott

---------------------------------------------------mace-opensaml-users-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

---------------------------------------------------mace-opensaml-users--