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.

For a discussion of the use case, see below.

Separate topics cover:

For editing access in this wiki space, see the access instructions.

The Use Case

We have five actors:

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 Web Service Provider in such a manner that the identities of both the User and the Portlet are securely communicated to the WSP.

An illustrative sequence diagram is further below, and a visio of the diagram is also available.

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