Content Comparison

...

 There are two categories of solutions -- those where the user's browser can be redirected from the SP to the backend site, and those where teh the browser cannot be redirected to the backend site (and consequently the SP must forward the user credentials over some other channel).

...

1. Specifications and information available here.
2. An example use case is allowing printing service printer.example.com (the Consumer), to access private photos stored on photos.example.net (the Service Provider) without requiring Users to provide their photos.example.net credentials to printer.example.com.
3. Does not prescribe or constrain the mechanism used by the Service Provider to authenticate the browser user.
4. The Service Provider MAY need a GUI allowing the user to identify which resources are being shared with the Consumer site.
5. The Service Provider MUST have a GUI where the user approaves approves sharing the resources with the Consumer.
6. oAuth COULD serve as a design model for a possible approach.

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 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. Tooling packages readily available for processing messages.
2. WS-Trust, etc already support the forwarding and processing of delegated credentials.
3. Shib's CS support would have to support the use of holder-of-key.

Develop a New SAML Profile

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.
3. NOTE -- this is NOT Web Services Security -- itis NOT using SOAP message security or the WS stack.
4. 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).
5. How might this be combined with REST ?

Use Cases

1. Browser user uses Shibboleth to authenticate to Confluence. User goes to Space Admin pages. User wants to give an additional ldap group access to the Space. User goes to the manage Permissions page, and clicks "browse groups". Confluence forwards the user's Kerberos ticket to the ldap server; the user only sees groups they are authorized to see.
2. Browser user uses Shibboleth to authenticate to web-based email interface. The web-based email application forwards the user's Kerberos ticket to the local IMAP server, to authenticate the user, and open their Inbox.
3. Browser user logs in to the Brown Faculty gateway. The gateway application connects to a backend application, authenticates the user by forwarding a Kerberos ticket, and asks the backend application for the list of courses and projects that this person teaches or participates in. 
4.