Title: RE: Contradictory requirements?
Evan - It sounds like you don't really believe in the second of your two proposals. So, let's look only at the first. My problem with it is in the last line:
"etc., etc., etc."
Web server n gets Ticket 1 (which does not contain an authenticator), issued by Web server 1, from Web server n-1. It has no idea where the ticket has been between Web server 1 and Web server n-1. So, it has no way of judging whether it is still associated with the same browser. It must blindly trust all intermediaries, without knowing who they are (or even how many they are).
Doesn't sound satisfactory to me. Best regards. Tim.
-----Original Message-----
From: Evan Prodromou [mailto:]
Sent: Wednesday, June 20, 2001 3:13 PM
To: Tim Moses
Cc: ''
Subject: Re: Contradictory requirements?
>>>>> "TM" == Tim Moses <> writes:
TM> Colleagues - I would like SAML to standardize protocol
TM> profiles that enable daisy-chained single-sign-on and
TM> application-chain scenarios for the standard commercial
TM> browser that do not require the final relying party to know of
TM> and trust every link in the daisy-chain. I believe this will
TM> involve each relying party redirecting the browser to the
TM> original asserting party, either directly or via its own local
TM> authority (for the inter-domain case). Such a solution would
TM> be consistent with my interpretation of the requirements, with
TM> the exception of the second sentence in [R-Intermediaries].
TM> Would others consider such a profile to be in or out of scope?
I'm not sure I believe it's actually required.
Here's my idea of how to get the effect you're looking for. I'm using
a "pull method", but i can draw out a "push method", too.
1) Web User asks Web Server 1 to be transferred to Web Server 2.
2) Web Server 1 creates a one-use ticket, Ticket 1, and then redirects
Web User to Web Server 2.
3) Web Server 2 sends Ticket 1 to Web Server 1, requesting an AuthC
assertion associated with the ticket, and Web Server 1 returns the
AuthC Assertion 1.
4) Fickle-hearted Web User asks Web Server 2 to be transferred to Web
Server 3.
5) Web Server 2 creates a one-use ticket, Ticket 2, and then redirects
Web User to Web Server 3. Note that Ticket 2 != Ticket 1.
6) Web Server 3 sends Ticket 2 to Web Server 2, requesting an AuthC
assertion associated with the ticket. Web Server 2 returns AuthC
Assertion 1 (the assertion made by Web Server 1).
etc., etc., etc.
There's another possibility here, of course, which is adding some
"callback" data into the ticket itself. In this scenario, the steps
would go something like:
1) Web User asks Web Server 1 to be transferred to Web Server 2.
[Note that if we could get these ^%&$#! Web Users to just stay put,
we'd all have a much easier job. B-)]
2) Web Server 1 creates a MAGIC ticket, Ticket 10, and then redirects
Web User to Web Server 2. The magic ticket has a format like (off
the top of my head]:
{{Web Server 1}{time}{IP Address} Digital Signature}
3) Web Server 2 looks at the MAGIC ticket, and since it sees {Web
Server 1} embedded in the ticket, it asks Web Server 1 for an AuthC
Assertion, which it gets.
4) Web User (!!) asks Web Server 2 to be transferred to Web Server 3.
5) Web Server 2 redirects Web User to Web Server 3, passing the same
MAGIC ticket, Ticket 10.
6) Web Server 3 looks at the MAGIC ticket, and since it sees {Web
Server 1} embedded in the ticket, it asks Web Server 1 for an AuthC
Assertion, which it gets. (Note: it doesn't talk to Web Server 2 at
all).
Web Servers 2 and 3 would probably also check to see that Web User is
coming from the IP address embedded in the ticket, and that the ticket
is less than N seconds old, where N is some constant defined by their
partnership with Web Server 1.
I don't particularly like this scenario, for a number of reasons:
* Once Moriarty has the MAGIC ticket (perhaps by compromising the
network between Web User and Web Server 2 or 3, or by compromising
Web Server 2 or 3 itself), he can use it willy-nilly for the N
seconds it's valuable. Because the ticket should be as long-lived as
it takes for Web User not to get annoyed from having to
re-authenticate, this could be quite long.
* The identification of Web Server 1, embedded in the ticket, is
undefined and possibly
* The ticket could get kinda large, what with the signature and all
the data and stuff.
OK, so, my two Eurocents worth.
~ESP
--
Evan Prodromou, Senior Architect
Securant Technologies, Inc. 415-856-9551
