AuthnRequest and intermediary use cases (long)

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

I did some mental diagramming of messages and some comparisons back to the
sort of "usual" browser use cases following all the discussions today, and
I'm starting to spot some of the differences and similarities and how they
might impact the possible solutions.

I believe that one of the important distinctions to make is around the fact
that sometimes the goal is to ask for authentication and a resulting
authentication assertion to be produced, and sometimes what you're after is
an impersonation token (as a SAML assertion) that you get by authenticating
as an intermediary and optionally supplying some other credential not your
own. There are obviously others, but those are the two that really seemed to
underlie the diagrams.

Greg also noted that some of what we're doing starts to resemble a CSR in
the sense that most of what goes into an assertion is really the same stuff
that an intermediary might want to supply to the authority as a template for
the assertion that it wants. This includes things like validity, subject and
confirmation, audiences, etc.

I would like to be able to think of an AuthnRequest as a special case of
this in which the desired subject is implied as the entity authenticating to
the authority (the principal, in the browser or ECP cases). The usual ID-FF
use case is that the SP issues the request (possibly signing it) and the
principal relays it to the IdP, with the result being an authentication
assertion about the principal for the SP.

I believe that this basic message flow can apply to the Kerberos and SOAP
client uses cases in which the entity requesting the assertion can
authenticate as the principal that should be the assertion subject. That is,
any impersonation going on is outside SAML. The client/IdP authentication
is, as now, left undefined. It can be Kerberos, X.509, a WSS profile, or
whatever.

I'm not prepared to argue that this is or should be the only way one could
imagine a SOAP client requesting an assertion in exchange for some other
authentication token. But I think it is one way and the one that is
internally consistent with our other use cases within SAML.

With a small addition, it should be possible to request stronger
confirmation methods than bearer. Further, it should be possible to request
that the Audiences in the assertion be such that it would be usable at
multiple services, which would support the case of forwarding a single token
directly from service to service (provided a shared NameIdentifier existed
and the policies in place permit it). This was Bob's use case for
impersonation among intermediaries that strongly trust each other.

Looking at the other use cases that devolve into an entity authenticating to
a SAML authority (again, in some arbitrary way) and asking for an assertion
with a different subject, I'm trying to see this as an extension of this
more basic AuthnRequest (possibly a different message, perhaps
AssertionRequest) in which the desired Subject and Audiences are explicit.
Further, I could see using SubjectConfirmation inside that Subject to pass
in tokens that confirm the impersonation in some way (such as a SSO
assertion or a Kerberos ticket).

The result of this request, if policy is satisfied, would be an assertion
(with the desired Subject and Audiences) and a confirmation method that
might be holder of key or might be something new. Either way, the
confirmation "key" or data would be a second assertion that contains an
authentication statement about the intermediary, again with holder of key,
the key being that of the intermediary. The whole bundle is basically signed
once.

A fragment to illustrate:

<Assertion>
    <AttributeStatement>
    <Subject>
    <NameIdentifier>Joe Shmo</NameIdentifier>
        <SubjectConfirmation>
            <ConfirmationMethod>assertion</ConfirmationMethod>
            <ConfirmationData>
                <!-- inner assertion confirms the outer -->
                <Assertion>
                    <Subject>
                    <NameIdentifier>man-in-the-middle</NameIdentifier>
                        <SubjectConfirmation>
                            <ConfirmationMethod>holder of key</...>
                            <ds:KeyInfo>middle man's key</ds:KeyInfo>
                        </SubjectConfirmation>
                    </NameIdentifier>
                    </Subject>
                </Assertion>
            </ConfirmationData>
        </SubjectConfirmation>
    </NameIdentifier>
    </Subject>
    <Attribute>...
    <Attribute>...
    </AttributeStatement>
</Assertion>

The semantic is that the holder of the key of the inner assertion confirms
the subject confirmation of the outer assertion, which gives the relying
party what it needs to recognize and accept (or not) the impersonation.

These assertions might be usable as confirmation tokens in a subsequent
AssertionRequest that could bridge to a second hop. The authority would be
responsible for rewriting the assertions as needed to protect the
principal's privacy using EncryptedNameIdentifiers.

Ron and I discussed the differences between this and the
KeyInfo/SecurityTokenReference approach in WSS, which I see, but I found it
useful to examine this from a SAML perspective first.

-- Scott