Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: typos

...

 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.

...

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

...