Portal Design

Placeholder for discussion of Portal Design issues.

SP Integration

Exposing attributes from SP to portal

The Shibboleth Service Provider represents the user attributes extracted from a SAML authentication response as HTTP headers.

For instance, this mapping in attribute-map.xml would instruct the SP to map the user's favorite fruit user attribute to an HTTP header named "favFruit".

<Attribute name="https://example.org/myAttributes/FavoriteFruit" id="favFruit"/>

uPortal has a pluggable API for sources of user attributes (represented as Person Attribute Data Access Objects (DAOs)). Johns Hopkins University has developed a Person Attribute DAO with the behavior of presenting HTTP request attributes as uPortal Person Attribute API attributes.

The Person Attribute subsystem doesn't have access to the HTTP request and its headers. The Johns Hopkins implementation solves this with a bridging Java Servlet Filter.

This filter is declared in web.xml like this:

<filter>
    <filter-name>HttpHeaderFilter</filter-name>
    <filter-class>edu.jhu.services.persondir.support.http.HttpHeaderFilter</filter-class>
    <init-param>
        <param-name>personDirectoryContextLocation</param-name>
        <param-value>properties/contexts/personDirectoryContext.xml</param-value>
    </init-param>
</filter>
...
<filter-mapping>
    <filter-name>HttpHeaderFilter</filter-name>
    <servlet-name>Login</servlet-name>
</filter-mapping>

The data access object itself is declared something like this:

<bean id="httpHeaderAttributeSource" class="edu.jhu.services.persondir.support.http.HttpHeaderPersonAttributeDao">
  <constructor-arg>
    <value>edu.jhu.services.persondir.support.http.HttpHeaderPersonAttributeDao</value>
  </constructor-arg>
  <property name="columnsToAttributes">
    <map>
      <entry key="favFruit">
        <value>favorite_fruit</value></entry>
    </map>
  </property>
</bean>

What this says is "Map the HTTP header named 'favFruit' to the portal user attribute named 'favorite_fruit'."

This source of user attributes can be declared alongside sources such as RDBMS queries and LDAP queries.

<bean id="mergedPersonAttributeDao" class="org.jasig.services.persondir.support.MergingPersonAttributeDaoImpl">
  <property name="personAttributeDaos">
    <list>
      <ref bean="uPortalJdbcAttributeSource"/>
      <ref bean="uPortalLdapAttributeSource"/>
      <ref bean="httpHeaderAttributeSource"/>
    </list>
  </property>
  <property name="merger">
    <bean class="org.jasig.services.persondir.support.merger.MultivaluedAttributeMerger"/>
  </property>
</bean>

What this says is "Consider the database, LDAP, and HTTP headers as sources of user attributes, in the configured ways."

This binding of HTTP headers to uPortal person attribute APIs is uPortal specific (actually, JASIG Person Attribute API specific, with uPortal being the only major portal platform making use of this API). However, a similar approach of binding the attribute-bearing headers provided by the Shibboleth SP to the APIs whereby the portal expects to represent user attributes is applicable to all portal platforms.

Exposing User Attributes from SP to JSR-168 Portlets

Background on User attributes in JSR-168 Portlets

Once user attributes are available to the portal, these attributes can be used for several purposes. They can be inputs to decisions about user layout and evaluation of user group membership. The attributes can also be presented to particular portlets running in the portal. Not all user attributes known to the portal need be available to a given portlet running within the portal.

JSR-168 portlets declare at deployment time which user attributes they may use by means of declaration in their portlet.xml deployment descriptor.

 
<user-attribute>
  <description>User Favorite Fruit</description>
  <name>favorite_fruit</name>
</user-attribute>

What this says is "This portlet relies upon the portal to provide a user attribute 'favorite_fruit'".

JSR-168 portlets can read values of their declared user attributes at runtime via a JSR-168 API:

// in the course of handling a PortletRequest named 'request'
Map userInfo = (Map) request.getAttribute(PortletRequest.USER_INFO);
String surname = (String) userInfo.get("favorite_color");
// presumably, do something interesting based on the user's favorite color...

JSR-168 portlets do not necessarily have access to the HTTP headers of the portal HTTP request (have no API-defined access to the HttpRequest object). They rely rather on JSR-168 APIs for conveyance of username, user attributes, and other information about the request from portal to portlet.

Exposing Shibboleth SP-provided user attributes to portlets

Under the Johns Hopkins approach, Shibboleth-provided user attributes are treated like other user attributes. Exposing particular attributes to portlets is a matter of collecting those attributes from the HTTP headers in the HttpHeaderPersonAttributeDao, and then mapping the resulting portal user attribute into the particular portlets making use of it.

Limiting access to attributes from SP to portlets

Existing Solution

Access to user attributes is already limited by the JSR-168 API and declaration of JSR-168 portlet attribute names in each portlet's deployment descriptor portlet.xml. If a portlet should have access to the portal user attribute that derives from a particular Shibboleth-provided user attribute that was represented by the Service Provider as an HTTP header, then that portlet's portlet.xml should map the corresponding portal user attribute. If another portlet should not have access to this attribute, its portlet.xml should fail to declare that attribute.

Directions for further limiting access to attributes from SP to portlets

This approach of the SP presenting user attributes to the portal and then allowing (and relying upon) the portal to present appropriate user attributes to appropriate portlets works well so long as the IDP is not modeling finer-grained attribute release policy as regards releasing attributes to some portlets and not others. If this richer attribute release guidance is present, then a more sophisticated solution may be needed.

This might involve a "smarter" Service Provider that represents this detail in the namespace of the HTTP headers representing the attributes, a "smarter" implementation of the JSR-168 portlet person attribute provider API which restricts programmatically which attributes which portlets may read, or even a "smarter" Http header reading Person Attribute DAO which uses Aspect-oriented access control to just-in-time gate access to restricted Shibboleth-provided user attributes.

Portal/Portlet Security Token Handoff

Mechanism for portlet to ask for an assertion to proxy with

Background on how assertion-like things are currently handled in uPortal

JSR-168 Portlets can read end user's password in a special user attribute

uPortal's JSR-168 support has special handling for the user attribute "password", such that if it is mapped in the portlet's portlet.xml then if the portal is aware of the user's password it will make it available to the portlet alongside the other user attributes.

This convention for treatment of the JSR-168 user attribute "password" is uPortal-specific, though of course the JSR-168 user attribute API itself is generic across all JSR-168-supporting portals.

JSR-168 Portlets can obtain a CAS proxy ticket via a special user attribute

uPortal's JSR-168 support has special handling for the user attribute "casProxyTicket", such that if it is mapped in the portlet's portlet.xml then if the portal is aware of a relevant CAS single sign on session (is in possession of a valid Proxy Granting Ticket for the current user session) the portal will obtain from CAS a Proxy Ticket for the purpose of proxying authentication to the portlet. By convention, the CAS Service URL of a portlet is represented as the URL of the servlet application containing the portlet, up to and including context path.

The portlet then validates this Proxy Ticket with CAS and itself receives a Proxy Granting Ticket from which it can then obtain Proxy Tickets for proxying authentication to backing services in the normal way of CAS proxy authentication.

Portlet Client Library

• Need an HTTP client API allowing access to WSPs while handling authentication internally
• Client stack needs support for TLS client and server authentication, cookies, and whatever features WSPs would impose
• Internals must support detection of ECP requests, Liberty-defined interactions with IdP, and handling ECP responses