W-15 Delegation and Intermediaries - specific suggestions

[Scott Cantor <cantor.2@osu.edu>]

The chairs are "eager" to move this work item forward, so now that I have a
slightly better sense (in my head at least) of what the SAML 2.0 SSO
protocol might look like, I propose a bit more detail.

None of this accounts for or offers a resolution to the questions around how
to synch up SAML and ID-FF SSO, which have some low-level differences. I
will say that this work item isn't going to get very far in certain
directions without a signed assertion delivered during SSO. Whether that
leads to multiple signatures (and whether that's realistically possible) I
leave for the reader.

1. Lifetime

RL Bob already mentioned changing the assertion validity to represent the
token/session lifetime instead of the bearer delivery window. As of now,
about the only loss of function to that I see is the IdP having some control
over that window instead of leaving it to the SP.

A related change would be adding the ability to request the SSO assertion
with a specific validity lifetime, which probably has some relation to the
session question. As it stands now, without an explicit session construct
presented (so far), I would be inclined to say that the lifetime of a SSO
assertion should correspond to the session length indicated to the SP by the
IdP (obviating the need for the ID-FF <ReauthenticateOnOrAfter> element).

2. SP Impersonation

It should be possible for an SP named in the assertion (an Audience) to go
back to the IdP and exchange that assertion for a new one that asserts the
SP's right to authenticate to another SP as the original principal. This
would be subject to policy set for the principal. I don't think (but could
be wrong) that any flags or bits are really needed in the request or
assertion to control this if the SAML authority is the exchange point. I
also think this is probably just an AuthnRequest SOAP message with the
original assertion included somehow. Maybe WSS, but I'm inclined to say it
might fit better as data within the request, since it's not really
authenticating the SP.

The signed assertion returned would name the new SP as the relying party,
probably would have a lifetime within that of the original, and if a
privacy-preserving NameIdentifier was in use, could be newly generated or
appropriately protected. For example, it could be a federated identifier
shared between the IdP and the new SP, encrypted so as not to expose it to
the original SP. It could also (and probably should) have a stronger subject
confirmation like holder-of-key, so the original SP could sign it into
messages to the new SP or authenticate with X.509 to prove the confirmation
to the new SP.

As described, this would be simple impersonation. If we wanted to do a bit
more work, delegation could be introduced to expose both the identity of the
principal and of the proxying SP. Related to this, we might want to
standardize a control condition to limit the repeating of this exchange
process (preventing it from hopping back another link from the new SP).

We want to keep this all easy to implement and understand. That's SAML's
strong suit, and I don't propose to suddenly make it a hugely complicated
mess.

3. SSO with stronger SubjectConfirmation

Several people have noted that there are cases where doing SSO without using
bearer confirmation make sense. The Kerberos discussions are one such case.
Another I can think of that may or may not be of interest is browsers with
X.509 certs, with the public key bound in as the confirmation key. The use
case is to validate the cert at the SP by proxy through the signature of the
IdP around the key in the assertion. This is especially interesting with
shorter-lived certs that might be generated on the fly for the browser
perhaps with Kerberos in the mix (see Michigan's KX509 work):

http://www.nsf-middleware.org/documentation/NMI-R2/0/KX509KCA/

In general, any time the client can prove possession of a key to both the
IdP and the SP (whether over HTTP, or SOAP, or something else), it can go
into the SSO assertion so we should spec that. I think this can be
generically described around a single AuthnRequest message delivered to the
IdP over various bindings to address the non-browser use cases. Some will
result in a bearer assertion and some not, but I think it all works.

4. Non-SAML tokens delivered during SSO or AttributeQuery

RL Bob's second bullet I think can be addressed by standardizing the
carriage of some token formats as SAML attributes, base64 encoded in some
cases, obviously. But we should pick standardized names for Kerberos tickets
and the like. I don't know enough technical detail about Kerberos at the
lowest level to know exactly how this will work, or what exactly has to be
passed in the attribute to permit an SP to authenticate to a Kerberized
service.

I am prepared to help produce concrete spec for these proposals once the
designs or variants of them are accepted. I've got a lot of work items
though, and some of this pushes the technical envelope for me anyway, so
help would be welcome.

-- Scott