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

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

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

That seems legitimate but a little more down the advanced road. I think we'd
have to first think about what that would look like. I note that one can
include multiple ConfirmationMethods in a single Subject, but there's no
definition of how that would relate to the confirmation data in the element.
Perhaps we need to revisit that schema a bit, or use multiple statements
(seems questionable from an efficiency standpoint), or defer this.

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

I've intended that /Request/Issuer be a hint re: (1) to aid the authority in
deducing the identity of the requester.

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

How can the requester know what to insert here? Are these really Subject
elements (or equivalent) in which the identity of the confirming parties is
expressed but maybe not a confirmation key?

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

Sure, obviously my example is just a special case of that where the
confirming token is also an assertion.

The other issue raised about holder-of-key applies to this discussion. It is
the case (as Bob noted) that the original intent of that confirmation method
was to preclude impersonation and that a different confirmation or
representation be used to explicitly communicate that. I think it's at least
worth considering the semantic distinction we might communicate just by
using a different URI. Or maybe that steps too far into the semantics of
what "holding a key" means.

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

I certainly thought about including something in the request message about
this (see my first schema example), but also considered the simplifying
assumption that the assertion issuer might determine this based on its
policy without anything in the request explicitly addressing it (my second
example).

I think we also need to consider what the "impersonation" statement would
be, that is, what the outer assertion might contain. Attributes would be a
common case, but I don't know about authentication statements as they
currently exist. Some kind of simple ImpersonationStatement that simply
names a Subject and includes the confirmation data might be enough.

-- Scott