OpenSAML user discussion

["Scott Cantor" <>]

> 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.

> 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.

> 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.

-- Scott