CASifying Jenzabar JICS Portal

Owned by Carey Morgan
Last updated: Oct 22, 2014Version comment
3 min read

This article describes how to use CAS as the identity provider for the Jenzabar Internet Campus Solution portal (JICS).

Two Approaches Available

  1. Configure CAS to use ArgumentExtractor features and configure JICS to use CAS as a SAML identity provider (described below)
  2. Use a custom login control provided by Jenzabar Services

Configure CAS and JICS

The following Jenzabar wiki topic may have more up to date information: https://wiki.myjenzabar.net/SAML_Jasig_CAS_as_Identity_Provider_to_JICS

The following notes describe how to use a CAS feature called ArgumentExtractor to enable it to speak SAML 2.0 and how to configure JICS to rely on it as Identity Provider.

It is possible to install CAS on the JICS web server, though it is most advisable to keep your CAS Identity Provider on its own server host so that it will not be affected by potential interruptions caused by the malfunction or maintenance of any other application.

Part 1: Preparing CAS to be an ID Provider

The notes below are taken directly from the Jasig Wiki:

https://wiki.jasig.org/display/CASUM/SAML+2.0+%28Google+Accounts+Integration%29

Step 1: Generate RSA Keys

The first step is to generate DSA/RSA public and private keys. These are used to sign and read the Assertions. After you've generated your keys, you will need to Convert the x509 key to a DER to be used on windows.

::"This command can likely be altered to put out a DER cert directly, needing only to be resaved"

The keys will also need to be available to the CAS application (but not publicly available over the Internet). We recommend you place the keys within your classpath (i.e. WEB-INF/classes) though any location accessible by the user running the web server instance is acceptable:

openssl genrsa -out private.key 1024

openssl rsa -pubout -in private.key -out public.key -inform PEM -outform DER

openssl pkcs8 -topk8 -inform PER -outform DER -nocrypt -in private.key -out private.p8

openssl req -new -x509 -key private.key -out x509.pem -days 365

Then take the x509.pem, and go to https://www.sslshopper.com/ssl-converter.html SSL Shopper SSL Converter and convert it from standard PEM to Binary / DER. The resulting certificate should be able to be opened on a windows machine. Open it, and click "Save Certificate As" and save it as a .cer and place it on your webserver.

Step 2: Configure CAS Server

JICS integration within CAS is enabled by simply adding an additional "ArgumentExtractor" to the list of ArgumentExtractors. An ArgumentExtractor attempts to obtain a service from the provided Request. Each ArgumentExtractor is responsible for understanding one type of Service.

You'll need to modify the WEB-INF/spring-configuration/argumentExtractorsConfiguration.xml, and add the following:(note: the section p:httpClient-ref="httpClient" is only for 3.4 and up, and should be removed for 3.3.x)

<bean name="googleAccountsArgumentExtractor"

class="org.jasig.cas.web.support.GoogleAccountsArgumentExtractor"

p:privateKey-ref="privateKeyFactoryBean"

p:publicKey-ref="publicKeyFactoryBean"

p:httpClient-ref="httpClient" />

Reference that from the list of ArgumentExtractors, so it would look something like this:

<util:list id="argumentExtractors">

<ref bean="casArgumentExtractor" />

<ref bean="samlArgumentExtractor" />

<ref bean="googleAccountsArgumentExtractor" />

</util:list>

You'll need to configure the keys so they can be loaded from the files. You do that as follows:

<bean id="privateKeyFactoryBean"

class="org.jasig.cas.util.PrivateKeyFactoryBean"

p:location="classpath:private.p8"

p:algorithm="RSA" />

<bean id="publicKeyFactoryBean"

class="org.jasig.cas.util.PublicKeyFactoryBean"

p:location="classpath:public.key"

p:algorithm="RSA" />

Replace the public.key and private.key with the names of your key files. If they are not available on the classpath, change the location to point to the location of the keys. If you are using RSA instead of DSA, change the algorithm as appropriate.

Part 2: Configure JICS

You must first determine which property of each logged in user will be passed from CAS to JICS as the unique identifier of the logged-in user. JICS essentially offers you three choices:

  • JICS Username
  • JICS Email Address
  • JICS HostID (the ERP/SIS ID number)

By default, JICS expects the incoming identifier to be the JICS Username. If anything different is configured to come in from CAS, you will need to provide an entry in the FWK_MappedUserEntity table to specify how JICS should interpret the incoming identifier. Details of this table's configuration is available here: https://wiki.myjenzabar.net/SAML_User_Mapping

Assuming CAS and JICS agree on what attribute is to be sent, you must make sure the two systems also agree on the SAML SSO nameid format configuration outlined below. The default format should be urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified, but urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress could also work if both systems agree on calling the attribute by that name.

In Site Manager > Site Settings > Framework Settings > Security > Authentication (version 7.4+) choose the following settings:

  • Authentication type: '''Authenticate using an external system''' option: '''SAML identity provider'''
  • SAML SSO Provider name: something like '''my.school.edu''' or '''JICS'''
  • SAML SSO Audience: '''Provider name'''
  • SAML SSO identity provider login URL: something like '''https://cas.yourschool.edu/cas/login'''
  • SAML SSO identity provider logout URL: '''https://cas.yourschool.edu/cas/logout?service=http://my.school.edu'''
  • SAML SSO public key file: a file path something like '''C:\Some_folder__on_JICS_server_with_cert\GeneratedAndRenamed.cer'''
  • SAML SSO protocol binding: '''urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect''' (the default)
  • SAML SSO nameid format: "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
  • SAML SSO use tag prefixes: '''False''' (new feature as of JICS 7.4) ''''Note: This is different from Shibboleth''''
  • Use custom login user control: '''False''' (unless you have implemented some customized version of the login control to replace standard code)