The document summarizes Indiana University's upgrade of its Central Authentication Service (CAS) from version 2 to version 3.5.2. Key aspects of the upgrade included designing and implementing a system of "AppCodes" to dynamically render user interfaces and determine authentication requirements, integrating primary authentication via Kerberos and a knowledge base, enabling secondary authentication via RADIUS for multi-factor authentication, extending CAS protocols to support IUCAS, and setting up an active-active high availability deployment using EhCache for ticket storage. The project was developed using Git source control and a continuous integration workflow.

1. To CAS 3 and Beyond:
The Story of a CAS Upgrade
Nubli Kasa
mmohdkas@iu.edu
Misagh Moayyed
mmoayyed@unicon.net

2. Agenda
 Introduction
 Environment Overview
 Functional Requirements
 Features Overview
 Demo
 Development Workflow
 Discussion & Questions
Open Apereo - June 1-4 2014

3. Introduction: Nubli Kasa
 Lead Systems Analyst Programmer at
Identity Management Systems
 With Indiana University for 6 years
 Technical lead for the project; Responsible
for managing CAS and Shibboleth
deployments

4. Introduction: Misagh Moayyed
 IAM Consultant @ Unicon
 3 years with Unicon; 5 years with
JasigApereo
 Unicon’s technical lead for the project

5. Current Environment
 Current CAS based onYale CAS v2
 Diverged from Apereo CAS in many ways
 Utilizes large set of AppCodes
◦ Authentication request type, authorization, …
 StepUp Authentication; Staff @ admin
permissions
 Challenges to meet business need have led to
many large and small CAS changes.

6. Functional Requirements
 Upgrade to CAS 3.5.2
 Design and Implementation of AppCodes
◦ Dynamic UI Rendering
◦ AppCodeValidation vs. StepUp AuthN
 Primary AuthN via Jaas & KB
 StepUp AuthN via RADIUS
 Protocol extension; Support for IUCAS
 Active-Active HA Deployment with EhCache

7. What is an AppCode?
 Token to describe the requesting app
◦ What theme to use?
◦ What authentication methods to allow?
 Analogous yet parallel to service registry
 Grouped by 4 primary AppCodes
◦ IU, GUEST, SAFEWORD, ANY
 Recognize changes automatically

8. AppCodeRegistry

9. Dynamic Theme Selection
 AppCode groups can specify themes
 AppCodeResourceViewResolver

10. Primary AuthN: Jaas & Krb
 Jaas.conf:
 Krb5.conf:
 Problem: how do we tie realms to KDCs?!

11. New JaasAuthenticationHandler
 No Krb5.conf; System Props instead:
◦ java.security.krb5.realm
◦ java.security.krb5.kdc
 Let CAS pick Realms and KDCs!

12. StepUp RADIUS AuthN Config
 Additional properties for NAS settings

13. StepUp AuthN via RADIUS
 Primary based on @cas-mfa codebase:
◦ https://github.com/Unicon/cas-mfa
 Initiated by SAFEWORD AppCode
 CAS remembers a single AppCode; knows
its relationship to other AppCodes

14. StepUp AuthN Rules
 Depending on credentials, ANY can both be
IU or GUEST!

15. CAS Protocol Extensions
IU CAS Protocol CAS Protocol Equivalent
cassvc ${appcode:IU}
casurl service
casticket ticket
CASValidation Response:

16. EhCacheTicketRegistry
 Distributed cache across live nodes
 Replication via Java RMI; Manual discovery
 Two separate caches for STs andTGTs
 No need for ticket registry cleaners!
 Simple setup; No external process required

17. EhCache Replication
 RMI replication & manual peer discovery
 Specify “other” nodes in the cluster

18. Discoverable Host Names
 Single cas.properties file for all nodes
 Discover ${host.name} automatically

19. Demo

20. Development Workflow
 BitBucket Git repository;
Code + Docs
 Real-time issue tracking &
collaboration
 Automated deployment via
Jenkins CI
bitbucket

21. Questions?
Open Apereo - June 1-4 2014
Nubli Kasa
mmohdkas@iu.edu
Misagh Moayyed
mmoayyed@unicon.net