Re: [security-services] AuthnRequest and intermediary use cases (long)

[Ron Monzillo <Ronald.Monzillo@Sun.COM>]

Scott,

This sounds good to me. Some questions/comments inserted.

Scott Cantor wrote:

>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.
>
I agree that being able to specify the confirmation method and the 
target audiences
is important. I would include in the former the ability to request an 
assertion that
can be confirmed by one and perhaps more specific entities.

>
>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).
>  
>
I think you may be suggesting that the AuthNRequest service be generalized
to something  more clearly neutral WRT to the returned assertion type. 
If so,
I agree.

It seems to me that we would need to model the identities of four
parties in the service invocation

1. the entity requesting the assertion
2. the entities able to use the returned assertion.
3. the subject of the returned assertion.
4. the target services (audiences?) at which the assertion may be used

It seems that 1 should be handled at the service binding layer, while
2, 3, and 4 should be handled within the service specific protocol msgs.

It would seem to me like 2 should be conveyed by allowing the assertion
requester to provide one or more SubjectConfirmation elements as part
of the request.

>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.
>
I am in favor of this semantic, and I would like to be able to apply
it more generally, such that SAML assertions can be used to authorize
impersonation identities represented in other (than SAML) types of key
bearing tokens.

By this I mean, where the top level token is a SAML assertion,
and it encapsulates tokens of other forms that identify the keys of
entities authorized to impersonate the subject of the SAML assertion.

>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.
>  
>
Being able to use an impersonation authorizing assertion to
get another impersonation authorizing assertion from the token service
sounds like an important use case, although I think we would have
to work through an example to see how this could work.

Let's say a first intermediate uses its identity to request an assertion
authorizing it to impersonate the subject of another assertion.

It then uses this assertion to impersonate the original subject in the
invocation of another intermediary.

I can see how the 2nd intermediary might want to to request
an assertion authorizing it to impersonate the subject of the impersonation
authorizing assertion it received from intermediate 1; in which case,
I think intermediate 2 would be expecting to use its security token
to confirm the resulting assertion.

Said another way, I equate "to be usable as confirmation tokens in
a subsequent hop", as being used as identities 1 or 2 of the 4 identities
I named above. IMO, intermediate 2 being able to use the token it
received from intermediate 1 to establish identities 1 or 2, at another
service would entail delegation.

I find it more straight-forward to think about how such tokens might
be used in slot 3, and I think this use case inspires us to think about 
whether
the subject of the assertion requested by intermediate 2 should
include the  impersonation chain (as seen by intermediate 2) or
just the subject being impersonated. It would seem like the
assertion request service/protocol should afford intermediate 2
the option of requesting either form.

Ron

>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
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.
>
>  
>