Re: [security-services] W-15 Delegation and Intermediaries - specificsuggestions

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

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

Well, I think it's clear that most intermediate-backend scenarios will
need signed objects.  Whether that's a signed response or a signed
assertion is an interesting question.  I feel as though our response
object is finding use as what I would call a "service ticket" in Kerberos
terms (third-party provides access to specific service for client), but
that we may think that an assertion should be able to fill that role,
independent of embedding in a SAML-protocol object.  The Liberty spin on
assertion is reflective of this.  So I think we need to figure this out.

> 1. Lifetime

So, just to be clear, the reason why lifetime is an issue is that the
intermediate will probably need to use an assertion containing an
authentication statement to interact with either the backend or a SAML
authority, and will want to be able to do that at arbitrary times after
initial authentication.  This is similar to, but perhaps not identical to,
the requirement to express lifetime for session purposes, as Scott
mentions.  As far as I'm concerned, a single lifetime is sufficient for
both.

> 2. SP Impersonation

As I think I've said before, there is an appealing use case of achieving
impersonation in the intermediate-backend protocol by having the
intermediate simply pass the SAML response object (which the intermediate
received as part of browser profile operation) to the backend as evidence
for the desired impersonation.  Obviously this would require a mechanism
to pass the response in the relevant protocol (and this doesn't mean SOAP
only).  I think this would be acceptable in many common trust arrangements
between intermediate and backend, assuming the response is signed, given
that the response specifies subject, intermediate (as recipient or
audience), validity and issue times.  The work item would be describing
this flow precisely and the security considerations related to it.  The
main appeal is that it requires no change at all to any existing schema or
profile.

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

Scott describes new mechanisms to give the intermediate a SAML object that
would be more suited to achieving impersonation.  One way of thinking
about this is permitting different management of the policy regarding the
intermediate's ability to impersonate.  In the case I describe above, the
backend gets info from the intermediate saying "I'm the intermediate,
here's a SAML response I got from the user, please let me impersonate the
user", and the backend has to evaluate whether the intermediate is
permitted to do this.  A method whereby the intermediate trades in the
user's SAML response for something else permits its info to the backend to
instead be "I'm the intermediate, here's an assertion from an authority
saying that I can impersonate this user".  The appeal in this is that the
backend can just accept this and not have to be responsible for the
evaluating the intermediate's impersonation capability.