OpenSAML user discussion

[Andreas Vallen <>]

Hello Scott,

Scott Cantor wrote:
> > The version of the Sun Access Manager product that we test our opensaml-
> > based IDP against, expects the Assertion element instead of the Response
> element
> > to be signed (in the case of successfull Responses).
> > This is clearly a Access Manager bug - it should work either way.
>
> It's not a bug. At least, when using POST. You MUST sign the assertion, and
> MAY sign the response. See line 600.

Ouch. I didn't interpret it that way until now, instead thinking that signature 
inheritance as described in saml-core applied if the response element was signed.

This MUST makes the use of the metadata attribute "WantAssertionSigned" that Tom pointed 
to in the other posting, even more confusing:
The POST and Redirect bindings' rules would override this attribute leaving only the 
Artifact binding to be influenced by its setting. Is this correct?

> > See below for our changes to one of the Encoder.encode methods that makes
> > this behaviour configurable.
>
> No, encoders should NOT touch payload, ever. They know nothing of profiles.
> The job of assertion signing is outside of the encoder concept entirely.

Yes, that makes sense. Shouldn't also the request/response signing removed from the 
encoders for the same reason?

> > If you find this additional configurability is worth the added complexity,
> > maybe it also would be possible to extract the (newly convoluted) signing
> > behaviour into its own class to make it reusable by the various Encoders.
>
> The entire issue is out of scope of that set of classes. It is for other
> layers to deal with. It may or may not ever be something OpenSAML includes
> code for, but at this point I would doubt it.

> To do an IdP, you would make decisions about whether to sign the assertion
> before you ever invoke an encoder. That may influence whether you pass a
> signature instruction to the encoder, but that's not something the encoder
> knows anything about.
>
> I do NOT advise you to subclass encoders for this purpose. You're mixing
> layers and I would avoid that, so that your profile code will be binding
> independent as much as possible. You might use the response binding to
> decide what to do with the payload, but that's not as invasive as
> subclassing.

Thanks for your advice. While that means that we'll have to make our profile code 
dependent on the employed repsonse binding, that really seems like the more appropriate 
distribution of responsiblity.

Sincerly,
Andreas