Signing multiple objects?

[Brad Cox]

In this case, we do control both ends and XPath is there if we need it. This
is for securing messages between PEP, PDP, Policy Service and Attribute
Service in an authorization management system, all of which we control. The
goal is a SAMLProcessor library that the four services will all use.

I'd rather not have this restriction, of course, and that the solution be
fully interoperable. But the signing spec is so over to the top in this case
that I'd be happy to get something that works at all. The spec is far beyond
what any impl I know of will support.

Any suggestions on where to start?

On Mon, Oct 24, 2011 at 8:59 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 10/24/11 8:51 PM, "Brad Cox" <bradjcox at gmail.com> wrote:
>
> >I'm trying to meet stringent DOD security requirements that require that
> >several elements in the headers be signed. Actually the body too, but
> >presumably just the payload but am not sure, so I've left body signing
> >aside for now). For example, the Timestamp, MessageID, and SAML Assertion
> >should all be signed.
>
> It's extremely complex to do that in a way that isn't vulnerable to
> wrapping attacks. You need XPath or a lot of control over the application
> on both ends.
>
> >I have Assertion signing working now, but am stumped on Timestamp and
> >MessageID since these come from xmltooling and don't comply with
> >SignableSAMLObject.
>
> I don't believe there is any built-in support for WS-Security message
> signatures. We haven't ever analyzed how it would be handled or how to
> make it safe.
>
> The safest thing is to sign the whole message. A whole document reference
> isn't usable with SOAP intermediaries, but it is secure.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
>



-- 
Cell: 703-594-1883
Blog: http://bradjcox.blogspot.com
Web: http://virtualschool.edu
Manassas VA 20111
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20111025/f1644ccd/attachment.html