This documentation relates to uPortal 4.0
If you are using a different version, please click on "Click for all versions" on the left side of the page and select the relevant version.

Caching and Re-playing Credentials

Skip to end of metadata
Go to start of metadata
All Versions
Page not found
Table of Contents
Page not found

Real-world portals often need to perform credential replay in order to access interesting information on behalf of an end user. For example, an email preview portlet might need to authenticate to an IMAP store using the logged-in user's institutional username and password.

Step 1: Enable Credential Caching

  • To enable credential caching, you will need to use the CacheSecurityContext in uportal-war/src/main/resources/properties/

For each context you'd like to cache credentials, add a cache property using the following template:

The following example shows a portal installation modified to cache credentials for both local and LDAP login:

## This is the factory that supplies the concrete authentication class

To get the cache to be populated, you will also need to allow the security credentials to continue being passed through the securityContexts by modifying uportal-war/src/main/resources/properties/

## Tells the ChainingSecurityContext whether or not to stop trying to authenticate a user
## once they have successfully passed authentication

Step 2: Uncomment cachedPasswordUserInfoService

The cachedPasswordUserInfoService bean auto-wires its other dependencies and doesn't need the full bean definition anymore: 

  • Uncomment the bean cachedPasswordUserInfoService in uportal-war/src/main/resources/properties/contexts/portletContainerContext.xml:
    <bean id="cachedPasswordUserInfoService" class="">
        <property name="decryptPassword" value="false"/>  <!-- If using CAS Clearpass, set to false. Use true if not using CAS. -->

Step 3: Enable stringEncryptionService

You must make sure the stringEncryptionServicebean in uportal-war/src/main/resources/properties/contexts/securityContext.xml is enabled (uncommented).

    <bean id="stringEncryptionService" class="">
        <property name="stringEncryptor">
            <bean class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">

                <!-- Before using the string encryption service you should first set a password.  The default
                     password works but is not secure.
                <property name="password" value="${org.jasig.portal.portlets.passwordEncryptionKey}"/>

                    Example BouncyCastle-powered AES encryption

                    To use AES encryption, uncomment the following section, add
                    the unrestricted JCE provider files to your JVM, and add
                    the JVM-version-appropriate BouncyCastle dependency to uPortal
                <property name="algorithm" value="PBEWITHSHA256AND128BITAES-CBC-BC"/>
                <property name="provider">
                    <bean class="org.bouncycastle.jce.provider.BouncyCastleProvider"/>

Though it is only used to protect password values stored in memory, it is recommended to change the default password encryption key value in uportal-war/src/main/resources/properties/ for increased security.  An alternate approach is to set the value with one of the Spring Property override files.

## Encryption key for the String Encryption Service used for user password encryption. Should be set to different value
## at least in prod, typically by using the Spring Property override files defined in CATALINA_HOME or
## PORTAL_HOME (see applicationContext.xml).  This is used to encrypt the user's password stored in-memory in the
## security context so malicious code or a hacker is less likely to obtain user's credentials.

Step 4:  Configure portlets

For each portlet that uPortal will pass the user's password to, the portlet's portlet.xml must be configured to accept the password as a user attribute and the portlet must be configured to use the password value.  Refer to each portlet's configuration documentation for specific procedures.

CAS Clearpass

Performing credential caching for CAS authentication is more complex, since when a user logs in via CAS, uPortal never sees the user's credentials. Luckily an interesting extension to CAS has been developed to allow the portal to query the CAS server and retrieve these credentials. Check out more on about the CAS ClearPass plug-in at How CAS relates to the Gateway SSO Portlet.

Step 1: Do the items specified above to enable password caching

Step 2: Update

Change the root.cas property to the CAS clearpass factory, and ensure the URL of the CAS clearPass service is uncommented.  You do not need a 'root.cas.cache' property because CAS is collecting and caching the password, not a uPortal security provider.
## URL of the CAS clearPass password service${}://${}/cas/clearPass

Step 3: If uPortal servers are clustered, enable PGP Ticket cluster replication

1. Uncomment init-param 'proxyGrantingTicketStorageClass' in uportal-war/src/main/webapp/WEB-INF/web.xml

 | For CAS PGT replication for CAS ClearPass in a clustered uPortal environment.
 | See "Replicating PGT using "proxyGrantingTicketStorageClass" and Distributed Caching" in

