Content Comparison

...

n-tier (no Browser Redirection)

Kerberos

1. This discussion has been dormant for some time; info available here.
2. Equivalent functionality is currently available with CoSign and Stanford's WebAuth.
3. Consequently, the issues and approaches are already known, but complex.
4. Because of how Kerberos is typically deployed, this approach is probably only relevant to intra-domain situations.
5. Use Shibboleth to transport a Kerberos ticket to SP-A as an attribute; SP-A then presents the ticket to the backend service.
6. No constraints on the protocol stacks SP-A uses to communicate with the backend.
7. This approach relies on Kerberos' existing support for delegation; the ticket must already be a "delegated ticket".

...

1. Not Browser based.
2. Flow originates at the client (no Authn Request from the SP).
   1.   Client contacts IdP over SOAP, requests Assertions for specific SP.
   2. Client authenticates to IdP with Cardspace? As defined by ECP ?
   3. Client POSTs the Assertions to the SP (this is the first interaction with the SP)
   4. SP Validates the Assertions (what does it check? holder-of-key ?)
   5. SP returns a cookie to the client.

NOTE -- this is NOT Web Services Security -- itis NOT using SOAP message security or the WS stack.

1. As described, this is not yet n-tier. However, with a bit of recursion, it could be:
   1. Extend the IdP with a new endpoint that could "update" the presented token (similar in concept to the idea in Scott's original Delegated Credentials Profile)
   2. Embed a client in the mid-tier; have it present the received Assertion to the IdP for "updating".
   3. Modify the SP implementaiton to recognize tht an Assertion contains a second Subject (meaning a delegated Assertion).