Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

Proxy CAS allows authentication of a chain of services (say, your Calendar Portlet as accessed from your uPortal instance) and its participation in a Single Sign On session (say, end user "awp9" authenticated via CAS to your uPortal, which proxy authenticated via CAS to your JSR-168 calendar portlet, which proxy authenticated via CAS to your calendar feed server). All of this happens with the end user authenticated to CAS using, say, a username and password and the services authenticated to CAS via server-side SSL certificates. No forwarding of primary credentials - only CAS server gets to see the password.h2 .

uPortal Portlet ProxyCAS Strategy

The uPortal obtains a Proxy Granting Ticket in the name of the uPortal instance at the time the user authenticates. The Cas Proxy Ticket User Info Service then requests a proxy ticket for a URL representing the portlet (for example, "https://my.school.edu/CalendarPortlet/CasProxyServlet").

...

To use the CAS Ticket User Info Service, ensure the bean is mapped in uportal-impl/src/main/resources/properties/contexts/portletContainerContext.xml and included in the userInfoService bean list. This bean is present and appropriately configured in the default uPortal distribution, but it is provided below for completeness.

Code Block
xml
xml
    <bean id="userInfoService" class="org.jasig.portal.portlet.container.services.MergingUserInfoService">
        <property name="userInfoServices">
            <list>
                <ref bean="personDirectoryUserInfoService"/>
                <ref bean="casTicketUserInfoService"/>
            </list>
        </property>
    </bean>

    <bean id="casTicketUserInfoService" class="org.jasig.portal.portlet.container.services.CasTicketUserInfoService">
        <property name="userInstanceManager" ref="userInstanceManager" />
        <property name="portletWindowRegistry" ref="portletWindowRegistry" />
        <property name="portletEntityRegistry" ref="portletEntityRegistry" />
        <property name="portletDefinitionRegistry" ref="portletDefinitionRegistry" />
        <property name="portalRequestUtils" ref="portalRequestUtils" />
    </bean>

...

Code Block
xml
xml
<portlet-app
    xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd"
    version="1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd
                        http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd" id="ProxyCasPortlet">

    <portlet>

        . . . 

    </portlet>

    <user-attribute>
        <!-- 
            This attribute name must match the key name configured in uPortal's
             CasTicketUserInfoService
         -->
        <name>casProxyTicket</name>
    </user-attribute>

</portlet-app>

...

Using Proxy CAS using the 3.1.x Jasig CAS client generally involves configuring filters, then using the CAS Java API to validate the UserInfo map provided CAS ticket.This works as follows:

First the portlet retrieves its own proxy ticket from the portlet's UserInfo map. Next it can use the org.jasig.cas.client.validation.TicketValidator class to validate the ticket and retrieve an Assertion object. The Assertion object encapsulates the Ticket Granting Ticket that the portlet can now use to obtain service tickets for back end services and resources. The Assertion object, once obtained is durable for the life of the portlet instance and can be used multiple times to obtain service tickets. The Assertion can be stored in the session and re-used by other components to obtain service tickets as needed.

Current CAS best practices suggest using Spring's DelegatingFilterProxy to configure a CAS filters via the Spring application context. This strategy allows developers to make use of Java property files for configuring strings such as the portal's base server URL.

...