...
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 | ||
---|---|---|
| ||
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 | ||
---|---|---|
| ||
Suppose that in the portal at https://portal.example.edu/ 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/ . The Service URL of this portlet is therefore https://portal.example.edu/OrderStatusPortlet/ . The portal will use its Proxy Granting Ticket to obtain a Proxy Ticket for the purpose of authenticating to https://portal.example.edu/OrderStatusPortlet/ , 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/proxyTicketReceptor 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