2. Uncomment the cas-client-support-distributed-ehcache dependency in uportal-war/pom.xml

<!-- For clustered uPortal environments using CAS ClearPass -->

3.  Configure RMI Cache Replication.

a) In your uportal-war/src/main/resources/properties/ehcache.xml, uncomment the manual RMI Peer Discoverer and RMI Peer Listener:

 | RMI Replicated Caching Manual Peer Discovery.  Use if automatic does not work for you or you don't want to
 | allow multicast on your network.  You must also set the IP addresses of the machines in the uPortal cluster
 | in the filters/*.properties files.
    properties="peerDiscovery=manual,rmiUrls=${}" />
 | Required if using Manual or Automatic RMI Replicated Caching Peer Discovery for CAS ClearPass in clustered
 | uPortal environment.
    properties="port=${}" />

b) Uncomment the cacheEventListenerFactory in cache 'org.jasig.cas.client.proxy.EhcacheBackedProxyGrantingTicketStorageImpl.cache' in uportal-war/src/main/resources/properties/ehcache.xml

 | Caches CAS Proxy-Granting Tickets (PGT) for CAS Clearpass support in a clustered uPortal environment, allowing
 | a CAS server to make the Clearpass PGT callback to any uPortal server, not just the uPortal server that initiated
 | the Clearpass PGT Request call to CAS.  Note that this cache data is replicated synchronously (really fired
 | synchronously - you don't know when the nodes in the cluster actually process the replication) to lessen the
 | chance that the uPortal node needing the PGT to request the user's password doesn't have it.  The PGT ticket
 | needs to be retained until requested by the portal to provide to a portlet, then it is not needed anymore since
 | the password is cached in the SecurityContext.
 | Additional configuration steps needed:
 | -,
 |          section Replicating PGT using "proxyGrantingTicketStorageClass" and Distributed Caching
 | -
 | -
 | For more information, see:
 | -
 | -
 | - 1 x user logins
 | - CAS PGT replicated synchronously
<cache name="org.jasig.cas.client.proxy.EhcacheBackedProxyGrantingTicketStorageImpl.cache"
       eternal="false" overflowToDisk="false" diskPersistent="false"
       maxElementsInMemory="10000" timeToIdleSeconds="600" timeToLiveSeconds="0"
       memoryStoreEvictionPolicy="LRU" statistics="true">
            replicateUpdates=true, replicateUpdatesViaCopy=true,
            replicateRemovals=true "/>

c) Then modify your filters/*.properties file to specify the IP addresses of the servers in your uPortal cluster.  You will need to have a different version of the filters/*.properties file for EACH uPortal Server in your cluster (e.g. you will need to modify the file on each uPortal server in the cluster, and not check the modifications into git).

# Clustered uPortal CAS Clearpass RMI URI list.
# Needed if using CAS Clearpass and a clustered uPortal environment.  See
# Replaces values in ehcache.xml.  Format is a pipe-separated list of uPortal machine IPs in the cluster (not including
# this machine) and the cache name.  See for
# more information.  The Manual RMI Peer Discovery must be uncommented in ehcache.xml.|//
# Clustered uPortal CAS Clearpass RMI Listener port.  If using manual peering, this port should match the port
# specified in the RMI URLs.  Range 1025 - 65536. Also used with automatic peer discovery.

Step 4: Enable SSL on uPortal servers

CAS Clearpass requires the uPortal servers to be using HTTPS.  Follow Tomcat's instructions for enabling SSL.

Local development environment

For a local development environment where the bundled CAS server is being used, you can use a self-signed certificate by following these steps.

1. Generate a self-signed certificate (

2. Enable HTTPS in your Tomcat using your certificate (

3. Import your private certificate into your java jre/lib/security/cacerts (see

Also modify your filters/ to use https://<servername>:8443 for both uPortal and CAS, or adjust the configuration of 'clearPassProxyList' in CAS's clearpass-configuration.xml accordingly (see Step 5).  You cannot use a server name of localhost.

Step 5: Configure CAS server for Clearpass

Enable ClearPass on the CAS server:

Local development environment

If using the CAS Server bundled with uPortal, perform 'Step 1: Modifying deployerConfigContext.xml' at the above URL to enable Clearpass.

  • No labels