Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

Version 1 Next »

This 2-hour session determined what development is necessary to fully integrate shibboleth within uPortal.

Integration areas

1. Authentication to the portal

2. Getting a user's groups and attributes

3. User proxying

Authentication to the portal

This is just a configuration exercise. Basically, use mod_shib in Apache to protect the portal's location, and within uPortal, grab the username from the servlet API (REMOTE_USER).

Getting a user's groups and attributes

  • Use getRemoteUserContext() to get shib header values, ie, the SAML attributes
  • PersonDirectory has an in-memory personDAO
    • Servlet filter not committed yet (Chris Doyle, jira issue persondir-37)
    • Done for shib+uPortal (@ JHU)
    • A few engineering issues remain with that servlet
    • Should be added to the PersonDirectory project
  • PersonDirectory caches data for session lifetime
    • "username" is persisted in upUser table, maps username to internal key
    • If there are non-local users, need a globally unique "username"
    • PersonDirectory has no charset issues and default length limit of NNN
  • Use PAGS to map SAML attributes to uPortal groups

User proxying

A high-level sequence diagram gives the general approach to doing the 4-tiers to proxy through the portal, a portlet, to external service. Essential underpinnings of this approach are

  • Use of the SAML 2 ECP profile ("Enhanced Client or Proxy") that specifies how service to do service SAML flows.
  • Use of standard SAML assertion attributes to constrain the use of a proxy token.
  • No labels