Re: Contradictory requirements?

[Evan Prodromou <eprodromou@securant.com>]

>>>>> "TM" == Tim Moses <tim.moses@entrust.com> 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        eprodromou@securant.com
Securant Technologies, Inc.             415-856-9551