Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: added partial draft of Portal to portlet assertion handoff piece

...

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.

Tip
titleSee also

See also uPortal 3 Manual Page on this topic.

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.

Note
titleExample of the Service URL representing a JSR-168 portlet and the CAS protocol

Suppose that in the portal at https://portal.example.edu/Image Added there is a portlet web application OrderStatusPortlet.war such that, to the extent that this portlet application is also a servlet application, it answers at https://portal.example.edu/OrderStatusPortlet/Image Added .

The Service URL of this portlet is therefore https://portal.example.edu/OrderStatusPortlet/Image Added . The portal will use its Proxy Granting Ticket to obtain a Proxy Ticket for the purpose of authenticating to https://portal.example.edu/OrderStatusPortlet/Image Added , which it will then present to the portlet as the special JSR-168 user attribute "casProxyTicket".

The Portlet will then validate this ticket with CAS, specifying at validation that it would itself like to obtain a Proxy Granting Ticket and providing to CAS a callback URL at which it would like to receive that Proxy Granting Ticket. CAS calls back to a URL like

https://portal.example.edu/OrderStatusPortlet/proxyTicketReceptorImage Added

providing a Proxy Granting Ticket which authenticates the chain of user-portal-portlet. The portlet then uses this Proxy Granting Ticket to obtain Proxy Tickets for the purpose of authenticating to specific backing services.

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