OpenSAML user discussion

["Scott Cantor" <>]

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

Hmm, that probably should be cleaned up.

> This MUST makes the use of the metadata attribute "WantAssertionSigned"
> that Tom pointed to in the other posting, even more confusing:

It has little to do with SSO generally, but in most cases the point of the
attribute is to indicate behavior "above and beyond" what a given profile
requires. If you read the spec, the language is:

"This requirement is in addition to any requirement for signing derived from
the use of a particular profile/binding combination."

In other words, if there's a MUST in the profile, it doesn't matter what it
says.

> The POST and Redirect bindings' rules would override this attribute
> leaving only the Artifact binding to be influenced by its setting. Is this
> correct?

Redirect cannot be used to carry a signed assertion, it wouldn't fit (more
accurately the signature won't). The only bindings you have are POST and
Artifact, but yes, it could influence an Artifact implementation.

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

No, because that's protocol signing, not payload. Furthermore, signature
syntax is binding dependent (e.g. Redirect and the new POST/Simple-Sign
proposal both use non-XML Signature mechanisms, but they still take a common
set of inputs. Making it the encoder's job eliminates a lot of extra
per-binding work for apps. I think it works well.

Payload, though, is separate. The only kind of payload where this even comes
up is assertions, and they need to be constructed ahead of time and placed
into the response message as required. Then the encoder will sign the
Response, or not.

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

It shouldn't be terribly onerous and it doesn't come up all that much.
Moreover, the reality is that you'll almost always want to sign them. Many
use cases chained off of SSO at the SP require it anyway.

-- Scott