Skip to end of metadata
Go to start of metadata
Table of Contents

This page is for documenting how to CASify JSR-168 portlets, particularly how to allow them to obtain proxy tickets.

Big picture

As of uPortal 2.5, you can override methods in CPortletAdapter to set PortletRequest attributes.

Suppose we do so. We invent a service String representing our portlet. We use an IYaleCasContext LocalConnectionContext implementation to obtain a proxy ticket for this service (in uPortal). We place this into a portlet request attribute on first invocation of our portlet.

The portlet validates the proxy ticket we passed as a PortletRequest attribute, specifying a proxy callback URL of a mapped instance of the ProxyTicketReceptor servlet in the portlet webapplication. CAS sends the portlet.war a proxy granting ticket of its own (chained off of the uportal PGT, but not the uPortal PGT. Services to which the portlet proxies can identify the particular .war instance that is proxying, rather than just identifying the portal generally. Particular back end services might trust the grades portlet to proxy to more than just the resources to which the bookmarks portlet may proxy.)

Implementation

Code sketches.

A wrapper for a portlet, implementing establishing the CASReceipt into the PortletSession.

CASPortletWrapper

This relies heavily on a helper class (which other portlets can use without using the wrapper portlet):

CASPortletUtils

This helper class in turn relies upon a new factory for ProxyTicketValidator instances:

ProxyTicketValidatorFactory
  • No labels

2 Comments

  1. Great stuff but I noticed that there is something small but crucially wrong with the method establishSession in the class CASPortletUtils. The line that reads:

    CASReceipt.getReceipt(validator);

    Should be:

    receipt = CASReceipt.getReceipt(validator);

    Otherwise the value of receipt will always be null.

  2. Can You attach an example of use?

    Thanks in advance