...
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.
The Solution Proposal is outlined on a separate page.
The Use Case
We have five actors:
...
- 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.
- The Service need not (but may choose to) be aware of the distinction between a User Agent accessing it under direct control of a user, and a Portlet accessing it on behalf of a user.
- Within reason, requiring software changes to the Portlet to secure its interactions with the Service is acceptable.
- Adoption of existing standards where possible is desirable.