You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

This wiki space exists to develop a technical solution and project plan to add support within the Shibboleth System software for at least one variant of the so-called "proxy authentication" problem, wherein a service to which a user may have authenticated wishes to invoke another service on the user's behalf. To motivate the project, the specific case of a portlet living within the uPortal software as the proxying service has been chosen, but the solution should apply to non-portal use cases.

Solving this problem in the general case is very complex, which is one reason it hasn't been done within Shibboleth to date. Instead, we are starting with a more tightly constrained use case that limits the scope of the problem; we will design for generality where possible, but not at the expense of compromising our ability to solve at least one basic use case without an overwhelming scope of work.

The Use Case

We have five actors:

  • User Agent
  • User's Identity Provider
  • Portal Instance (assumed to be uPortal)
  • Portlet
  • Service

In a non-portal use case, the Portal and Portlet can be treated as a single actor consisting of any kind of intermediary service. The rest of the use case is essentially unchanged.

The sequence of high-level application interactions is as follows:

  1. The User Agent logs into the Portal Instance with the mediation of the Identity Provider.
  2. The User Agent accesses a Portlet (may simply be part of rendering the Portal to the User Agent).
  3. The Portlet invokes the Service in such a manner that the identities of both the User and the Portlet are securely communicated to the Service.

In proposing a solution, we hold to these assumptions and constraints:

  • Access to and/or the behavior of the Portal/Portlet, as well as the Service, depend on communicating one or more "attributes" about the user to them.
  • Permission for the Service to obtain the required user attributes is granted ahead of the User Agent's interaction with the Portal/Portlet.
  • The user's unique identity may or may not be needed at both the Portal and Service, and privacy is valued (i.e. the solution doesn't assume that providing a persistent identifier for the user is acceptable).
  • The Portal, Portlet, and Service may each be controlled by different organizations, making a federated solution a requirement.
  • The protocol between the User Agent and Portal and between the Portlet and Service is HTTP. We do not assume (but don't preclude) that it is SOAP over HTTP.
  • The level of security of the User Agent's authentication and subsequent HTTP session with the Portal is also acceptable for the authentication and subsequent HTTP session between the Portlet and the Service.
  • No labels