The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

DelegatedCredentials

Owned by Former user (Deleted)
Last updated: Aug 04, 2008Version comment

Summary quote -- "People aren't interested in real security -- they just want something that looks like security."

 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 the browser cannot be redirected to the backend site (and consequently the SP must forward the user credentials over some other channel).

 Browser Redirection

 oAuth

  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 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 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".

 SOAP

  1. Typically described as used by a portal/mid-tier to access backend services.
  2. Security typically described as using WS-Security and WS-Trust, etc.
  3. The client (in the mid-tier) and the server (backend) applications would typically use a framework (WCF, Axis, etc) to compose and process SOAP messages.
  4. Consequently, these frameworks would have to support the use of SAML credentials within WS*, as well as the use of delegated credentials. The problem is that no one is using a SOAP framework that we can easily integrate with.
  5. There's also a belief that applications aren't really using SOAP between tiers. There's discussion of using SOAP to integrate components of large administrative applications; its hard to find real examples of using SOAP + Security with academic and collaborative applications.
  6. Describe the EGEE/SWITCH strategy.
  7. There's a suggestion to extend the 2.0 IdP to support requesting credentials via a SOAP connection. The belief is that this won't be used by anyone, adding support tot he claim that SOAP isn't really being used.

Liberty Protocols

  1. Not geting sufficient traction in the marketplace for us to even consider using these protocols.

CardSpace

  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.