W-15: RE: [security-services] Second use case for the delegation/tiered model

["Mishra, Prateek" <pmishra@netegrity.com>]

Scott,

My question is whether there is any change needed to the web browser
profiles? Or is it the case that the additional step (from intermediate to
back-end service provider) is simply layered on top of the browser to
intermediate step? 


For example, should the identity provider generate an assertion which
indicates in some way that it is "forwardable"? Would that be adequate to
capture a class of realizations?

<Scott>

Issues and Candidate Solutions

The SAML browser profiles permit the end-user to establish a SAML security
context with the meta search service and provide a means of obtaining SAML
attributes for the user, either via push or pull. These attributes would
typically be carried in a separate assertion from the SSO authentication
statement to allow for a longer validity period. However both assertions may
contain a NameIdentifier that cannot be exposed to another entity, a common
privacy requirement in library applications.

If the contents of the NameIdentifier are not significant to the back-end,
then the element could be encrypted for the intermediate service, allowing
it to properly associate any assertions with the user's security context
while permitting it to forward them to the back-end.

A single attribute assertion could potentially be used by both the
intermediate and back-end, although if many back-ends were being contacted,
this could lead to leakage of attributes. The intermediate could communicate
its needs to the SAML authority so that multiple assertions could be
created, or even obtain encrypted attributes for the different back-ends.

If a stronger confirmation than "bearer" were required, then the
intermediate could perhaps request that its key be included in the attribute
assertion(s) as a confirmation key so that it could utilize TLS or the WSS
SAML token profile to attach the token to its SOAP requests. This would be a
more controlled impersonation of the user's attributes.

If demonstration of user presence were required, then the intermediate might
need to obtain an authentication assertion for the user with a
NameIdentifier that was semantically relatable to the attribute assertion it
presents to the back-end. It is conceivable that this could be done by
simply encrypting the NameIdentifier in the original SSO assertion and
enabling the intermediate to forward it.

In the existing browser profiles, there are no clear security concerns being
met by the short validity period of the assertion, because the "packaging"
of the assertion request or delivery process in both profiles independently
enforces the short-lived constraint. However, current SAML practice is not
to sign the SSO assertion, and it is therefore not a forwardable token.

</Scott>