>>>>> "TM" == Tim Moses <> writes:
TM> Any protocol profile that relies on token possession for
TM> authenticating the principal (e.g. the "standard commercial
TM> browser" profile) runs into problems in daisy-chained
TM> scenarios, as (without the involvement of the asserting party
TM> at each step) an intermediary can impersonate the principal.
Absolutely true. The semantics of presentation of a token is pretty
convoluted and strange.
Take the "application chain" use case, for example. When the Web user
makes a request to the Web server, the presentation of the token
means, "I am Webb Q. Yousser, and I wish to retrieve/execute resource
X."
When the Web server turns around and presents the same token to the
Application Server 1, the semantic becomes, "Webb Q. Yousser is
executing my resource X. Execution of resource X requires access to
your resource Y, so I'd like you to give me resource Y with Webb
Q. Yousser's authorization level."
In a further chaining, Application Server 1 could ask Application
Server 2 for another resource Z, again on behalf of WQY and using
WQY's authorization level.
There is, of course, a never-ending spiral of a bastard form of
delegation going on here -- from user to local application to local
computer to network router to network router to Web server to
Application Server. It does depend on an implicit level of trust
between each pair of links in the chain.
If Application Server 1 does not know and trust Web Server, it's
probably a bad idea to execute anything that Web Server asks for, with
or without a SAML token. In effect, Application Server 1 must trust
Web Server at the "impersonate" level, which is really quite a lot of
trust.
~ESP
--
Evan Prodromou, Senior Architect
Securant Technologies, Inc. 415-856-9551
