OpenSAML user discussion

["Scott Cantor" <>]

> However we are operating within the limitations laid out by the client.
They
> prefer to not change their preferred approach of using Spring NTLM to
render
> a UsernamePasswordToken. However they insist on using SAML (since it is a
> standard) to propagate a signed SAML token in the HTTP call made out to
the
> RESTful service. They want to embed the Principal (through NameID) in the
> SAML assertion, sign it and pass it into the http request. On the service
> end they want to validate the signature and retrieve the Principal to be
> used further downstream for logging into Filenet Content Engine using a
> Websphere Custom Login Module that operates on Identity assertion with
trust
> validation.

If you're doing that, make sure you omit any SubjectConfirmation from the
assertion and/or use the sender-vouches method, as it's designed for that
use case of simply claiming the identity from the client end.
 
-- Scott