...
An explanation of how to go from a fresh download of uPortal 2.3.2 to a CASified uPortal instance.
| Warning | ||
|---|---|---|
| ||
These instructions are intended for use only with the attached code. They aren't quite right for use with a newer uPortal CAS security provider, such as the version 3.x release. |
Discussion:
CASifying a deployment of uPortal requires, of course, an available CAS server. The CAS server must be able to receive https: requests, as the connection for ticket validation between a CAS client (in this case, uPortal) and the CAS server must be secure.
...
This is simplified in the case where the uPortal and CAS applications are both being hosted on the same machine, since a self-signed localhost certificate will be sufficient. In the more general case where uPortal and CAS are hosted on separate machines, each machine will need a server certificate that the other machine trusts. All clients of the CAS server will need to trust the CAS server certificate – for this reason CAS servers often use commercial certificates purchased from http://www.verisign.com, http://www.thawte.com Verisign, Thawte, etc.
uPortal can be configured to use any of several security contexts. To use CAS for uPortal authentication, the YaleCasContext security context must be the selected context. uPortal security contexts are configured to receive one or more "principals" and "credentials" read from the Login servlet request. In particular, CAS receives the request parameter "ticket" as its credential. It validates this ticket against the CAS server configured in the portal.properties file.
...
In the security.properties file in the uPortal properties directory, set the property "root" = "org.jasig.portal.security.provider.YaleCasContextFactory". This specifies that you want to use the YaleCasContext (which will be produced by this factory) as your root security context. A more complex configuration would be to allow the union of CAS authentication and other (say, simple) authentication, but let's start simple:
| No Format |
|---|
# Comment out the existing value for "root":
#root=org.jasig.portal.security.provider.SimpleSecurityContextFactory
# and instead use this value:
root=org.jasig.portal.security.provider.YaleCasContextFactory
|
In the same security.properties file, set the property "credentialToken.root" = "ticket". Comment out all other principalToken and credentialToken entries. This specifies that you want uPortal to remember the request parameter "ticket" on the Login request – which CAS will send along – and make it available to YaleCasContext, which will validate it.
| No Format |
|---|
# Answers what tokens are examined in the request for each context during authentication. # A subcontext only needs to set it's tokens if it differs from those of the root context. #principalToken.root=userName #credentialToken.root=password #credentialToken.root.cas=ticketid credentialToken.root=ticket |
At the end of portal.properties, add the following properties, which specify parameters that YaleCasContext requires:
| No Format |
|---|
org.jasig.portal.security.provider.YaleCasContext.CasValidateUrl=https://localhost:8443/cas/proxyValidate org.jasig.portal.security.provider.YaleCasContext.CasProxyCallbackUrl=https://localhost:8443/uPortal/CasProxyServlet org.jasig.portal.security.provider.YaleCasContext.PortalServiceUrl=http://localhost:8080/uPortal/Login |
...
From here, you will need to replace the default authentication handler declared in the CAS application web.xml with a handler that authenticates your population. You may with wish to visit ESUP-Portail's CAuthGenericHandler project for several handler options.