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

New CAS documentation site

Icon

CAS documentation has moved over to jasig.github.io/cas, starting with CAS version 4.x. The wiki will no longer be maintained. For the most recent version of the documentation, please refer to the aforementioned link.

At our institution we've always required users to agree to an appropriate use policy on first login in our portal, later we added other "interrupts" that can fire at login as required these include acceptable use and secret question/answer pair. As we've casified more and more applications  the requirement came about to instead include these interrupts as a component of the CAS login.

The second requirement was to store the user's interrupt status within the LDAP. As a Active Directory/Exchange shop we decided on using extensionAttribute8 but you should be able to use any attribute with this code.

We formatted the LDAP attribute such that we have interrupt identifiers paired with the date of last completion and the pairs separated by semi-colons. ie. AUP=05/18/2010;QNA=;  This indicates the user completed appropriate use policy on May 18th and will have to provide a secret question/Answer pair at next login.

Attached source includes the java sources for the classes that scan the LDAP attribute.

First to use the class you'll need an LDAPTemplate, depending on how your deployerConfigContext.xml is set up you may already have one defined, if not you probably have a LDAP context defined like so:

If you have a context already defined the LDAPTemplate is easy to add like this:

 The ignorePartialResultException value in this example is required to work with Active Directory.
Once you have the LDAP template you need to configure the bean for the new java class in cas-servlet.xml:

 The properties:

  • filter defines how the username maps to LDAP attributes
  • ldapTemplate-ref names the LDAP template defined in the deployerConfigContext.xml
  • ldapAttrib is the LDAP attribute that will contain the string indicating which interrupts the user should see on next login
  • searchBase is the LDAP search based used when finding the username/attribute match

With this resolver added to the view factory the web flow can automatically find jsp pages named after your interrupt identifier:

 Then update viewFactoryCreator to add the new resolver to the view Factory:

 Now we need to tie the new beans into the login webflow in the file login-webflow.xml you should have:

 Change the transition to fire off the new bean and check for interrupt identifiers:

 Add the new the flow action to for the check:

 This action fires the bean and if there are pending interrupts the code is stored to the flowscope and the transition passes to the custom view for the interrupt if there are no pending interrupts it passes back to the normal flow.

 The custom view in the web flow looks like:

The jsp for the acceptable use view is named the same as the interrupt identifier (AUP.jsp in this example) looks a bit like this:

NOTE: After working several hours trying to get this same idea working, I finally realized that for CAS 3.5.1 the jsp needs different hidden fields:

Finally we add the SetFlag action which updates the LDAP attribute to record the user has completed the interrupt and passes flow back into the normal login flow (sort of - we actually go back a step in the flow to get a new ticket).

That's all you need if your interrupts are simple accept to proceed type, if you need more complex interrupts like our secret question/answer pair you'll need a few more pieces.  First you'll need a model to store the user feedback. (see IntData.java in the attached code)

Then you'll need to define your data update bean in cas-servlet.xml, something like:

To collect the user feedback you'll need to update the showInterrupt to populate the model:

Note the readFlow method in this example can be used to pull information from your data source and add it to your viewscope. 

 In the attached java there are two example methods for populating the question choices and to save the user's selection to a database. You'll need to modify as fits your environment.

 You then add a new action to pass the data into your bean for processing.

 And here is our QNA.jsp to give you an example form

 That's it, hope this is helpful to someone and I'm sure your end users will appreciate the value of your data collection efforts.

  • No labels