Page History

...

For a discussion of the use case, see below.The Solution Proposal is outlined on a separate page

Separate topics cover:

• Solution Proposal
• Portal Design Issues
• IdP Change Proposals

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

The Use Case

We have five actors:

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

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.

...

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 Servicethe 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:

• Access to and/or the behavior of the Portal/Portlet, as well as the ServiceWSP, depend on communicating one or more "attributes" about the user to them.
• Permission for the Service WSP 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 ServiceWSP, 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 WSP may each be controlled by different organizations, making a federated solution a requirement.
• The Portal, Portlet, and WSP each have credentials known to the IdP, but need not be aware of each other's credentials.
• The protocol between the User Agent and Portal and between the Portlet and Service WSP 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 ServiceWSP.
• The Service WSP 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 WSP is acceptable.
• Adoption of existing standards where possible is desirable.

Image Added