CAS Single Sign On Handbook

CAS Single Sign On Handbook
June 2014
Banner®, Colleague®, PowerCampus™, and Luminis® are trademarks of Ellucian Company L.P. or its affiliates and are registered in the U.S.
and other countries. Ellucian®, Ellucian Advance™, Ellucian Degree Works™, Ellucian Course Signals™, Ellucian SmartCall™, and Ellucian
Recruiter™ are trademarks of Ellucian Company L.P. or its affiliates. Other names may be trademarks of their respective owners.
©2013-2014 Ellucian Company L.P. and its affiliates.
Contains confidential and proprietary information of Ellucian and its subsidiaries. Use of these materials is limited to Ellucian licensees, and is
subject to the terms and conditions of one or more written license agreements between Ellucian and the licensee in question.
In preparing and providing this publication, Ellucian is not rendering legal, accounting, or other similar professional services. Ellucian makes no
claims that an institution's use of this publication or the software for which it is provided will guarantee compliance with applicable federal or state
laws, rules, or regulations. Each organization should seek legal, accounting and other similar professional services from competent providers of
the organization's own choosing.
Prepared by: Ellucian

4375 Fair Lakes Court
Fairfax, Virginia 22033
United States of America
Revision History
Publication Date Summary
November 2013 New version that supports CAS single sign on for Ellucian products.
April 2014 Added chapters for Banner Document Management, Banner Workflow, and Ellucian Degree Works
May 2014 Updated text for cas.properties and deployerConfigContext.xml files.
June 2014 Added text for integrating Banner Document Management with Banner Workflow.
Contents
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Identity management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Ellucian integration with CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Functional Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
What is SSO? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
What is third-party authentication? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
What is claims-based authentication? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
What is a common identifier? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
What is CAS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
How does Banner support identity management? . . . . . . . . . . . . . . . . . . . . . . . . . 12

Batch utilities and account provisioning components . . . . . . . . . . . . . . . . . . . . . . . . . . 12
SSO Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
An analogy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Plan your CAS implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

New implementation of CAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
CAS upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Map GUIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
If BEIS account provisioning is deployed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
If BEIS account provisioning is not deployed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Configure the CAS server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
CAS Single Sign On Handbook | Contents 3

Installing a new CAS server from the Jasig distribution . . . . . . . . . . . . . . . . . . . . . . . . 17
Installing a new CAS server as part of the Luminis Platform 5 installation . . . . . . . . . . 27
Configuring Banner to use an existing CAS server . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Installing and configuring Luminis Platform 5 to use an existing CAS server. . . . . . . . 28
Configuring Banner for CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
SSB configuration for CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Supporting components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Processing flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Configuration steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Deep-linking to SSB pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
INB configuration for CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Processing flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Deep-linking to INB forms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
JVM pooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Banner 9.x configuration for CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Processing flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Configuring Banner Document Management for CAS . . . . . . . . . . . . . . 89
CAS with ApplicationXtender products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Processing flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Integration with Banner Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

CAS authentication for SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Supported product versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
BDM integration URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Using BDM integration URLs in custom activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Advanced options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Configuring Banner Effort Reporting and Labor Redistribution for

CAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Configuring Banner Flexible Registration for CAS . . . . . . . . . . . . . . . . . 103
Supported versions of CAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Processing flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
CAS-protected URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Configuring Banner Integration for Ellucian Talent Management Suite

for CAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Processing flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Processing notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Configuring Banner Travel and Expense Management for CAS . . . . . . 112
Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Processing flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Processing notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Configuring Banner Workflow for CAS . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Processing flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Integration with BDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Configuring Ellucian Degree Works for CAS. . . . . . . . . . . . . . . . . . . . . . 122
Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Processing flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Configuring Ellucian Luminis Platform 5 for CAS. . . . . . . . . . . . . . . . . . 127
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Introduction
Your institution must maintain numerous software applications and environments to meet
the daily needs of your students, faculty, and administrators. The complexity of these
applications and environments requires the implementation of an identity management
infrastructure.
Identity management
An identity management infrastructure provides two basic functions:
• Account provisioning creates, maintains, and deactivates user identity data in a

central identity vault or in multiple applications.
Refer to the Banner® Enterprise Identity Services User Guide for details on account
provisioning.
• Single sign on (SSO) allows a user to securely access multiple systems with a single
login. Web applications can authenticate a user without accessing the user’s security
credentials. Many higher education institutions use Central Authentication Service
(CAS) to implement SSO.
This handbook focuses on the use of CAS to authenticate users for SSO.
Ellucian integration with CAS

CAS is an open source SSO authentication service for web applications. CAS is the
officially supported SSO authentication protocol for Ellucian applications. Ellucian
integration with CAS is certified for CAS server 3.4.12 and above.
Note: Refer to http://downloads.jasig.org/cas for a list of available CAS

server versions.
This handbook describes the configuration of the following Ellucian applications for use
with CAS:
Configuration
Ellucian application instructions
Banner - Self-Service (SSB) Page 29
Banner - Internet-Native (INB) Page 41
CAS Single Sign On Handbook | Introduction 7

Configuration
Ellucian application instructions
Banner - 9.x Page 78
Banner Document Management Page 89
Banner Effort Reporting and Labor Redistribution Page 102
Banner Flexible Registration Page 103
Banner Integration for Ellucian Talent Management Suite Page 108
Banner Travel and Expense Management Page 112
Banner Workflow Page 116
Ellucian Degree Works Page 122
Ellucian Luminis® Platform 5 Page 127
Documentation will be added to this handbook as more Ellucian applications are tested for
integration with CAS.
CAS Single Sign On Handbook | Introduction 8

Functional Concepts
This chapter describes functional concepts regarding the role of single sign on (SSO) and
Central Authentication Service (CAS) in your identity management infrastructure. You
should read and understand this information before you implement CAS at your institution.
What is SSO?
Single sign on (SSO) allows a user to securely access multiple systems with a single
login. Defined business processes and a supporting technical infrastructure determine
who can access systems, when systems can be accessed, and from where systems can
be accessed. Once a central service authenticates a user, the user is granted access to
multiple systems without repeated requests for login.
SSO gives your institution a unified mechanism to authenticate users and implement
business rules that determine user access to local, remote, and legacy applications and
data. SSO provides the following benefits:
• Improved user productivity. Users do not need to log in multiple times. Users do not
need to remember multiple IDs and passwords.
• Improved developer productivity and efficiency. SSO provides a common authentication

framework.
• Simplified administration. The burden of managing user accounts is simplified. The need
to reset forgotten passwords is reduced.
• Enhanced security. Having a single password promotes stronger passwords.
What is third-party authentication?

Third-party authentication is a process that uses a trusted external source to facilitate
access to specific applications. The following are examples of trusted third-party
authentication solutions:
• Open source - Central Authentication Service (CAS) and Shibboleth

• Commercial products - Novell Access Manager, Oracle Access Manager, CA
SiteMinder, and Microsoft Active Directory Federation Services (AD FS)
CAS Single Sign On Handbook | Functional Concepts 9

What is claims-based authentication?
Many third-party authentication systems use claims-based authentication to manage user
identities. Claims about a user’s identity are contained in a trusted token that is issued and
signed by a trusted entity. The user’s authentication is based on these claims.
An example of claims-based authentication is an airplane passenger presenting a

passport (trusted token signed by a government body) to authenticate his or her identity.
Refer to “An analogy” on page 13 for a more detailed example.
What is a common identifier?

A key feature of an identity management infrastructure is a common definition of user
identity that can be shared among applications. For Ellucian applications, this is
represented by the UDCIdentity XML structure.
The key element in the UDCIdentity XML structure is the UDCIdentifier, a globally unique
identifier (GUID) that is assigned to each user at your institution and stored in a central
identity vault. The UDCIdentifier is an unchanging, system-generated, 32-character,
alphanumeric value. The following example shows the UDCIdentifier:
<UDCIdentifier>36BE6D6D18560C44E0440003BA33B440</UDCIdentifier>
The UDCIdentifier identifies a user whenever access to protected resources is requested.

The UDCIdentifier provides the basis of SSO between a central access manager (such as
CAS) and Ellucian applications. This is accomplished by provisioning the UDCIdentifier
within the UDCIdentity XML structure. After a user successfully authenticates to the
central access manager, the user’s digital identity is asserted through the UDCIdentifier.
Applications can use the UDCIdentifier natively to identify the user and grant access.
What is CAS?
Central Authentication Service (CAS) is an open source SSO authentication service for
web applications. Originally developed by Yale University, CAS became a Jasig project in
December 2004.
At a high level, CAS offers the following features:
• Leverages CAS tickets to provide seamless authentication to external applications

• Protects the configured URL space
• Provides authentication services
• Supports configuration with multiple authentication providers
• Supports multiple authentication mechanisms:

• LDAP (Lightweight Directory Access Protocol)
• AD (Active Directory)
• DB (database)
• Commercial products
Many higher education institutions use CAS to implement SSO. Although CAS can be
implemented in a few hours, a fully functional SSO implementation that is supported by
CAS requires considerable planning and preparation. Integrated applications must be
configured to participate in a CAS-controlled environment. Many client programs are
available to customize applications so they can use CAS for user authentication.
The following diagram shows an example of ticket-based SSO using CAS. In this
example, several applications use a centralized CAS server and LDAP directory. Various
versions of Banner® are used at the same time: Banner 9.x, Internet-Native Banner (INB),
and Self-Service Banner (SSB). Third-party applications are also configured to participate
in the CAS-controlled environment.

How does Banner support identity management?
Banner® Enterprise Identity Services (BEIS) is a collection of Banner components that
support your institution’s identity management infrastructure:
Note: Depending on your requirements and implementation, the SSO

Manager can be deployed with or without the other components.
Batch utilities and account provisioning components

User data must be provisioned among various applications. This can be accomplished by
using BEIS account provisioning components or by using a third-party identity
management system.
If BEIS is used
If BEIS account provisioning components are deployed, BEIS performs the following
processing:
• Generate the UDCIdentifier, a globally unique identifier (GUID).

• Create a cross-reference in Banner between the UDCIdentifier and the PIDM.
• Send updates to defined clients, such as the central identity vault or other Ellucian
products that require account provisioning.
If a third-party identity management system is used

If BEIS account provisioning components are not deployed, you need an alternative
mechanism to perform the following:
• Generate the UDCIdentifier.

• Update Banner with the UDCIdentifier.
• Propagate the UDCIdentifier to the central identity vault that CAS uses to authenticate
users.

SSO Manager
The SSO Manager is a BEIS component that provides a single sign on gateway for SSB
and INB. The SSO Manager allows SSB and INB to participate in a claims-based
authentication environment. Claims about a user’s identity are contained in a trusted token
that is issued and signed by a trusted entity. The user’s authentication is based on these
claims.
The SSO Manager relies on a central access manager (such as CAS) to authenticate a
user and assert the user’s identity. Once a user is authenticated, the SSO Manager
performs the operations that allow the user to access SSB or INB.
The SSO Manager supports the following SSO configurations:
• CAS-based authentication. CAS protects the SSO Manager by authenticating the user.
After the user is authenticated, the SSO Manager invokes a validation service that is
exposed by the CAS server. This service validates the CAS session and provides the
identity of the user to the SSO Manager in a defined XML format.
Note: The SSO Manager fully supports the CAS server that is delivered
with Luminis® Platform 5.x.
• Third-party authentication. A third-party identity management system protects the SSO

Manager by authenticating the user and asserting the user’s identity to the SSO
Manager using a cookie, HTTP header, or parameter.
The SSO Manager also provides services that other Ellucian applications can use to
facilitate claims-based authentication based on the UDCIdentifier.
An analogy
The following analogy illustrates how Ellucian applications work with CAS to establish and
manage SSO.
An airplane passenger must present a trusted, government-issued document (such as a

passport or driver’s license) to airport security and to airline agents. The name on the
document must match the name on the plane ticket for the passenger to access the airport
terminal and board the airplane.
Compare this airplane scenario to a user trying to access an Ellucian application:
Airplane scenario Ellucian scenario
The terminal and the airline require a Ellucian applications (such as Banner and
passenger to authenticate his or her Luminis) require a user to authenticate his
identity. or her identity.
An airplane passenger tries to board an A user tries to access an Ellucian

airplane. application.

Airplane scenario Ellucian scenario
A government-issued document is A trusted token, issued by a third-party

required for identification purposes. authentication system, is required for
identification purposes. For Ellucian
applications, the trusted token is the
UDCIdentifier.
Airport security performs the operations The SSO Manager performs the
that allow the passenger to board the operations that allow the user to access
airplane. INB or SSB.

Getting Started
The following tasks should be performed before you configure Ellucian products to use
Central Authentication Service (CAS) for single sign on (SSO):
• Plan your CAS implementation (page 15)

• Map globally unique identifiers (GUIDs), if necessary (page 16)
• Configure the CAS server (page 17)
Plan your CAS implementation

You must plan your CAS implementation, whether it is a new implementation or a CAS
upgrade.
New implementation of CAS

Plan for a new implementation as follows:
• Include both technical and functional representation in the planning and implementation
process.
• Determine the overall goal. Identify which applications should participate in a claims-
based SSO environment, and which applications should not.
• Review your institution’s current password policies.

• Ensure that the technical team responsible for implementing and maintaining CAS is
familiar with SSO concepts and CAS. Refer to “Prerequisites” on page 17 for details.
• Evaluate hardware and server requirements.

• Determine what will serve as the central identity vault.
• Inform your end users of any changes in login behavior.
• Train help desk personnel regarding the implementation so they can answer user
questions and troubleshoot any issues.
• Create a test plan and test environment.
CAS Single Sign On Handbook | Getting Started 15

CAS upgrade
Plan for an upgrade as follows:
• Determine the differences between the old and new versions of CAS.
• Determine the impact on the applications that are participating in your claims-based
environment?.
• Determine how the CAS upgrade impacts your current Ellucian applications.
• Create a test plan and a test environment.
Map GUIDs
SSO with CAS is designed to use the UDCIdentifier as the globally unique identifier
(GUID) for each user at your institution. The UDCIdentifier identifies a user whenever
access to protected resources is requested. The UDCIdentifier for each user is stored in
the central identity vault.
Banner® Enterprise Identity Services (BEIS) includes optional account provisioning

components that manage UDCIdentifiers. The absence or presence of these BEIS
components determines whether the UDCIdentifier is used as the GUID.
Each Ellucian application can be configured to accept a custom configured assertion

name, such as UDCIdentifier. This assertion name, however, can be different.
If BEIS account provisioning is deployed

If BEIS account provisioning is deployed, BEIS assigns and stores a UDCIdentifier in
Banner whenever a person record is created. BEIS account provisioning also stores the
generated UDCIdentifier in the central identity vault.
The coordination of the UDCIdentifier in Banner and in the central identity vault facilitates
SSO. After a user is authenticated, the consuming application uses the UDCIdentifier that
is stored in the central identity vault to identify the user in Banner. If the identifiers match,
access is granted to the authenticated user.
If BEIS account provisioning is not deployed

If BEIS account provisioning is not deployed, you must map the GUID that is stored in
Banner to the GUID that is stored in the central identity vault as follows:
• GUID stored in Banner. The GUID for a person is stored in the GOBUMAP table. The
column GOBUMAP_UDC_ID is VARCHAR2(225) and is designed to store the
UDCIdentifier. Any unique identifier for the person can be stored in this column.

• GUID stored in the central identity vault. The same GUID must be stored in the
central identity vault so it can be retrieved by /samlValidate requests and wrapped in the
appropriate XML tag. A baseline BEIS configuration sets the LDAP cn attribute with the
value of the UDCIdentifier XML tag. The CAS server is configured to retrieve this value
for /samlValidate requests.
As long as the GUIDs stored in these two repositories are coordinated and retrievable as
the UDCIdentifier, access through the consuming application is possible.
Configure the CAS server

Depending on your environment, a CAS server might already be in place. This chapter
provides information for common implementation scenarios:
• Installing a new CAS server from the Jasig distribution

• Installing a new CAS server as part of the Luminis Platform 5 installation
• Configuring Banner to use an existing CAS server
• Installing and configuring Luminis Platform 5 to use an existing CAS server
Prerequisites
CAS server 3.4.12 is the minimum supported version. Before you configure the CAS
server, you must be familiar with the following applications:
• CAS protocol 2.0

• CAS architecture 3.4
• CAS server 3.4.12
• Maven 3.x
• Tomcat
Installing a new CAS server from the Jasig distribution

Use the following steps to install a CAS server from the Jasig distribution:
• Step 1 - Download the Jasig CAS server distribution

• Step 2 - Modify pom.xml
• Step 3 - Download Maven and install the Oracle JDBC driver
• Step 4 - Modify cas.properties
• Step 5 - Modify deployerConfigContext.xml

• Step 6 - Modify ticketRegistry.xml
• Step 7 - Customize the CAS login and logout pages
• Step 8 - Build cas.war
• Step 9 - Deploy cas.war
• Step 10 - Test the CAS web application
• Step 11 - Configure a CAS service to protect the CAS services URL
Note: If you are moving to Luminis® Platform 5, you can install the CAS
server that is delivered with Luminis Platform 5. Refer to “Installing a new
CAS server as part of the Luminis Platform 5 installation” on page 27 for
details.
Warning! Be careful if you copy and paste code samples from this
document into your configuration files. Unexpected spaces in copied code
can cause problems.
The following sections provide details for each step.
Step 1 - Download the Jasig CAS server distribution

Use the following steps to download the Jasig CAS server distribution.
1. Download Jasig CAS server 3.4.12 or higher from http://www.jasig.org/cas/download.
2. Extract the distribution .zip file. This action creates the cas-server-<version>
directory where <version> refers to the CAS server version.
Example: cas-server-3.4.12
Step 2 - Modify pom.xml

Use the following steps to add dependencies to pom.xml.
1. Navigate to the cas-server-<version> /cas-server-webapp directory.

This directory is referred to as <PROJECT_HOME>.
2. Open pom.xml in the <PROJECT_HOME> directory.

3. Add the following dependencies:

<dependency>
<groupId>org.jasig.cas</groupId>
<artifactId>cas-server-support-ldap</artifactId>
<version>${project.version}</version>
<type>jar</type>
</dependency>

<dependency>
<groupId>commons-dbcp</groupId>
<artifactId>commons-dbcp</artifactId>
<version>1.4</version>

<scope>runtime</scope>
</dependency>

<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>${hibernate.core.version}</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>${hibernate.core.version}</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc6</artifactId>
<version>11.2.0</version>
</dependency>
4. Save and close pom.xml.
Step 3 - Download Maven and install the Oracle JDBC driver

Apache Maven is used to build cas.war with built-in support for LDAP authentication
and CAS session and service persistence via Java Persistent Architecture (JPA). Use the
following steps to download Maven and add the Oracle JDBC driver to the Maven
repository.
1. Download and install Apache Maven from http://maven.apache.org/download.cgi.
Note: Refer to Maven documentation for installation instructions.
2. Download ojdbc6.jar from the JDBC Driver Download section of http://

www.oracle.com/technetwork/database/features/jdbc/index-
091264.html?ssSourceSiteId=ocomen to a directory. This directory is referred to as
<OJDBC6_DIR>.
3. Execute the following command to install ojdbc6.jar into the Maven repository:
mvn install:install-file -Dfile=<OJDBC6_DIR>/ojdbc6.jar -

DgroupId=com.oracle -DartifactId=ojdbc6 -Dversion=11.2.0
-Dpackaging=jar
Step 4 - Modify cas.properties

Use the following steps to modify cas.properties.
1. Navigate to <PROJECT_HOME>/src/main/webapp. This directory is referred to

as <PROJECT_WEBROOT>.
2. Open <PROJECT_WEBROOT>/WEB-INF/cas.properties.
3. Update the server.prefix property to specify the CAS server protocol, host, and
port.
Example: server.prefix=https://cas.ellucian.com:8443/cas

4. Update the host.name property to specify the CAS server host.
Example: host.name=cas.ellucian.com
5. (Optional) In the default deployment, volatile data is cleared when the application
restarts. If you want to persist the data, use the following steps to change the
configuration:
5.1. Make sure the following entry is present and uncommented:
database.hibernate.dialect=org.hibernate.dialect.
OracleDialect
5.2. Add the following property:
ticket.cleaner.database.platform=SQL92
6. Save and close cas.properties.
Step 5 - Modify deployerConfigContext.xml

Use the following steps to add specific entries for your LDAP configuration to
deployerConfigContext.xml.
1. Open <PROJECT_WEBROOT>/WEB-INF/deployerConfigContext.xml.
2. Remove the following beans inside list in the credentialsToPrincipal

Resolvers property:
<bean class=
"org.jasig.cas.authentication.principal.UsernamePasswordCredentialsToPrincipalResolver"
/>
<bean class=
"org.jasig.cas.authentication.principal.HttpBasedServiceCredentialsToPrincipalResolver"
/>
3. Add the following bean inside list in the credentialsToPrincipal

Resolvers property:
<bean class=
"org.jasig.cas.authentication.principal.CredentialsToLDAPAttributePrincipalResolver">
<property name="credentialsToPrincipalResolver">
<bean class=
"org.jasig.cas.authentication.principal.UsernamePasswordCredentialsToPrincipalResolver"
/>
</property>
<property name="filter" value="(uid=%u)" />
<property name="principalAttributeName" value="uid" />
<property name="searchBase" value="ou=users,dc=ellucian,dc=com" />
<property name="contextSource" ref="contextSource" />
<property name="attributeRepository">
<ref bean="attributeRepository" />
</property>
</bean>
Note: Modify property name="searchBase" to specify the

correct searchBase entry for your LDAP. Change "ou=users,
dc=ellucian,dc=com" to reflect your environment.

4. By default, CAS provides two authentication handlers. Remove the second handler
inside list in the authenticationHandlers property.
<bean class=
"org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler" p:httpClient-
ref="httpClient"
/>
<bean class=
"org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHand
ler"
/>
5. Add the following bean inside list in the authenticationHandlers property:

<bean class=
"org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler" >
<property name="filter" value="uid=%u" />
<property name="searchBase" value="ou=users,dc=ellucian,dc=com" />
<property name="timeout" value="10">
</property>
</bean>
Note: Modify property name="searchBase" to specify the

correct searchBase entry for your LDAP. Change "ou=users,
dc=ellucian,dc=com" to reflect your environment.
6. Update bean userDetailsService to define an LDAP user to support CAS

administration functions. This user must already exist in LDAP. Specify the user ID of
the CAS administration user with the default CAS administration role.
<sec:user-service id="userDetailsService">
<sec:user name="casadmin" password="notused" authorities="ROLE_ADMIN" />
</sec:user-service>
7. Replace the attributeRepository bean with the following bean. This bean is
used to specify the attributes that must be fetched from LDAP.
<bean id="attributeRepository"
class="org.jasig.services.persondir.support.ldap.LdapPersonAttributeDao">
<property name="baseDN" value="ou=users,dc=ellucian,dc=com" />
<property name="requireAllQueryAttributes" value="true" />

<property name="queryAttributeMapping">
<map>
<entry key="username" value="uid" />
</map>
</property>
<property name="resultAttributeMapping">
<map>

<entry key="cn" value="UDC_IDENTIFIER"/>
<entry key="uid" value="uid" />
</map>
</property>
</bean>
Note: Modify property name="baseDN" to specify the correct baseDN

entry for your LDAP. Change "ou=users,dc=ellucian,dc=com"
to reflect your environment.
8. Add the contextSource bean. This bean is used to specify the LDAP properties.
<bean id="contextSource"
class="org.springframework.ldap.core.support.LdapContextSource">
<property name="pooled" value="false"/>
<property name="urls">

<list>
<value>ldap://LDAP_HOST:389</value>
</list>
</property>
<property name="userDn" value="cn=Manager,dc=ellucian,dc=com"/>
<property name="password" value="u_pick_it"/>
<property name="baseEnvironmentProperties">
<map>
<entry>
<key>
<value>java.naming.security.authentication</value>
</key>
<value>simple</value>
</entry>
</map>
</property>
</bean>
Note: Modify the LDAP URL, userDn, and password to reflect your LDAP
configuration. Change "dc=ellucian,dc=com" to reflect your
environment.
9. Use one of the following methods (in-memory data store or JPA-based registry) to
store session and service registry data.
9.1. An in-memory (persistent) data store can be used to store session and service
registry data. Volatile data is cleared during application restarts. Service
registrations are stored statically in deployerConfigContext.xml.To
implement an in-memory data store, change the following bean:
<bean id="serviceRegistryDao"
class="org.jasig.cas.services.InMemoryServiceRegistryDaoImpl">
<property name="registeredServices">
<list>

<bean class="org.jasig.cas.services.RegisteredServiceImpl">
<property name="id" value="1" />
<property name="name" value="CAS Managed Services" />
<property name="description" value="CAS Managed Services Endpoint" />
<property name="serviceId" value="https://[cas.host.edu]:[cas.port]/cas/
services/**" />
<property name="allowedAttributes">
<list>
<value>uid</value>
</list>
</property>
<property name="evaluationOrder" value="10000001" />
</bean>

<bean class="org.jasig.cas.services.RegisteredServiceImpl">
<property name="id" value="2" />
<property name="name" value="SSO Manager" />
<property name="description" value="CAS Client for SSB/INB" />
<property name="serviceId" value="http://
[ssomanager.host.edu]:[ssomanager.port]/ssomanager/c/**" />
<property name="allowedAttributes">
<list>
<value>UDC_IDENTIFIER</value>
</list>
</property>
<property name="evaluationOrder" value="10000002" />
</bean>
</list>
</property>
</bean>
9.2. A JPA-based session and service registry is preferred in a production

environment. To implement a JPA-based data store, use the following steps:
Modify the following bean:
<bean id="serviceRegistryDao"
class="org.jasig.cas.services.JpaServiceRegistryDaoImpl"
p:entityManagerFactory-ref="entityManagerFactory" />

Add the following bean definitions under the beans root element:
<bean id="entityManagerFactory"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="dataSource"/>
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
<property name="generateDdl" value="true"/>
<property name="showSql" value="true" />
</bean>
</property>
<property name="jpaProperties">
<props>
<prop key="hibernate.dialect">org.hibernate.dialect.OracleDialect</prop>
<prop key="hibernate.hbm2ddl.auto">update</prop>
</props>
</property>
</bean>
<bean id="transactionManager"
class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory"/>
</bean>
<tx:annotation-driven transaction-manager="transactionManager"/>
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"
p:driverClassName="oracle.jdbc.driver.OracleDriver"
p:url="jdbc:oracle:thin:@localhost:1521:ORCL" p:username="scott" p:password="tiger" />
Note: For bean id="dataSource", modify the URL, user name, and
password to reflect your environment. The user name and password must
be a valid Oracle user name and password. You can use the ssomgr
Oracle account that was created to store CAS managed services
information.
Add the tx: namespace to the beans root element:

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p="http://www.springframework.org/schema/p"
xmlns:sec="http://www.springframework.org/schema/security"
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation=
"http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/security
http://www.springframework.org/schema/security/spring-security-3.0.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-3.0.xsd">
10. Save and close deployerConfigContext.xml.
Step 6 - Modify ticketRegistry.xml
Note: Use this step only if you are using a JPA-based session and service
registry. Skip this step if you are using an in-memory data store to store
session and service registry data.
Use the following steps to modify ticketRegistry.xml.
1. Open <PROJECT_WEBROOT>/WEB-INF/spring-configuration/
ticketRegistry.xml.

2. Replace the entire file contents with the following.
<?xml version="1.0" encoding="UTF-8"?>

<beans
xmlns="http://www.springframework.org/schema/beans"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation=
"http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
<description>
Configuration for the JPA based TicketRegistry which stores the tickets in the db and
cleans them out at specified intervals.
</description>

<bean id="ticketRegistry" class="org.jasig.cas.ticket.registry.JpaTicketRegistry" />

<bean
class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"/>
<bean id="ticketRegistryCleaner"
class="org.jasig.cas.ticket.registry.support.DefaultTicketRegistryCleaner"
p:ticketRegistry-ref="ticketRegistry"
p:lock-ref="cleanerLock"/>
<bean id="cleanerLock"
class="org.jasig.cas.ticket.registry.support.JpaLockingStrategy"
p:uniqueId="${host.name}"
p:applicationId="cas-ticket-registry-cleaner" />
<bean id="ticketRegistryCleanerJobDetail"
class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean"
p:targetObject-ref="ticketRegistryCleaner"
p:targetMethod="clean"/>
<bean id="periodicTicketRegistryCleanerTrigger"
class="org.springframework.scheduling.quartz.SimpleTriggerBean"
p:jobDetail-ref="ticketRegistryCleanerJobDetail"
p:startDelay="20000"
p:repeatInterval="1800000"/>
</beans>
3. Save and close ticketRegistry.xml.
Step 7 - Customize the CAS login and logout pages

Use the following steps to customize the CAS login and logout pages.
1. Open <PROJECT_WEBROOT>/themes/default/cas.css.
2. Edit the cas.css style sheet to include your customizations.
3. Save and close cas.css.
4. Open <PROJECT_WEBROOT>/images. This directory contains the images for

logos, footers, and other graphics.
5. Edit the images. The easiest way to customize a theme is to rename each custom
image to its default counterpart.

6. (Optional) If you want to add components to the login and logout pages:
6.1. Open the <PROJECT_WEBROOT>/WEB-INF/view/jsp/default/ui
directory.
6.2. Edit the following pages, as needed:
casLoginView.jsp
casLogoutView.jsp
6.3. Save and close the pages.

7. (Optional) If you want to edit locale messages (such as the welcome message, failed
login, and form validation) that support internationalization:
7.1. Open the <PROJECT_WEBROOT>/WEB-INF/classes directory.
7.2. Edit the appropriate message properties files.
7.3. Save and close the message properties files.
8. Back up the changes to an external directory.
Note: Future product upgrades will overwrite the edits. You can use the
backup to reset the changes.
Another way to customize the style sheet and images is to create a new theme in the
<PROJECT_WEBROOT>/themes directory. Once you create a new theme, you must
edit the CAS service to use the new theme rather than the default theme. The new theme
is not overwritten during a product upgrade. Refer to "Custom-themed login pages" in the
Luminis Platform Multi-Entity Processing Implementation Guide for details.
Step 8 - Build cas.war

Use the following steps to build cas.war.
1. Navigate to the <PROJECT_HOME> directory.
2. Execute the following command to create cas.war in the <PROJECT_HOME>

directory:
mvn clean package
Step 9 - Deploy cas.war

Use the following steps to deploy cas.war.
1. Navigate to the <PROJECT_HOME> directory.
2. Locate cas.war.
3. Deploy cas.war to Tomcat.

4. Ensure that SSL is enabled on Tomcat.

Step 10 - Test the CAS web application
Use the following steps to test the CAS web application.
1. Access the CAS login page:
https://<CAS host>:<CAS port>/<CAS context path>
2. Log in as the CAS administration user that was defined in Step 5 - Modify
deployerConfigContext.xml, substep 6. This must be an existing LDAP user.
Step 11 - Configure a CAS service to protect the CAS services URL
Note: Use this step only if you are using a JPA-based session and service
registry. Skip this step if you are using an in-memory data store to store
session and service registry data.
Note: Skip this step if this CAS service was previously configured.
The CAS server needs to know which application URLs must be protected for SSO. This
is accomplished by configuring a CAS service for each application in your CAS
environment. Application-specific instructions are provided in individual chapters of this
handbook.
You must also configure a CAS service to protect the CAS service URL itself. This CAS
service applies to all applications in your CAS environment. Use the following steps to
configure this CAS service.
1. Access the CAS server management page:
https://<CAS host>:<CAS port>/<CAS context path>/
services/manage.html
2. Log in with a valid administrator user name and password (obtained from the CAS
administrator).
3. Select the Add New Service tab.
4. Enter the following values:
Name cas services

Service URL http(s)://<CAS host>:<CAS port>/<CAS
context path>/services/**
Description Protect cas services
Status Select Enabled and SSO Participant.
Attributes Select uid.

5. Click Save Changes. The CAS server is now protecting the /<CAS context
path>/services URL.
Installing a new CAS server as part of the Luminis

Platform 5 installation
If you are moving to Luminis Platform 5, you can install the CAS server that is delivered as
part of Luminis Platform 5. Refer to the Luminis Platform 5.1 Installation Guide for
deployment options and detailed installation instructions.
Configuring Banner to use an existing CAS server

You can configure Banner to use a CAS server that is already installed. CAS server 3.4.12
is the minimum supported version.
If you have a supported version of CAS, refer to “Configuring Banner for CAS” on page 29
for instructions to configure Banner for the existing CAS server.
If you do not have a supported version of CAS, refer to “Installing a new CAS server from
the Jasig distribution” on page 17 for instructions to install and configure a supported
version of the CAS server.

Installing and configuring Luminis Platform 5 to use an
existing CAS server
If you are moving to Luminis Platform 5, you can install and configure Luminis Platform 5
to use a CAS server that is already installed. Refer to Chapter 6, "External CAS
Installation and Configuration," in the Luminis Platform 5.1 Installation Guide for
instructions to configure Luminis Platform 5 to use an external CAS server.

Configuring Banner for CAS
This chapter describes the configuration of Banner® to support single sign on (SSO) via
Central Authentication Service (CAS). Instructions are provided for configuring the
following Banner products:
• Self-Service Banner (SSB) on page 29

• Internet-Native Banner (INB) on page 41
• Banner 9.x on page 78
SSB configuration for CAS

SSO for SSB requires the SSO Manager, a component of Banner Enterprise Identity
Services (BEIS). The SSO Manager acts as the SSO gateway for SSB, bypassing native
SSB authentication.
Note: In addition to the SSO Manager, BEIS includes components that

support account provisioning. Depending on your requirements and
implementation, the SSO Manager can be deployed with or without the
account provisioning components.
The SSO Manager relies on CAS to authenticate a user and assert the user’s identity. This
protects the SSB access URLs that are exposed by the SSO Manager. Once CAS
authenticates a user, the SSO Manager collaborates with Banner Web Tailor to allow the
user to access SSB.
Supporting components
The following components support SSO for SSB:
Component Description
CAS CAS is the central access manager for SSO. CAS attribute
assertion features facilitate SSO. A CAS validation service
(/samlValidate) retrieves the attributes that identify the user.
CAS Single Sign On Handbook | Configuring Banner for CAS 29

SSO Manager The SSO Manager, a component of BEIS, acts as the SSO
gateway for SSB, facilitating the following processes when
starting an SSO session:
• Retrieval of the user’s unique identifier (UDCIdentifer) from the
central identity vault via /samlValidate
• Proxy of SSO requests in an SSO environment that is
administered by BEIS
Refer to the Banner Enterprise Identity Services Installation
Guide for instructions on installing the SSO Manager. You can
install the SSO Manager with or without other BEIS
components.
Banner Web Tailor Banner Web Tailor accepts the identity assertion from the SSO
Manager, determines the user based on the assertion, and
creates an SSB session for the user.
Banner Web Tailor is required as follows:

• If Cascade is enabled, Banner Web Tailor 8.4.2 or later must
be installed.
• If Cascade is not enabled, Banner Web Tailor 8.3.1 plus patch
p1-dc06g9_twb8030101, or later, must be installed.
Processing flow
The following processing occurs when SSB is accessed in an SSO session:

Component Processing step
User 1. Opens a web browser and requests access to SSB through

a protected URL:
http(s)://<host>:<port>/ssomanager/c/SSB
Note: If the standard SSB URL is used, native SSB
authentication (SPRIDEN ID and PIN), rather than SSO, is
used to access SSB.
2. Is redirected to the CAS login page over an HTTPS
connection. The name of the requested application is
passed as a parameter.
3. Logs in to CAS.
CAS 4. Authenticates the user.

5. Issues a ticket to the SSO Manager.
SSO Manager 6. Creates a Security Assertion Markup Language (SAML) 1.1

request.
7. Calls the CAS /samlValidate service, passing the ticket and
service name as parameters.
CAS /samlValidate 8. Validates the ticket.

9. Ensures that the ticket is associated with the requested
service.
10.Retrieves configurable identity attributes (for example, the
UDCIdentifier) from the central identity vault.
11. Returns a SAML response, which contains the user’s
network ID and UDCidentifier, to the SSO Manager. A
sample response is shown on page 32.
SSO Manager 12.Calls Banner Web Tailor.
SSB 13.Uses the UDCIdentifier to look up the associated Banner

(Banner Web Tailor) PIDM.
14.Inserts or updates a row in the Web Tailor Web SessionID
(TWGBWSES) table, indicating that a session was started
and properly authenticated.
15.Returns control to the SSO Manager.
SSO Manager 16.Redirects the user’s browser to Banner Web Tailor.
SSB 17.Verifies the following:

(Banner Web Tailor) - A row exists in the TWGBWSES table for the PIDM
associated with the UDCIdentifier that is stored in the
cookie created by the SSO Manager.
- The last access date is valid.
These verifications ensure that the session was started after
authentication. This prevents hackers from setting cookies
with a non-authenticated UDCIdentifier.

Sample SAML response
The following example shows a sample SAML response if /samlValidate successfully
retrieves the UDCIdentifier. The Attribute tag in the AttributeStatement
section contains the UDCIdentifier. The AuthenticationStatement section
contains the authenticated network ID.
<Response xmlns="urn:oasis:names:tc:SAML:1.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
IssueInstant="2011-08-13T10:56:13.378Z"
MajorVersion="1"
MinorVersion="1"
Recipient="http://jellyfish.greatvalleyu.com:7777/ssomanager/c/SSB"
ResponseID="_df63003ff7bf6f645a2d08a2e2c2cc76">
<Status>
<StatusCode Value="samlp:Success"></StatusCode>
</Status>
<Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion"
AssertionID="_306176fd94a8677cab6056dc3e8c892e"
IssueInstant="2011-08-13T10:56:13.378Z"
Issuer="localhost"
MajorVersion="1"
MinorVersion="1">
<Conditions NotBefore="2011-08-13T10:56:13.378Z"
NotOnOrAfter="2011-08-13T10:56:43.378Z">
<AudienceRestrictionCondition>
<Audience>http://jellyfish.greatvalleyu.com:7777/
ssomanager/c/SSB
</Audience>
</AudienceRestrictionCondition>
</Conditions>
<AttributeStatement>
<Subject>
<NameIdentifier>saisusr</NameIdentifier>
<SubjectConfirmation>
<ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:
cm:artifact</ConfirmationMethod>
</SubjectConfirmation>
</Subject>
<Attribute AttributeName="UDC_IDENTIFIER"
AttributeNamespace="http://www.ja-sig.org/products/cas/">
<AttributeValue>2F10C881AC7D55942329E149405DC2F5
</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthenticationStatement
AuthenticationInstant="2011-08-13T10:56:13.347Z"
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:
unspecified">
<Subject>
<NameIdentifier>saisusr</NameIdentifier>
<SubjectConfirmation>
<ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:
cm:artifact
</ConfirmationMethod>
</SubjectConfirmation>
</Subject>
</AuthenticationStatement>
</Assertion>
</Response>
Configuration steps
Use the following steps to configure SSB for CAS:
• Step 1 - Configure Banner Web Tailor to use the SSO Manager with SSB
• Step 2 - Configure the SSO Manager for SSB

• Step 3 - Configure a CAS service for the SSO Manager
• Step 4 - Verify the configuration
Step 1 - Configure Banner Web Tailor to use the SSO Manager with SSB
Use the following steps to edit the Banner Web Tailor parameters that are used by the
SSO Manager.
1. Enter the Secure Area of Self-Service Banner.
2. Navigate to Web Tailor Administration.
3. From the Web Tailor Menu, select Web Tailor Parameters.
4. For each of the following parameters, click the parameter name, enter the parameter
value, and click Submit Changes.
Parameter Description
IDMLOGINURI Login URL:
http(s)://<CAS server>:<CAS port>/

<CAS context path>/login
Example: https://my-cas-
server.edu:8443/cas-web/login
IDMLOGOUTURI Logout URL:
http(s)://<CAS server>:<CAS port>/

<CAS context path>/logout
Example: https://my-cas-
server.edu:8443/cas-web/logout
Note: If you are using the CAS server that was
delivered with Luminis® Platform 5.x, use
http(s)://server/c/portal/logout.
IDMTIMEOUT Time in seconds that information contained in the
IDMSESSID cookie is trusted. IDMTIMEOUT= 0
means session timeout is not enforced.
IDMSSO Flag that determines whether SSO with the SSO

Manager is enabled (Y) or not enabled (N). If enabled,
SSB can be accessed using the SSO Manager.
IDMCOOKIE Name of the SSO Manager SSO cookie. Suggested

value is IDMSESSID. This value must be the same as
the UDC ID key that is specified on the SSB
Configuration page of the SSO Manager administrative
interface.

IDMCOOKIEDOMAIN Domain where the cookie is created (for example,

.university.edu.). This value must be the same
as the cookie domain name entered on the SSB
Configuration page of the SSO Manager administrative
interface. This parameter value must begin with a
period (.).
IDMCOOKIEPATH Path where the cookie is created (for example, /).
Step 2 - Configure the SSO Manager for SSB

Use the following steps to configure the SSO Manager for SSB.
1. Access the SSO Manager administrative interface:
http://<host>:<port>/ssomanager
2. Log in with the SSO Manager credentials.
3. Select SAML Validate.
4. Click Save.
5. Select the SSB Configuration tab.

6. Enter the following SSB configuration information:
SSB URL Default URL where users are redirected when they request
the protected SSB URL. This is normally the SSB main
menu page:
http(s)://<host>:<port>/<dad-name>/
twbkwbis.P_GenMenu?name=bmenu.P_MainMnu
SSB Deep Linking Check box that indicates whether deep-linking is supported:
selected Deep-linking is supported. The Base URL

and URL Parameter Name fields can be
edited.
cleared Deep-linking is not supported. The Base

URL and URL Parameter Name fields
cannot be edited.
Refer to “Deep-linking to SSB pages” on page 39 for more

details about deep-linking.
Base URL Base URL for accessing SSB. This URL is used to construct
the full URL when the SSO Manager requests a deep-linked
page.
http(s)://<host>:<port>/<dad-name>
The base URL does not identify a specific SSB page. Refer
to “Deep-linking to SSB pages” on page 39 for more details
about deep-linking.
URL Parameter Delimiter used to specify a target resource (packaged

Name procedure, function, or URL) to the SSO Manager. The SSO
Manager looks for this delimiter in deep-linked URL
requests to determine the requested target resource.
Refer to “Deep-linking to SSB pages” on page 39 for more

details about deep-linking.
Mode Type of central access manager that authenticates users for

SSO. Select CAS.
UDC ID Indicator Not used for CAS.
UDC ID Key Not used for CAS.
Cookie Name Name of the cookie that asserts the user’s identity
(UDCIdentifier) to SSB. The value of this parameter must
equal the value of the IDMCOOKIE parameter that is
defined in Banner Web Tailor. The suggested value is
IDMSESSID.

Cookie Domain Your institution’s domain name or server domain name (for
Name example, .institution.edu). This value must be the
same as the IDMCOOKIEDOMAIN parameter that is
defined in Banner Web Tailor. This parameter value must
begin with a period (.).
7. Click Save.
Note: A server restart is not required for these entries to take effect.
Step 3 - Configure a CAS service for the SSO Manager
Note: Skip this step if a CAS service was previously configured for the
SSO Manager.
The CAS server needs to know that the SSO Manager URL is protected for SSO. This is
accomplished by configuring a CAS service for the SSO Manager. Both INB and SSB
need this CAS service. Use the following steps to configure the CAS service that protects
the SSO Manager.
administrator).

Name sso manager cas client

Service URL http(s)://<SSO Manager server>:<SSO
Manager port>/ssomanager/**
Description Protect sso manager client
Attributes Select UDC_IDENTIFIER.
5. Click Save Changes. The CAS server is now protecting the SSO Manager URL.
Step 4 - Verify the configuration

Use the following steps to verify that SSO to SSB is configured properly.

3. In the Verification Links section, click CAS.
4. Verify that the CAS server is accessed correctly.

5. Log in to CAS using valid credentials for the environment.
6. Clear the cookies and close the browser.
7. Log in to the SSO Manager administrative interface again:

8. In the Gated Applications section, click Self Service Banner.
9. Log in to CAS with valid credentials for a known SSB user.

10. Ensure that the SSB main menu is displayed.
Deep-linking to SSB pages

Deep-linking is the ability to bypass a menu page and hyperlink directly to a specific SSB
page. The SSO Manager supports deep-linking through the protected URLs that it
exposes for accessing SSB. Applications that need to deep-link into SSB must supply the
appropriate URL parameters that identify the page where the user should be transferred.
The default SSB URL is defined on the SSB Configuration page within the SSO Manager
administrative interface. The browser is redirected to this default URL whenever a user
requests the SSB URL that is exposed by the SSO Manager.
Example:
The SSO Manager is configured to access the protected SSB main menu whenever
SSB is requested. In a CAS-based environment, the following URL is used to access
SSB:
http://<host>:<port>/ssomanager/c/SSB
Once the user is successfully authenticated, SSO Manager redirects the user to the
Self-Service Banner main menu:
http(s)://<host>:<port>/<dad-name>/
twbkwbis.P_GenMenu?name=bmenu.P_MainMnu.

The SSO Manager also supports the ability to link to a specific SSB page other than the
SSB main menu. This deep-linking is accomplished by adding parameters to the exposed
URL to specify a target resource. The resource can be the combination of a database
package and method (package.method), or it can be a complete URL.
To use this feature, the following parameters must be defined on the Self-Service Banner
Configuration page within the SSO Manager administrative interface:
SSB Deep Linking Check box that indicates whether deep-linking is

supported:
selected Deep-linking is supported.

cleared Deep-linking is not supported.
Base URL Base URL for accessing SSB. This URL is used to
construct the full URL when the SSO Manager requests a
deep-linked page:
http(s)://<host>:<port>/<dad-name>
The base URL does not identify a specific SSB page to
access.
Example: https://ssbserver.institution.
edu:9500/smpl/
URL Parameter Name Delimiter used to specify a target resource (packaged
procedure, function, or URL) to the SSO Manager. The
SSO Manager looks for this delimiter in deep-linked URL
requests to determine the requested target resource.
Example: If the value of the URL Parameter Name is pkg,

the string “?pkg=” in a URL request determines the target
resource.
The SSO Manager expects deep-link requests to SSB to use the following syntax:
<SSO Manager SSB URL>?<URL parameter name>=<target
resource>
When a request for a resource is received, the SSO Manager evaluates the URL, looking
for the delimiter specified as the URL parameter name. One of the following occurs:
• If the delimiter is not found, the SSO Manager redirects the browser to the default SSB
URL.
• If the delimiter is found and the target resource is a URL, the SSO Manager redirects to
the specified URL.
• If the delimiter is found and the target resource is not a URL, the SSO Manager
constructs a redirect URL and redirects the browser to the constructed URL:
<base URL>/<target resource>

Examples:
SSB access for a CAS-based environment is configured as follows:
SSO Manager SSB https://beisserver.institution.

URL edu:7777/ssomanager/c/SSB
SSB URL https://ssbserver.institution.
edu:9500/smpl/twbkwbis.
P_GenMenu?name=bmenu.P_MainMnu
Base URL https://ssbserver.institution.
edu:9500/smpl/
URL Parameter Name pkg
A deep-link to the Update E-mail Addresses - Select Address (bwgkogad.

P_SelectEmalUpdate) page in SSB can be made to the SSO Manager as
follows:
https://beisserver.institution.edu:7777/ssomanager/c/
SSB?pkg=bwgkogad.P_SelectEmalUpdate
A deep-link to a URL (for example, the URL for a different geographic locale) can be
made as follows:
SSB?pkg=https://ssbsmpl.greatvalley.edu:9500/frfr83/
bwgkogad.P_SelectEmalUpdate
The following request redirects the browser to the SSB Main Menu, because the URL
parameter name is not recognized:
SSB?res=bwgkogad.P_SelectEmalUpdate
INB configuration for CAS

SSO for INB requires the SSO Manager, a component of Banner Enterprise Identity
Services (BEIS). The SSO Manager acts as the SSO gateway for INB, bypassing native
INB authentication.
Note: In addition to the SSO Manager, BEIS includes components that

support account provisioning. Depending on your requirements and
implementation, the SSO Manager can be deployed with or without the
account provisioning components.
The SSO Manager relies on CAS to authenticate a user and assert the user’s identity. This
protects the INB access URLs that are exposed by the SSO Manager. Once CAS

authenticates a user, the SSO Manager collaborates with Oracle Forms runtime
components to allow the user to access INB.
The following components support SSO for INB:
SSO Manager The SSO Manager, a component of BEIS, acts as the SSO
gateway for INB, facilitating the following processes when
starting an SSO session:
• Retrieval of the user’s unique identifier (UDCIdentifer) from the
central identity vault via /samlValidate
• Creation of the INB ticket that is used to retrieve the user’s
Oracle credentials from the Credential web service
• Exposure of the Credential web service for storing and
retrieving application-specific credentials
Refer to the Banner Enterprise Identity Services Installation
Guide for instructions on installing the SSO Manager. You can
install the SSO Manager with or without other BEIS components.
ssoclient.jar This file contains Java components that communicate with the
Credential web service to obtain a user’s Oracle credentials for
logging in to INB.
GOBEACC table Each user must have a record in the GOBEACC table. This
record associates the user’s PIDM with the user’s Oracle ID.

Processing flow
The following processing occurs when INB is accessed in an SSO session:
User 1. Opens a web browser and requests access to INB through a

protected URL:
http(s)://<host>:<port>/ssomanager/c/INB
Note: If the standard INB URL is used, native INB
authentication (Oracle Forms user ID and password), rather
than SSO, is used to access INB.
2. Is redirected to the CAS login page over an HTTPS
connection. The name of the requested application is
passed as a parameter.
3. Logs in to CAS.

5. Issues a ticket to the SSO Manager.

SSO Manager 6. Creates a Security Assertion Markup Language (SAML) 1.1

request.
7. Calls the CAS /samlValidate service, passing the ticket and
service name as parameters.

9. Ensures the ticket is associated with the requested service.
10.Retrieves configurable identity attributes (for example, the
UDCIdentifier) from the central identity vault.
11. Returns a SAML response, which contains the user’s
network ID and UDCidentifier, to the SSO Manager. A
sample response is shown on page 32.
SSO Manager 12.Forwards the ticket to the Oracle Forms application

(ssoclient.jar).
ssoclient.jar 13.Uses the INB ticket to retrieve user credentials from the
Credential web service, which is exposed by the SSO
Manager.
Note: The SSO Manager can be configured to automatically
generate a password if the Credential web service does not
know the user credentials.
14.Logs the user into Oracle Forms and starts the user session.
The INB ticket is never reused. The ticket that the SSO Manager forwards to
ssoclient.jar is destroyed as soon as ssoclient.jar uses it to request
credentials from the Credential web service.
Configuration steps
Use the following steps to configure INB for SSO:
• Step 1 - Configure the SSO client (optional)

• Step 2 - Configure the Oracle Forms server for INB SSO
• Step 3 - Configure the SSO Manager for INB
• Step 4 - Configure a CAS service for the SSO Manager
Step 1 - Configure the SSO client (optional)
Note: The SSO client is configured when the SSO Manager is installed.
Use the following steps only if you want to reconfigure the SSO client after
installation.

The ssoclient.jar file contains the Java components that communicate with the
Credential web service to obtain the user credentials needed to access INB. The
ssoclient.jar file uses Oracle Forms Java integration to allow Java classes to
execute from the Oracle Forms server.
The ssoclient.properties file supports the configuration of the SSO client. This
file is configured when the SSO Manager is installed.
The SSO Manager is packaged as SSOManager_8.2.zip. This zip file contains an

automated installer that configures ssoclient.jar. Use the following steps to launch
the automated installer and configure ssoclient.jar.
Note: The automated installer must be run on the Oracle WebLogic

server where the application resides.
1. Download and extract BEIS_8.2.zip from the Ellucian Download Center. The file
is located in the Banner General product folder.
2. Extract SSOManager_8.2.zip. The extract directory is referred to as
<ZIP_HOME>.
3. Open a command prompt and navigate to <ZIP_HOME>/ant-installer.
4. Execute the following command:
java -jar sso-manager-weblogic-installer.jar
The automated installer is launched. The user interface depends on whether you are
running in a windowing (GUI) or in a non-windowing (command-line) environment.
The remaining instructions are based on using the GUI for configuration.
Configuration options are identical for a command-line interface.
Note: In command-line mode, each configuration option is displayed with

the default value in brackets. To accept the default value, press Enter on
your keyboard. To enter a different value, enter the correct value and
press Enter on your keyboard. Valid values for the installation options are
true and false. All values must be entered without leading and trailing
spaces.

5. Click Next.
6. Select Configure and Save SSO Client.
7. Click Next.

8. Enter the following SSO Manager information:
SSOManager Server Protocol used by the SSO Manager (http or https)

Protocol
SSOManager Host SSO Manager host name
SSOManager Port Managed server port number where the SSO Manager is
running
9. Click Next.
10. Enter the SSO Manager user configuration:
Username User name for the SSO Manager web application
Password Password for the SSO Manager web application

11. Click Next.
12. Click Select Folder and browse to the location where you want to save
ssoclient.jar.
13. Click Next.

14. Click Show Details.
15. Click Install.

Installation details are displayed as the installation progresses.
The message Install Finished is displayed when the installation is complete. The
ssoclient.jar file is saved in the selected folder.
Step 2 - Configure the Oracle Forms server for INB SSO

The Oracle Forms server must be configured to support SSO for INB. You can modify
settings directly in the configuration files, or you can use the Oracle Enterprise Manager
console. The following sections give instructions for both methods.
Option 1 - Modify settings directly in configuration files

Use the following steps if you want to modify settings directly in the configuration files. The
Oracle WebLogic server home location is referred to as <WebLogic Home>.
1. Place ssoclient.jar on your Oracle Forms server in a directory where you have
read and execute permissions. This location is referred to as <Banner SSO
client directory>.
Note: Do not place ssoclient.jar in the <WebLogic Home>/

forms/java directory. Doing so creates a security risk.
2. Locate and open the Forms environment file (.env extension). This file is used to set
variables (such as ORACLE_HOME, FORMS_PATH, and CLASSPATH) in the
Oracle Forms runtime environment.
Example:
/u01/app/oracle/middleware/user_projects/domains/
ClassicDomain/config/fmwconfig/servers/WLS_FORMS/
applications/formsapp_11.1.1/config/SMPL.env

3. Modify the CLASSPATH variable in the Forms environment file to include a reference
to ssoclient.jar immediately after the reference to frmsrv.jar as follows:
CLASSPATH=/u01/app/oracle/middleware/as_1/forms/j2ee/
frmsrv.jar:/<Banner SSO client directory>/ssoclient.jar:/
u01/app/oracle/middleware/as_1/jlib/ldapjclnt11.jar:/u01/
app/oracle/middleware/as_1/jlib/debugger.jar:/u01/app/
oracle/middleware/as_1/jlib/ewt3.jar:/u01/app/oracle/
middleware/as_1/jlib/share.jar:/u01/app/oracle/
middleware/as_1/jlib/utj.jar:/u01/app/oracle/middleware/
as_1/jlib/zrclient.jar:/u01/app/oracle/middleware/as_1/
reports/jlib/rwrun.jar:/u01/app/oracle/middleware/as_1/
forms/java/frmwebutil.jar:/u01/app/oracle/middleware/
as_1/jlib/start_dejvm.jar:/u01/app/oracle/4middleware/
as_1/opmn/lib/optic.jar:/u01/app/oracle/middleware/as_1/
forms/java/frmall.jar::/u01/app/oracle/middleware/as_1/
forms/java/auainit-8.5.1.jar
Note: The order in this variable is important.
Note: In a windowing environment, the syntax uses backward slashes (\)

instead of forward slashes (/).
Note: Any reference to baniam.jar must be removed.
4. Locate and open the Forms Web configuration file.

Example:
applications/formsapp_11.1.1/config/formsweb.cfg
5. Add a new parameter to formsweb.cfg for passing the ticket to the Welcome to
Banner (GUAINIT) form.
Example:
# Other Forms runtime arguments: grouped together as one
# parameter.
# These settings support running and debugging a form from
# the Builder:
otherparams=buffer_records=%buffer%debug_messages=%debug_
messages% array=%array% obr=%obr%query_only=%query_only%
quiet=%quiet% render=%render%record=%record%
tracegroup=%tracegroup% log=%log%
term=%term%iamticket=%iamticket%

Option 2 - Modify settings using the console
Use the following steps if you want to use the Oracle Enterprise Manager console to
modify the configuration settings. The Oracle WebLogic server home location is referred
to as <WebLogic Home>.
1. Place ssoclient.jar on your Oracle Forms server in a directory where you have
read and execute permissions. This location is referred to as <Banner SSO
client directory>.
Note: Do not place ssoclient.jar in the <Oracle WebLogic>/

forms/java directory. Doing so creates a security risk.
2. Access the Oracle Enterprise Manager:

http://<host>:<port>/em
3. In the navigation pane, expand and click Forms > forms.
4. Click Environment Configuration.
5. Select the default or environment-specific file name from the Show drop-down list.

6. Modify the CLASSPATH variable to include a reference to ssoclient.jar
immediately after the reference to frmsrv.jar as follows:
/u01/app/oracle/middleware/as_1/forms/j2ee/frmsrv.jar:/
<Banner SSO client directory>/ssoclient.jar:/<WebLogic
Home>/middleware/as_1/jlib/ldapjclnt11.jar:/<WebLogic
Home>/middleware/as_1/jlib/debugger.jar:/<WebLogic Home>/
middleware/as_1/jlib/ewt3.jar:/<WebLogic Home>/
middleware/as_1/jlib/share.jar:/<WebLogic Home>/
middleware/as_1/jlib/utj.jar:/<WebLogic Home>/middleware/
as_1/jlib/zrclient.jar:/<WebLogic Home>/middleware/as_1/
reports/jlib/rwrun.jar:/<WebLogic Home>/middleware/as_1/
forms/java/frmwebutil.jar:/<WebLogic Home>/middleware/
as_1/jlib/start_dejvm.jar:/<WebLogic Home>/middleware/
as_1/opmn/lib/optic.jar
7. Click Apply.
8. In the navigation pane, expand and click Forms > forms.
9. Click Web Configuration.

10. Select the section name of the database where Oracle Forms is deployed.
11. Select advanced from the Show drop-down list.
12. For the otherparams variable, add iamticket=%iamticket% at the end of

the string as follows:
obr=%obr% record=%record% tracegroup=%tracegroup%
log=%log% term=%term% ssoProxyConnect=%ssoProxyConnect%
iamticket=%iamticket%
13. Click Apply.
Step 3 - Configure the SSO Manager for INB

Use the following steps to configure the SSO Manager for INB.

3. Select SAML Validate.
4. Click Save.
5. Select the INB Configuration tab.
6. Enter the following INB configuration information:
INB URL Default URL where users are redirected when they request
the protected INB URL. This is normally the INB server:
http(s)://<host>:<port>/forms/frmservlet
When a valid SSO request is received, the SSO Manager
redirects the user request to this location with the
appropriate parameters. This value is referred to as the INB
URL.
Forms Environment Oracle Forms environment to which the SSO Manager is

linked. This parameter is appended to the INB URL.
Example: http(s)://<host>:<port>/forms/
frmservlet?config=<forms environment
value>
The configuration of this environment is normally specified
through an Oracle Forms environment file with a similar
name (for example, smpl and smpl.env).
Mode Type of central access manager that authenticates users for

SSO. Select CAS.

UDC ID Indicator Not used for CAS.
UDC ID Key Not used for CAS.
Ticket Parameter Name of the HTTP request parameter that the SSO
Name Manager creates to pass an INB ticket to the Oracle Forms
server to perform SSO. This name must match the value
configured in the Oracle Forms server (see “Step 2 -
Configure the Oracle Forms server for INB SSO” on
page 49). The default name is iamticket.
SSO with INB involves the exchange of an INB ticket

between the SSO Manager and the Oracle Forms server.
The ID of the INB ticket is passed via a parameter that is
appended to the INB URL in an HTTP request. INB (the
Oracle Forms server and ssoclient.jar) is configured
to look for this request parameter. The ssoclient.jar
component extracts the ID of the INB ticket from the
parameter and uses it to request the user’s INB user name
and password from the Credential web service to complete
sign on by Oracle Forms.
The following INB URL shows the default ticket parameter

name and associated value appended:
http://<host>:<port>/forms/frmservlet?
iamticket=<ticket parameter value>
Password Policy Method used to create a password if the Credential web
service does not know a user’s password:
Prompt Prompt user to enter a password. (The

entered password must match the
user’s INB password.)
Auto Generate Automatically generate a password.

Valid Characters Valid characters for generated passwords:
Alphanumeric Alphabetic and numeric characters
Alphabetic Alphabetic characters only
Minimum Length Minimum length of generated passwords. Must be numeric.
Maximum Length Maximum length of generated passwords. Must be numeric.
Store Password Check box that determines whether INB user passwords are
stored for future use.
selected Store passwords for future SSO

requests.
cleared Do not store passwords for future SSO

requests.

7. Click Save.
Note: A server restart is not required for these entries to take effect.
Step 4 - Configure a CAS service for the SSO Manager
Note: Skip this step if a CAS service was previously configured for the
SSO Manager.
The CAS server needs to know that the SSO Manager URL is protected for SSO. This is
accomplished by configuring a CAS service for the SSO Manager. Both INB and SSB
need this CAS service. Use the following steps to configure the CAS service that protects
the SSO Manager.
administrator).

Name sso manager cas client

Service URL http(s)://<SSO Manager server>:<SSO
Manager port>/ssomanager/**
Description Protect sso manager client
5. Click Save Changes. The CAS server is now protecting the SSO Manager URL.

Use the following steps to verify that SSO to INB is configured properly.

3. In the Verification Links section, click CAS.
4. Verify that the CAS server is accessed correctly.

5. Log in to CAS using valid credentials for the environment.
6. Clear the cookies and close the browser.
7. Access the SSO Manager administrative interface again:

8. In the Gated Applications section, click Internet Native Banner.
9. Log in to CAS with valid credentials for a known INB user.

10. Ensure that the INB main menu is displayed.
Deep-linking to INB forms

Deep-linking is the ability to bypass a menu page and hyperlink directly to a specific INB
form. The SSO Manager supports deep-linking through the protected URLs that it exposes
for accessing INB. Requests to deep-link into INB must supply a parameter that specifies
the desired form.
The SSO Manager expects deep-link requests to INB to use the following syntax:
<SSO Manager INB URL>?otherParams=launch_form=<target
form>
Oracle Forms does not require any configuration changes to accept this parameter.
Example:
http://beisserver.institution.edu:7777/ssomanager/c/
INB?otherParams=launch_form=AFACAMP&BAN_ARGS=CAMPAIGN::XC
ELL
If the requested form is not found, the Banner menu page is displayed.

JVM pooling
Each time an INB session is started, a frmweb process is created with a private Java
virtual machine (JVM). The JVM is used to render the INB forms applet and execute any
additional calls to Java.
The INB ssoclient.jar file places an additional load on the in-process, private JVM.
Over time, as the number of INB sessions increases, swap space utilization also
increases.
Oracle Forms services offer JVM pooling to help manage swap space utilization. JVM
pooling allows multiple frmweb processes to share a pool of JVM resources. This reduces
the need for each process to continue growing its private JVM heap allocation.
Use the following steps to configure JVM pooling for INB single sign on:
• Step 1 - Configure the SSO client (optional)

• Step 2 - Modify the CLASSPATH variable
• Step 3 - Create the JVM Controller
• Step 4 - Edit the Forms Web configuration
• Step 5 - Edit basejpi.htm
• Step 6 - Shut down the WLS_FORMS server
• Step 7 - Start the WLS_FORMS server
• Step 8 - Start the JVM Controller
• Step 9 - Test the JVM Controller
Step 1 - Configure the SSO client (optional)
Note: The SSO client is configured when the SSO Manager is installed.
Use the following steps only if you want to reconfigure the SSO client after
installation.
The ssoclient.jar file contains the Java components that communicate with the
Credential web service to obtain the user credentials needed to access INB. The
ssoclient.jar file uses Oracle Forms Java integration to allow Java classes to
execute from the Oracle Forms server.
The ssoclient.properties file supports the configuration of the SSO client. This
file is configured when the SSO Manager is installed.
The SSO Manager is packaged as SSOManager_8.2.zip. This zip file contains an

automated installer that configures ssoclient.jar. Use the following steps to launch
the automated installer and configure ssoclient.jar.

Note: The automated installer must be run on the Oracle WebLogic
server where the application resides.
1. Download and extract BEIS_8.2.zip from the Ellucian Download Center. The file
is located in the Banner General product folder.
2. Extract SSOManager_8.2.zip. The extract directory is referred to as
<ZIP_HOME>.
3. Open a command prompt and navigate to <ZIP_HOME>/ant-installer.
4. Execute the following command:
java -jar sso-manager-weblogic-installer.jar
The automated installer is launched. The user interface depends on whether you are
running in a windowing (GUI) or non-windowing (command-line) environment. The
remaining instructions are based on using the GUI for configuration. Configuration
options are identical for a command-line interface.
Note: In command-line mode, each configuration option is displayed with

the default value in brackets. To accept the default value, press Enter on
your keyboard. To enter a different value, enter the correct value and
press Enter on your keyboard. Valid values for the configuration options
are true and false. All values must be entered without leading and
trailing spaces.
5. Click Next.

6. Select Configure and Save SSO Client.
7. Click Next.
8. Enter the following SSO Manager information:
SSOManager Server Protocol used by the SSO Manager (http or https)

Protocol
SSOManager Host SSO Manager host name
SSOManager Port Managed server port number where the SSO Manager is
running
9. Click Next.

10. Enter the SSO Manager user configuration:
Username User name for the SSO Manager web application
Password Password for the SSO Manager web application
11. Click Next.

12. Click Select Folder and browse to the location where you want to save
ssoclient.jar.
13. Click Next.

14. Click Show Details.

15. Click Install.
Installation details are displayed as the installation progresses.
The message Install Finished is displayed when the installation is complete. The
ssoclient.jar file is saved in the selected folder.

Step 2 - Modify the CLASSPATH variable
Use the following steps to modify the CLASSPATH variable in the Forms environment file.
1. Locate and open the Forms environment file (.env extension). This file is used to set
variables (such as ORACLE_HOME, FORMS_PATH, and CLASSPATH) in the
Oracle Forms runtime environment.
Example:
applications/formsapp_11.1.1/config/SMPL.env
2. Modify the CLASSPATH variable in the Forms environment file to include a reference
to ssoclient.jar immediately after the reference to frmsrv.jar as follows:
CLASSPATH=/u01/app/oracle/middleware/as_1/forms/j2ee/
frmsrv.jar:<Banner SSO client directory>/ssoclient.jar:/
u01/app/oracle/middleware/as_1/jlib/ldapjclnt11.jar:/u01/
app/oracle/middleware/as_1/jlib/debugger.jar:/u01/app/
oracle/middleware/as_1/jlib/ewt3.jar:/u01/app/oracle/
middleware/as_1/jlib/share.jar:/u01/app/oracle/
middleware/as_1/jlib/utj.jar:/u01/app/oracle/middleware/
as_1/jlib/zrclient.jar:/u01/app/oracle/middleware/as_1/
reports/jlib/rwrun.jar:/u01/app/oracle/middleware/as_1/
forms/java/frmwebutil.jar:/u01/app/oracle/middleware/
as_1/jlib/start_dejvm.jar:/u01/app/oracle/middleware/
as_1/opmn/lib/optic.jar:/u01/app/oracle/middleware/as_1/
forms/java/frmall.jar:/u01/app/oracle/middleware/as_1/
forms/java/auainit-8.5.1.jar
Note: The order in this variable is important.
Note: In a windowing environment, the syntax uses backward slashes (\)

instead of forward slashes (/).
Note: Any reference to baniam.jar must be removed.
Step 3 - Create the JVM Controller

Use the following steps to create the JVM Controller.

2. In the navigation pane, navigate to Forms > forms.
3. Navigate to Forms > JVM Configuration.
4. Click Create.

5. Enter the following information:
Section Name INBSSOController

Comments ssoclient JVM Controller
6. Click Create.
7. Click Apply.

8. Select INBSSOController.
9. Click Add.

Name classpath
Value Full path to ssoclient.jar
Example: /home/oracle/ssoclient/
ssoclient.jar
Comments Full path to ssoclient.jar
11. Click Create.

12. Click Add.
Name maxsessions
Value 50 (number of concurrent Forms sessions that can
connect to the JVM Controller before a new JVM process is
spawned)
14. Click Create.

15. (Optional) If you want to add the jvmoptions setting:
15.1. Click Add.
15.2. Enter the following information:
Name jvmoptions
Value -Xms512m -Xmx1024m
These are examples. Tune the values based on your
environmental requirements.
15.3. Click Create.

16. Click Apply.

Step 4 - Edit the Forms Web configuration
Use the following steps to edit formsweb.cfg.
1. Navigate to Forms > Web Configuration.
2. Select the appropriate section name (for example, SMPL).

3. Click Add.
Name jvmcontroller
Value INBSSOController
Comments Jvmcontroller for named section of
formsweb.cfg
Note: If the jvmcontroller parameter already exists, set the value to

INBSSOController.
5. Click Create.
6. Click Add.
Name allowJVMControllerAutoStart
Value true

8. Click Create.
9. Click Apply.
Step 5 - Edit basejpi.htm

Use the following steps to edit basejpi.htm.
1. Navigate to $ORACLE_HOME/../asinst_1/config/FormsComponent/
forms/server/basejpi.htm.
2. Add JVM Controller references to the following two sections:
• <PARAM NAME="serverArgs" VALUE="%escapeParams%
module=%form% userid=%userid% debug=%debug% host=%host%
port=%port% %otherParams% jvmcontroller=%jvmcontroller%
%wfargs%">
• serverArgs="%escapeParams% module=%form% userid=%userid%
debug=%debug% host=%host% port=%port% %otherparams%
jvmcontroller=%jvmcontroller% %wfargs%"

Step 6 - Shut down the WLS_FORMS server
Use the following steps to shut down the WLS_FORMS server.
1. Navigate to WebLogic Domain > ClassicDomain > cluster forms > WLS_FORMS.
2. Right-click WLS_FORMS and select Control > Shut Down.
3. Click Shutdown.

4. When the shutdown operation completes, click Close.
Step 7 - Start the WLS_FORMS server

Use the following steps to start the WLS_FORMS server.
1. Right-click WLS_FORMS and select Control > Start Up.
2. When the start operation completes, click Close.

Step 8 - Start the JVM Controller
Use the following steps to start the JVM Controller.
2. Navigate to Forms > JVM Controllers.
3. Select INBSSOController.

4. Click Start.
Step 9 - Test the JVM Controller

Use the following steps to verify that the JVM Controller is managing INB sessions.
1. Log in to INB using the SSO Manager:
http(s)://<host>:<port>/ssomanager/c/INB
4. Navigate to Forms > User Sessions.

5. Verify that the number of user login sessions is greater than or equal to 1.
6. Navigate to Forms > JVM Controllers.
7. Verify that the number of current sessions is greater than or equal to 1.

Banner 9.x configuration for CAS
Banner 9.x applications natively support SSO. A central access manager, such as CAS,
implements this native SSO support as follows:
• Enables Banner 9.x applications for SSO

• Protects Banner 9.x access URLs
• Implements authentication against a central identity vault
The following sections provide details on configuring a Banner 9.x application to support
SSO using CAS authentication.
The following components support SSO for Banner 9.x applications:
Banner 9.x Banner 9.x applications (for example, Student Course Catalog)
applications include a common authentication provider that supports CAS
authentication.
Processing flow
The following processing occurs when a Banner 9.x application is the first application
accessed in an SSO session:

User 1. Opens a web browser and requests access to a Banner 9.x

application through a protected URL:
http://<Banner 9.x host>:<port>/<Banner
9.x application name>/
banner.zul?page=<main_page>
Example: http://myBanner9xServer.edu:8080/
StudentRegistration/
banner.zul?page=mainPage
2. Is redirected to the CAS login page.
3. Logs in to CAS.

5. Issues a ticket to the user.
User 6. Uses the ticket to invoke the Banner 9.x application.
Banner 9.x 7. Calls the CAS /samlValidate service.

application

9. Retrieves the UDCIdentifier from the central identity vault.
10.Returns the ticket to the Banner 9.x application.
Banner 9.x 11. Makes sure the UDCIdentifier matches a person in Banner.
application 12.Grants access to the Banner 9.x application.
The following processing occurs when a Banner 9.x application is accessed in a session
where SSO was previously established:

User 1. Requests access to a Banner 9.x application through a

protected URL:
http://<Banner 9.x host>:<port>/<Banner
9.x application name>/
banner.zul?page=<main_page>
Banner 9.x 2. Calls the CAS /samlValidate service.
application

5. Returns the ticket to the Banner 9.x application.
Banner 9.x 6. Makes sure the UDCIdentifier matches a person in Banner.

application 7. Grants access to the Banner 9.x application.
Configuration steps
Use the following steps to configure a Banner 9.x application for CAS:
• Step 1 - Configure the authentication provider

• Step 2 - Configure the CAS client URLs
• Step 3 - Create a .war file
• Step 4 - Externalize the SSO configuration (optional)
• Step 5 - Deploy the Banner 9.x application
• Step 6 - Configure a CAS service for each Banner 9.x application
Step 1 - Configure the authentication provider

Use the following steps to configure the authentication provider in the groovy configuration
file.
1. Connect to the Oracle WebLogic server that hosts the Banner 9.x application, using a
shell command prompt.
2. Locate the Banner 9.x application groovy configuration file.
Example:
ban_apps_home/StudentCourseCatalog/current/instance/
config/StudentCourseCatalog_configuration.groovy

3. Locate the CAS CONFIGURATION section in the groovy configuration file.
4. Make the following change:
Before: banner {
sso {
authenticationProvider = 'default' // Valid
values are: 'default', 'cas'
After: banner {
sso {
authenticationProvider = 'cas' // Valid
values are: 'default', 'cas'
authenticationAssertionAttribute =
'UDC_IDENTIFIER'
5. Save the changes.
Step 2 - Configure the CAS client URLs

Use the following steps to configure the CAS client URLs in the groovy configuration file.
1. Locate the CAS grails springsecurity plugin in the groovy configuration file.
Example:
grails {
plugins {
springsecurity {
cas {
2. Edit the following parameters:
serverUrlPrefix CAS server context path
serviceUrl Banner 9.x application URL. Each Banner 9.x application has
its own URL.
serverName CAS server host and port
proxyCallbackUrl Proxy callback URL
loginUri CAS server login URI, relative to the CAS serverUrlPrefix

sendRenew Setting that controls the re-entry of user names and

passwords:
true User must re-enter a user name and password to

gain access to the service.
false User does not need to re-enter a user name and

password to gain access to the service (default).
proxyReceptorUrl Proxy Receptor Service URL
useSingleSignout Setting that enables signout for all CAS-managed

applications with one logout:
true Enforces the logout process that is defined in the

logout section of the springsecurity grails plugin
(default).
false Does not enforce the logout process that is defined

in the logout section of the springsescurity grails
plugin.
key Key that the authentication provider uses to identify tickets it

previously authenticated
artifactParameter Ticket login URL parameter (for example, ticket)
serviceParameter Service login URL parameter (for example, service).
filterProcessesUrl URL that the filter intercepts for login (for example,
/j_spring_cas_security_check)
afterLogoutUrl CAS logout and redirection URLs, respectively. This
parameter is enforced if useSingleSignout is true.
Example:
grails {
plugins {
springsecurity {
cas {
serverUrlPrefix = 'https://mycas.school.edu:8443/cas'
serviceUrl = 'http://myXE.school.edu:8081/
StudentCourseCatalog/j_spring_cas_security_check'
serverName = 'http://myXE.school.edu:8081'
proxyCallbackUrl = ' http://myXE.school.edu:8081/
StudentCourseCatalog/secure/receptor'
loginUri = '/login'
sendRenew = false
proxyReceptorUrl = '/secure/receptor'
useSingleSignout = true
key = 'grails-spring-security-cas'
artifactParameter = 'ticket'

serviceParameter = 'service'
filterProcessesUrl = '/j_spring_cas_security_check'
}
logout {
afterLogoutUrl = 'https://mycas.school.edu:8443/cas/
logout?url=http://myXE.school.edu:9010/reg_systest/index.html
3. Save the changes and close the file.
Step 3 - Create a .war file

Use the following steps to create a .war file. The .war file includes the configuration file,
making the .war file self-sufficient.
Note: You can optionally locate the configuration file on an external file
system. Refer to “Step 4 - Externalize the SSO configuration (optional)”
on page 83 for details. An external file system can be used for test and
development environments, but should not be used for a production
environment.
1. Change your working directory to the product home directory:

<product home>/current/installer
Example: /u02/ban_apps_home/StudentRegistrationSsb/current/
installer
2. Execute the following ant command to build the systool module:
$ cd <product home>/current/installer
installer $ ant
Note: For Unix, make sure the ant file is executable (chmod +x ant).
3. Make sure you are in the <product home>/current/installer directory.

4. Use the systool module to create the .war file:
Unix: $ bin/systool war

Windows: > bin\systool war
Step 4 - Externalize the SSO configuration (optional)

For test and development environments, the SSO configuration file can optionally be
located on an external file system. In this scenario, rebuilding and redeploying the .war file
in not required, making it easier to switch between authentication modes.
Warning! Using an external file system is not recommended for a

production environment. Unexpected changes to the file system or the

Java system parameters that link the configuration to the file system can
render the application inoperable and create unintended down time.
If the SSO configuration file is located on an external file system, you must use the
following instructions to override the configuration in the .war file. Instructions are provided
for Tomcat and Oracle WebLogic.
Tomcat
Use the following steps to override the configuration in the ,war file.
1. Set system properties to point to the external configuration file.
Example:
To point to a configuration file residing in the PRODUCT_HOME directory:
export JAVA_OPTS="- DBANNER_APP_CONFIG=/PRODUCT_HOME/
shared_configuration/banner_configuration.groovy -
DSTUDENT_COURSE_CATALOG_CONFIG=/PRODUCT_HOME/
catalog_home/current/instance/config/
StudentCourseCatalog_configuration.groovy".
2. Restart Tomcat.
Oracle WebLogic
Use the following steps to override the configuration in the ,war file.
1. Connect to the Oracle WebLogic server administration console:
http://<host>:<port>/console
2. In the Change Center pane, click Lock & Edit.
3. In the Domain Configuration section, click Servers.
4. On the Summary of Servers page, click the name of the managed server where the
Banner 9.x application is deployed.
5. On the Settings page, select the Server Start tab.
6. In the Arguments field, enter the following:
–D<Banner 9.x application name>_CONFIG=<full file path to
Banner 9.x application name>_configuration.groovy
Example:
-DSTUDENT_CLASS_SCHEDULE_CONFIG=<full file path to
StudentCourseCatalog>_configuration.groovy
7. Click Save.
8. In the Change Center pane, click Activate Changes.
9. Restart the Banner 9.x manged server.

Step 5 - Deploy the Banner 9.x application
You can deploy the Banner 9.x application to a Tomcat server or to an Oracle WebLogic
server.
Note: Environments vary significantly regarding user privileges, clustering

approach, web container version, and operating system. The Tomcat
server might not be suitable for your use.
Note: If you are redeploying a Banner 9.x application, you must undeploy
the original version before you deploy the new version.
Tomcat
The systool module (built in Step 3 - Create a .war file) can be used to deploy the Banner
9.x application .war file to a Tomcat server. This target supports the deployment of the
dist/ .war file using the Tomcat Manager.
Alternatively, the .war file can be deployed to the Tomcat server by copying the .war file to
the Tomcat webapps directory. Hence, use of this target is not critical.
Use the following steps to deploy the Banner 9.x application to a Tomcat server.
1. Navigate to the <product home>\current\installer directory.
Examples:
Unix $ bin/systool deploy-tomcat
Windows > bin\systool deploy-tomcat
2. When prompted, enter the URL of the Tomcat Manager.
Example: http://localhost:8080/manager
3. When prompted, enter a valid Tomcat user name and password.
This user must have the manager-gui role that is used to deploy applications to the
Tomcat server. The password is not persisted.
For Tomcat 6.x, you must configure at least one user name/password combination in
your Tomcat user database <TOMCAT_HOME>\conf\tomcat-users.xml with
the manager role.
Example: <user username="tomcat" password="tomcat"
roles="manager-gui, manager"/>
Note: Roles in the Tomcat server changed between Tomcat 6.x interim
releases. Refer to Tomcat documentation for your specific release for
information on enabling the appropriate role that allows a user account to
deploy an application.
4. Access the Banner 9.x application:

http://<Banner 9.x host>:<port>/<Banner 9.x application
name>/banner.zul?page=<main_page>
Oracle WebLogic
Use the following steps to deploy the Banner 9.x application to an Oracle WebLogic
server.
1. Connect to the Oracle WebLogic Server administration console:
http://<host>:<port>/console
2. In the Change Center pane, click Lock & Edit.
3. In the Domain Structure pane, click Deployments.
4. On the Summary of Deployments page, click Install.
5. On the Install Application Assistant page, click upload your file(s).
6. Select the file to be uploaded as follows:
6.1. In the Deployment Archive field, click Browse.
6.2. Navigate to the .war file for the application.
6.3. Select the file and click Open.
7. Click Next.
8. Select the application .war file from the list at the bottom of the page.
9. Click Next.
10. Select Install this deployment as an application.
11. Click Next.
12. Select the server where the application should be deployed.
13. Click Next.
14. Click Finish to start the deployment. When deployment is completed, the Summary of
Deployments page is redisplayed with the newly deployed application.
15. In the Change Center pane, click Activate Changes.
16. On the Summary of Deployments page, start the newly deployed application as
follows:
16.1. Select the newly deployed application.
16.2. Click Start > Servicing all requests.
16.3. Click Yes to start the application.
17. Access the Banner 9.x application:
http://<Banner 9.x host>:<port>/<Banner 9.x application
name>/banner.zul?page=<main_page>

Step 6 - Configure a CAS service for each Banner 9.x application
The CAS server needs to know that the URL of each Banner 9.x application protected for
SSO. This is accomplished by configuring a CAS service for each Banner 9.x application.
Use the following steps to configure the CAS service that protects a Banner 9.x
application.
administrator).
Name Name of the Banner 9.x application
Service URL http(s)://<host>:<port>/<Banner 9.x

application URI>/**
Description Description of the Banner 9.x application
5. Click Save Changes. The CAS server is now protecting the URL of the Banner 9.x
application.

Use the following steps to verify that SSO to the Banner 9.x application is configured
properly.
1. Access the Banner 9.x application.
Example:
http://<Banner 9.x host>:<port>/StudentCourseCatalog
2. Log in to CAS with valid credentials for a known Banner 9.x application user.
3. Verify that the Banner 9.x application is accessed correctly.

Configuring Banner Document
Management for CAS
This chapter describes the configuration of Banner® Document Management (BDM) to

support single sign on (SSO) via Central Authentication Service (CAS). BDM integrates
Banner with EMC ApplicationXtender. In a CAS-based environment, users authenticate to
CAS instead of ApplicationXtender.
SSO via CAS uses the CAS /samlValidate service to retrieve and validate user identities. If
your institution uses the /bannerValidate service instead of the /samlValidate service, refer
to the Banner Document Management 8.4 Installation Guide with ApplicationXtender 6.5
Patch 1 for SSO configuration details.
CAS with ApplicationXtender products

CAS is a web-based protocol. The following considerations apply to the use of CAS with
ApplicationXtender products:
• ApplicationXtender Web Access .NET can use CAS for SSO.

• ApplicationXtender Document Manager is not a web-based product. Therefore,
ApplicationXtender Document Manager cannot use CAS for SSO.
• When SSO via CAS is enabled, password synchronization from Internet-Native Banner
(INB) to ApplicationXtender Web Access .NET is disabled automatically.
• If the user preference setting on the User Preference (EXAUPRF) form enables
ApplicationXtender Document Manager instead of ApplicationXtender Web Access,
.NET, password synchronization still occurs from INB to ApplicationXtender Document
Manager.
Prerequisites
• ApplicationXtender 6.5 SP2 or higher is required.
• BDM 8.0 or higher is required. In addition, one of the following patches is required to
provide support for the CAS /samlValidate service. The required patch depends on your
version of ApplicationXtender:
CAS Single Sign On Handbook | Configuring Banner Document Management for CAS 89
BDM patch ... Is required for ...
pcr-000106299_ext8050002 ApplicationXtender 6.5 SP2
pcr-000109518_ext8050004 ApplicationXtender 7.0
• The UDC_IDENTIFIER attribute must be properly configured on the CAS server.

• The UDC_IDENTIFIER must be published using /samlValidate, a native CAS validation
service.
• BDM is integrated with Internet-Native Banner (INB) and Self-Service Banner (SSB).
SSO with INB and SSB requires the SSO Manager, a component of Banner Enterprise
Identity Services (BEIS). Refer to “SSB configuration for CAS” on page 29 and “INB
configuration for CAS” on page 41 for details on configuring the SSO Manager.
Processing flow
The following processing occurs when ApplicationXtender Web Access .NET is accessed
in an SSO session:
User 1. Opens a web browser and requests access to

ApplicationXtender Web Access .NET through a protected
URL:
http://<ApplicationXtender Web Access
server>/AppXtender/Login.aspx?sso=true
ApplicationXtender 2. Redirects the user to the CAS login page.
Web Access .NET
User 3. Logs in to CAS.

6. Redirects the ticket to ApplicationXtender Web Access .NET,
passing the ticket as a parameter in the URL.
ApplicationXtender 7. Calls the CAS /samlValidate service.

Web Access .NET
ApplicationXtender 9. Retrieves the UDCIdentifier from the central identity vault.

Web Access .NET 10.Auto logs the user into ApplicationXtender Web Access
.NET.
11. Grants access to the user.
Configuration steps
Use the following steps to configure BDM for CAS:
• Step 1 - Install the BDM SSO files

• Step 2 - Modify Login.aspx
• Step 3 - Modify bdms.sso.config
• Step 4 - Configure integration between Banner and ApplicationXtender Web Access
.NET
• Step 5 - Configure a CAS service for ApplicationXtender Web Access .NET

• Step 6 - Map UDCIdentifiers to ApplicationXtender IDs (optional)
Step 1 - Install the BDM SSO files

Use the following steps to install the BDM SSO files on the ApplicationXtender Web
Access .NET server.
1. If ApplicationXtender 6.5 SP2 is installed at your institution, download pcr-
000106299_ext8050002.trz from the Ellucian Download Center.
-or-
If ApplicationXtender 7.0 is installed at your institution, download pcr-
000109518_ext8050004.trz from the Ellucian Download Center.
2. Extract BEIS_AX_<n.n.nnn>_SAML.zip to a temporary directory on the
ApplicationXtender Web Access .NET server.
3. Navigate to the SSO directory.
4. Determine whether ApplicationXtender Web Access .NET is installed in the default
location (c:\Inetpub\wwwroot\AppXtender):
4.1. If it is installed in the default location, go to step 5.
4.2. If it is not installed in the default location, modify install.bat by setting
variable INSTALLFOLDER to point to the ApplicationXtender Web Access .NET
installation folder. Then go to step 5.
5. Right-click install.bat and select Run as administrator.
-or-
Run install.bat from a command prompt, as follows, to ensure that it runs

successfully:
5.1. Right-click the command prompt and select Run as administrator.
5.2. Change directory to the drive:path of the SSO directory of the extracted file.
5.3. Execute the following command:
start install.bat
A message is displayed as each command in the install.bat file is
completed.
Step 2 - Modify Login.aspx

Use the following steps to modify Login.aspx to call BDMS SSO logic.
Note: If you want to uninstall SSO support at a later time, you must
manually remove the code that you add to Login.aspx or restore the
backup version of Login.aspx.
1. Navigate to Login.aspx on the ApplicationXtender Web Access .NET server,

typically C:\Inetpub\wwwroot\AppXtender.
2. Back up Login.aspx.
3. Open Login.aspx using a text editor.
4. Copy and paste the following code at the end of the file, between the </form> tag
and the </body> tag. This code calls BDM SSO logic.
<script runat="server">
protected override void Page_Load(object sender, EventArgs e)
{
new bdms.idm.sso.LoginHelper().PageLoadHelper();
base.Page_Load(sender,e);
}
</script>
Step 3 - Modify bdms.sso.config

Use the following steps to modify bdms.sso.config to identify the CAS login URL.
1. Navigate to bdms.sso.config on the ApplicationXtender Web Access .NET

server, typically C:\Inetpub\wwwroot\AppXtender.
2. Open bdms.sso.config using a text editor.
3. Modify the CASLoginUrl by entering the login URL of the CAS server.
Example
<CASLoginUrl>
https://<host>:<port>/cas/login
</CASLoginUrl>
4. Restart Internet Information Services (IIS).
Step 4 - Configure integration between Banner and ApplicationXtender
Web Access .NET
Use the following steps to set up SSO from Banner to ApplicationXtender Web Access
.NET.
1. Access the BDM System Settings (EXAINST) form in Internet-Native Banner.
2. Change the value of ApplicationXtender WebXtender Root to http://<host>/
appxtender/ISubmitQuery.aspx?sso=true
3. Save the record.
Step 5 - Configure a CAS service for ApplicationXtender Web Access .NET

The CAS server needs to know that the ApplicationXtender Web Access .NET URL is
protected for SSO. This is accomplished by configuring a CAS service for
ApplicationXtender Web Access .NET. Use the following steps to configure the CAS
service that protects ApplicationXtender Web Access .NET.
administrator).
Name BDM ApplicationXtender Web Access

Service URL https://<ApplicationXtender Web Access
server>:<port>/AppXtender/**
Description Protecting BDM ApplicationXtender Web
Access via CAS
Theme Name BDM
5. Click Save Changes. The CAS server is now protecting ApplicationXtender Web
Access .NET.
Once SSO is configured, the following URL can be used to log in to ApplicationXtender
Web Access .NET through SSO:
http://<ApplicationXtender Web Access server>/AppXtender/
Login.aspx?sso=true
Step 6 - Map UDCIdentifiers to ApplicationXtender IDs (optional)
If BEIS account provisioning is deployed, you can skip this step.
If BEIS account provisioning is not deployed, you must use this step to map
UDCIdentifiers to ApplicationXtender user names. This mapping involves the following
Banner tables:
• GOBUMAP. This table stores a person’s GUID in the GOBUMAP_UDC_ID column. This
column is VARCHAR2(225) and is designed to store the UDCIdentifier. Any unique
identifier for a person can be stored in this column.
• GOBTPAC. This table stores a person’s ApplicationXtender user name in the

GOBTPAC_EXTERNAL_USER column. This is the same user name that is stored in the
ApplicationXtender AE_LOGIN table in the USRNAM column.
• EOBUMAP. This table maps the UDCIdentifier (stored in GOBUMAP) to the

ApplicationXtender user name (stored in GOBTPAC). The EOBUMAP_UDC_ID column
contains the UDCIdentifier. The EOBUMAP_USERNAME column contains the
associated ApplicationXtender user name.
Run eieobumap.sql to initialize the EOBUMAP table with seed data from the
GOBUMAP and GOBTPAC tables.
Integration with Banner Workflow

BDM can be integrated with Banner Workflow to streamline document-based processes.
The following features can be combined to build powerful workflows that efficiently route
documents among participants in a workflow:
• Three URL links, contained in BDM, can be used to open a document, search for
documents, or upload a document.
• The Custom Activity Designer, contained in Banner Workflow, can be used to create
custom activities. A custom activity can include simple HTML tags such as <href> for
URL links that use workflow context parameters.
• Business event parameters are delivered as part of the integration between BDM and
Banner Workflow.
The following sections provide details about the BDM integration URLs that can be used in
custom Banner Workflow activities.
CAS authentication for SSO

CAS authentication is used to enable SSO when BDM documents are routed among
participants in a workflow. BDM URLs include a parameter that invokes CAS
authentication.
For SSO to work, a Banner Workflow user must have the proper privileges to access
BDM. Refer to the Banner Document Management Administration Guide for information
on creating user accounts for your Banner Workflow users.
Supported product versions

Integration between BDM and Banner Workflow requires the following minimum product
versions:
• BDM 8.5.0.2, if ApplicationXtender 6.5 SP2 is implemented

• BDM 8.5.0.4, if ApplicationXtender 7.0.260 is implemented
• Banner Workflow 8.1
When possible, you should use the most recent version of BDM and Banner Workflow.
BDM integration URLs

BDM provides integration URLs that can be used to open a document, search for
documents, or upload a document. Parameters in the URLs must be formed in a specific
way.
Note: The functions that are called to open, search for, or upload
documents are provided within ApplicationXtender. ApplicationXtender
Web Access is the preferred product for using the BDM integration with
Banner Workflow.
URL format
The URL must contain parameters in the following format:
http://<server>/AppXtender/<function>.aspx?sso=true
&DataSource=<datasource parameter>
Additional workflow parameters can be added to the end of the URL:

http://<server>/AppXtender/<function>.aspx?sso=true
&DataSource=<datasource parameter>&<parm1>=<parm1_value>
&<parm2>=<parm2value>
Parameters are defined as follows:
<server>/AppXtender Server where ApplicationXtender is installed

and where documents are stored or will be
stored, depending on the function.
The value of this parameter is defined when

ApplicationXtender is installed. Use one of
the following methods to determine this
value:
• Ask the department that maintains
ApplicationXtender at your institution.
• Access the BDM Systems Settings
(EXAINST) form and locate the value of the
ApplicationXtender Web Access Root
field.
<function>.aspx ApplicationXtender function:
IDocument.aspx - Open a document.

ISubmitQuery.aspx - Search for
documents.
IDocImport.aspx - Upload a document.

sso=true Setting that invokes CAS authentication for
SSO.
DataSource=<datasource_ Banner database that contains the Banner

parameter> records that are linked to documents in
ApplicationXtender by means of the
document index.
URL examples
The following examples show URLs that are used to open a document, search for
documents, and upload a document in ApplicationXtender Web Access. Documents are
stored on the INSTSRV1 server. The BXS.B-S-ADMIN.I (insert student admissions)
business event is used in these examples. Parameters for the business event have the
following values:
Parameter Value
BXS.ADMISSIONS_REQUIREMENT CLT1
BXS.APPNAME B-S-ADMN
BXS.DATASOURCE TESTDB01
BXS.DOCID 1302
Parameter Value
BXS.ID AABBCCDD1
BXS.TERM_CODE 201320
BXS.APPLICATION_NUMBER 1
URL that opens a document

The URL that opens a specific document has the following format:
http://<server>/AppXtender/IDocument.aspx?sso=true
&DataSource=<BXS.DATASOURCE>&Docid=<BXS.DOCID>
&appname=<BXS.APPNAME>
The URL contains the following parameters:
<server>/AppXtender Server where documents are stored.
IDocument.aspx ApplicationXtender function that opens a

specific document in ApplicationXtender
Web Access.

SSO.
DataSource=<BXS.DATASOURCE> Banner database that contains the Banner

records that are linked to the document in
document index. This value is provided in
the BXS.DATASOURCE business event
parameter.
Docid=<BXS.DOCID> Internal value assigned by

ApplicationXtender when the document was
indexed. This value is provided in the
BXS.DOCID business event parameter.
appname=<BXS.APPNAME> BDM-assigned application name. This value

is provided in the BXS.APPNAME business
event parameter.
Example
http://INSTSRV1/AppXtender/IDocument.aspx?sso=true
&DataSource=TESTDB01&Docid=1302&appname=B-S-ADMN
URL that searches for documents
When you search for documents in ApplicationXtender Web Access, the number of
parameters in the URL determines the granularity of the query. When multiple documents
meet the query criteria, ApplicationXtender Web Access displays a list of matching
documents.
The URL that searches for documents has the following format:
http://<server>/AppXtender/ISubmitQuery.aspx?sso=true
&DSN=<BXS.DATASOURCE>&appname=<BXS.APPNAME>&ID=<BXS.ID>
ISubmitQuery.aspx ApplicationXtender function that searches for

a single document or a set of documents in
ApplicationXtender Web Access, depending
on the parameters in the URL.

SSO.
DSN=<BXS.DATASOURCE> Banner database that contains the Banner

records that are linked to the document in
document index. This value is provided in the
BXS.DATASOURCE business event
parameter.
DSN is another naming convention for

DATASOURCE, and is used specifically for
the ISubmitQuery.aspx function.
appname=<BXS.APPNAME> BDM-assigned application name. This value

is provided in the BXS.APPNAME business
event parameter.
ID=<BXS.ID> Optional parameter for this function.
Example 1
http://INSTSRV1/AppXtender/ISubmitQuery.aspx?sso=true
&DSN=TESTDB01&appname=B-S-ADMN&ID=AABBCCDD1
The appname and ID parameters are passed. The URL retrieves a single document
or a list of documents, depending on how many documents are indexed in the B-S-
ADMN application for the ID.
Example 2
http://INSTSRV1/AppXtender/ISubmitQuery.aspx?sso=true
&DSN=TESTDB01&appname=B-S-ADMN&ID=AABBCCDD1
&APPLICATION NUMBER=1&TERM CODE=200820
The appname, ID, APPLICATION NUMBER, and TERM CODE parameters are
passed. The URL retrieves a single document or a list of documents for the ID,
depending on how many documents are indexed in the B-S-ADMN application for the
ID, application, and term code.
URL that uploads a document

A user can upload a document from a local machine or from a server to
ApplicationXtender. After the document is uploaded, it will be indexed to a Banner record.
The URL that uploads a document has the following format:

http://<server>/AppXtender/IDocImport.aspx?sso=true
&DataSource=<BXS.DATASOURCE>&appname=<BXS.APPNAME>
&ID=<BXS.ID>&APPLICATION NUMBER=<BXS.APPLICATION_NUMBER>
&TERM CODE=<BXS.TERM_CODE>&ADMISSIONS REQUIREMENT=
<BXS.ADMISSIONS_REQUIREMENT>
IDocImport.aspx ApplicationXtender function that allows a

user to upload one or more documents to
ApplicationXtender Web Access. The
document will be indexed to a Banner
record later.
sso=true Setting that invokes CAS authentication

for SSO.
DataSource=<BXS.DATASOURCE> Banner database that contains the

Banner records that are linked to the
document in ApplicationXtender by
means of the document index. This value
is provided in the BXS.DATASOURCE
business event parameter.
appname=<BXS.APPNAME> BDM-assigned application name. This

value is provided in the BXS.APPNAME
business event parameter.
ID=<BXS.ID> Optional parameter for this function.
APPLICATION NUMBER= Optional parameter for this function.

<BXS.APPLICATION_NUMBER>
TERM CODE=<BXS.TERM_CODE> Optional parameter for this function.
ADMISSIONS REQUIREMENT= Optional parameter for this function.

<BXS.ADMISSIONS_REQUIREMENT>
Example
http://INSTSRV1/AppXtender/IDocImport.aspx?sso=true
&DataSource=TESTDB01&appname=B-S-ADMN&ID=AABBCCDD1
&APPLICATION_NUMBER=1&TERM CODE=200820
&ADMISSIONS_REQUIREMENT=CLT1
Several parameters are passed with the appname parameter. The more parameters
that are passed, less lookup is needed when the document is indexed in BDM.
Using BDM integration URLs in custom activities

The Custom Activity Designer in Banner Workflow can be used to create custom Banner
Workflow activities. A custom activity can include simple HTML tags such as <href> for
URL links that use workflow context parameters. These URL links can be used to open a
document, search for documents, or upload a document.
Refer to the "Banner Workflow Integration" chapter in the Banner Document Management
Administration Guide for details on the following tasks:
• Create workflow context parameters for the BDM event.

• Build a workflow.
• Create a custom activity in the workflow.
• Add BDM integration URLs to the custom activity.
If you are using CAS for SSO authentication, the BDM integration URLs in the Text
attributes must contain the sso parameter as shown in the following examples.
Example 1
<a href="http://INSTSRV1/AppXtender/IDocument.aspx?
sso=true&DataSource=@BXS_DATASOURCE&Docid=@BXS_DOCID
&appname=@BXS_APPNAME" target="new">View the Document</a>
This Text attribute creates the View the Document link in the custom activity. The link
opens a new window with the document that created the initial event.
Example 2
<a href="http://INSTSRV1/AppXtender/ISubmitQuery.aspx?
sso=true&DSN=@BXS_DATASOURCE&appname=@BXS_APPNAME
&ID=@BXS_ID" target="new">Query Documents</a>
This Text attribute creates the Query Documents link in the custom activity. The link
opens a new window with the ID’s documents in the specified application.
Example 3
<a href="http://INSTSRV1/AppXtender/IDocImport.aspx?
sso=true&DataSource=@BXS_DATASOURCE&appname=@BXS_APPNAME
&ID=@BXS_ID" target="new">Upload a Document</a>
This Text attribute creates the Upload a Document link in the custom activity. The link
opens a new window with the BDM page that is used to upload a document. The
person’s ID is displayed. You can optionally include the APPLICATION NUMBER,
TERM CODE, and ADMISSIONS REQUIREMENT parameters.
Advanced options
If you want to use advanced integration options, such as including direct links to BDM
documents from workflow notifications, contact your account manager or Banner
Workflow Professional Services consultant.
Configuring Banner Effort Reporting
and Labor Redistribution for CAS
Single sign on (SSO) via Central Authentication Service (CAS) for Banner® Effort
Reporting and Labor Redistribution is implemented by configuring Banner Employee Self-
Service for SSO. The Effort Reporting and Labor Redistribution links within Banner
Employee Self-Service launch the Effort Reporting and Labor Redistribution applications
without prompting for user credentials.
Effort Reporting and Labor Redistribution as standalone applications do not support CAS-
based single sign on.
CAS Single Sign On Handbook | Configuring Banner Effort Reporting and Labor Redistribution for CAS 102
Configuring Banner Flexible
Registration for CAS
This chapter describes the configuration of Banner® Flexible Registration to support

single sign on (SSO) via Central Authentication Service (CAS). In a CAS-based
environment, users authenticate to CAS instead of Banner Flexible Registration.
Supported versions of CAS

CAS support in Banner Flexible Registration was tested with the following CAS servers:
• CAS 3.4.12 server that is delivered with Luminis® Platform 5

• Independent CAS 3.5.0 server
Other configurations possibly work, but might require additional configuration.
Prerequisites
service.
• SSL must be enabled on the CAS server.

• SSL must be enabled on the Banner Flexible Registration server.
Processing flow
When a user accesses Banner Flexible Registration as the first application in an SSO
session, the Banner Flexible Registration home page provides instructions and a URL link
for signing in. The user clicks the URL link, is redirected to the CAS login page, and logs in
to CAS. CAS authenticates the user. The user is then redirected to the Banner Flexible
Registration application.
When a user navigates from another CAS-enabled application to Banner Flexible

Registration, the user is directed to a secure URL. Banner Flexible Registration works with
CAS Single Sign On Handbook | Configuring Banner Flexible Registration for CAS 103
CAS to determine if the user is already logged in to CAS. CAS handles authentication into
Banner Flexible Registration.
When a user signs out of Banner Flexible Registration, the user can choose to log out of
CAS as well.
Configuration steps
Use the following steps to configure Banner Flexible Registration for CAS:
• Step 1 - Define the server URLs

• Step 2 - Define the CAS logout redirect URL (optional)
• Step 3 - Disable the ability to change passwords
• Step 4 - Configure forced CAS logouts (optional)
• Step 5 - Configure a CAS service for Banner Flexible Registration
Step 1 - Define the server URLs

Use the following steps to define the server URLs for Banner Flexible Registration and
CAS.
1. Access the Flexible Registration Configuration Rules (SFRACNFG) form.
2. Enter the following URLs:
Flexible Full URL where Banner Flexible Registration is installed.

Registration Include the protocol (https), machine name, port number,
deployment URL and application root. Do not include index.jsp, because
this URL does not represent a landing page.
Example:
https://ellucianuniversity.com:443/
flexibleregistration
SSL must be enabled on the Banner Flexible Registration
server.
If you are using a load-balanced environment, use the main

published URL, not an individual machine URL.
CAS server URL Full URL to the CAS server. Include the protocol (https),
machine name, port number, and CAS application root.
Example:
https://ellucianuniversity.com:443/cas
SSL must be enabled on the CAS server.
3. Save the changes.
Step 2 - Define the CAS logout redirect URL (optional)

Banner Flexible Registration supports the single sign out capability of CAS by presenting
the user a link to the log out of the CAS server. CAS optionally supports a redirect URL
where all users are redirected after they log out. This URL is not a Banner Flexible
Registration URL but another URL that you might have. Use the following steps if you
want to define a logout redirect URL.
1. Access the Flexible Registration Configuration Rules (SFRACNFG) form.
2. Enter the following URL:
CAS logout redirect Full URL to a page where users are redirected after the CAS
URL logout process is completed. Include the protocol, machine
name, port number, application root, and page if required.
Example:
http://ellucianuniversity.com:443/
home.html
The URL in this example redirects all users to the home.html
page when they log out of CAS from Banner Flexible
Registration.
3. Save the change.
Step 3 - Disable the ability to change passwords

A Change Password link is optionally displayed in Banner Flexible Registration user
profiles. Because CAS handles authentication requests, Banner Flexible Registration
cannot determine the method for changing passwords. Therefore, the ability to change
passwords must be disabled. Use the following steps to hide the Change Password link
in user profiles.
1. Access the Flexible Registration Catalog Rules (SFRACTLG) form.
2. On the Rules tab, disable the Display Change Password link under My Profile?
parameter.
3. Save the change.
Step 4 - Configure forced CAS logouts (optional)

When students sign out of Banner Flexible Registration, they normally stay logged into
CAS. This allows them to use SSO to access other applications in the same browser
session.
In some situations, however, you might not want to force students to log out of CAS after
they exit Banner Flexible Registration. For example, you might want students to log out of
all applications and CAS when they are using Banner Flexible Registration on a kiosk or
public computer.
Use the following steps if you want to force Banner Flexible Registration to call the CAS
sign out process whenever students sign out of Banner Flexible Registration.
1. Access the Flexible Registration Catalog Rules (SFRACTLG) form.
2. In the URL Redirect on Sign Out parameter field on the Rules tab, enter the URL of
the page that should be displayed when users sign out of Banner Flexible
Registration.
3. Save the change.
Step 5 - Configure a CAS service for Banner Flexible Registration

The CAS server needs to know that the Banner Flexible Registration URL is protected for
SSO. This is accomplished by configuring a CAS service for Banner Flexible Registration.
Use the following steps to configure the CAS service that protects Banner Flexible
Registration.
administrator).
Name Flexible Registration

Service URL http(s)://<Flexible Registration
server>:<Flexible Registration port>/
<application name>/**
Description Protecting Flexible Registration via CAS
5. Click Save Changes. The CAS server is now protecting Banner Flexible Registration.
CAS-protected URLs
You must provide users with a CAS-protected URL that can be used to access Banner
Flexible Registration through SSO. This special URL ensures that a user signs in through
CAS. A CAS-protected URL has the following structure:
<protocol>://<host>:<port>/<application>/cas/
index.jsp?frc= <catalog code>
The only difference between the CAS-protected URL and the normal URL is the context
path (/cas) before the index.jsp link.
Examples:
For users with accounts at your institution who are using CAS for SSO:
https://ellucianuniversity.com:443/flexibleregistration/
cas/index.jsp?frc=A0
For users without accounts at your institution:

index.jsp?frc=A0
If you are using the Multi-Entity Processing (MEP) features of Banner Flexible
Registration:
cas/institution/CAMP1/catalog/A0/
Configuring Banner Integration for
Ellucian Talent Management Suite for
CAS
This chapter describes the configuration of Banner® Integration for Ellucian Talent
Management Suite to support single sign on (SSO) via Central Authentication Service
(CAS). In a CAS-based environment, user authenticate to CAS instead of Banner
Integration for Ellucian Talent Management Suite.
Prerequisites
service.
• If you are using Banner Enterprise Identity Services (BEIS) to generate UDCIdentifiers,
BEIS 8.1.5 or higher is required. Refer to “How does Banner support identity
management?” on page 12 for more information about BEIS.
Processing flow
The following processing occurs when Banner Integration for Ellucian Talent Management
Suite is accessed in an SSO session:
User 1. Opens a web browser and requests access to Banner

Integration for Ellucian Talent Management Suite through a
protected URL:
https://<BITM server>:<port>/bitm-core/
splash.zul
Example: http://myBanner9xServer.edu:8080/
StudentRegistration/
banner.zul?page=mainPage
3. Logs in to CAS.
CAS Single Sign On Handbook | Configuring Banner Integration for Ellucian Talent Management Suite for CAS 108

6. Redirects the ticket to Banner Integration for Ellucian Talent
Management Suite, passing the ticket as a parameter in the
URL.
Banner Integration 7. Calls the CAS /samlValidate service.

for Ellucian Talent
Management Suite

10.Returns the ticket to Banner Integration for Ellucian Talent
Management Suite.
Banner Integration 11. Grants access to the user.

for Ellucian Talent
Management Suite
Configuration steps
Use the following steps to implement CAS support for Banner Integration for Ellucian
Talent Management Suite:
• Step 1 - Modify configuration files

• Step 2 - Configure a CAS service for Banner Integration for Ellucian Talent Management
Suite
Step 1 - Modify configuration files

CAS support for Banner Integration for Ellucian Talent Management Suite is implemented
by modifying the following configuration files:
web.xml
applicationContext-springSecurity.xml
The BITM-Installer.zip file, delivered with Banner Integration for Ellucian Talent
Management Suite, configures bitm-core.war for SSO support. Refer to the Banner
Integration for Ellucian Talent Management Suite Handbook for instructions on using this
tool.
If you are accessing the application using the Oracle HTTP Server (OHS), you should use
the same URL within web.xml to enable SSO.
Step 2 - Configure a CAS service for Banner Integration for Ellucian Talent
Management Suite
The CAS server needs to know that the Banner Integration for Ellucian Talent
Management Suite URL is protected for SSO. This is accomplished by configuring a CAS
service for Banner Integration for Ellucian Talent Management Suite. Use the following
steps to configure the CAS service that protects the Banner Integration for Ellucian Talent
Management Suite.
administrator).
Name Banner Integration for Ellucian Talent

Management Suite
Service URL http(s)://<BITM server>:<BITM port>/
bitm-core/**
Description Protecting Banner Integration for Talent
Management via CAS
5. Click Save Changes. The CAS server is now protecting Banner Integration for
Ellucian Talent Management Suite.
Processing notes
• The following URL must be used to access CAS-enabled Banner Integration for Talent
Management Suite:
https://<BITM server>:<port>/bitm-core/splash.zul
• If you get a certificate error when you launch Banner Integration for Ellucian Talent
Management Suite, you must import the certificate from the CAS server into the Java
Developer’s Kit (JDK) that is running the Banner Integration for Ellucian Talent
Management Suite application server.
• If your server is behind proxy, the following error might occur when you launch the
application:
ERROR> <?:?> - Unable to parse SAML 1.0 Schemas:
org.xml.sax.SAXParseException:schema_reference.4: Failed to read schema
document 'xmldsig-core-schema.xsd', because 1) could not find the
document; 2) the document could not be read; 3) the root element of the
document is not <xsd:schema>.
To resolve the error, perform the following setup on the Oracle WebLogic command
window where the application is deployed. Do the setup before you start the managed
server.
Windows
set PROXY_SETTINGS=-Dhttp.proxyHost=<proxy server> -
Dhttp.proxyPort=<proxy port>
Unix/Linux
PROXY_SETTINGS=-Dhttp.proxyHost=<proxy server> -Dhttp.proxyPort=<proxy
port>export PROXY_SETTING
Configuring Banner Travel and
Expense Management for CAS
This chapter describes the configuration of Banner® Travel and Expense Management to
support single sign on (SSO) via Central Authentication Service (CAS). In a CAS-based
environment, a user authenticates to CAS instead of Banner Travel and Expense
Management.
Prerequisites
service.
Processing flow
The following processing occurs when Banner Travel and Expense Management is
accessed in an SSO session:
User 1. Opens a web browser and requests access to Banner Travel

and Expense Management through a protected URL:
https://<TEM server>:<port>/tvlexp/
tvlexp-flex/index.html
3. Logs in to CAS.

6. Redirects the ticket to Banner Travel and Expense
Management, passing the ticket as a parameter in the URL.
Banner Travel and 7. Calls the CAS /samlValidate service.

Expense
Management
CAS Single Sign On Handbook | Configuring Banner Travel and Expense Management for CAS 112

10.Returns the ticket to Banner Travel and Expense
Management.
Banner Travel and 11. Grants access to the user.

Expense
Management
Configuration steps
Use the following steps to implement CAS support for Banner Travel and Expense
Management:
• Step 1 - Configure tvlexp.ear

• Step 2 - Configure a CAS service for Banner Travel and Expense Management
Step 1 - Configure tvlexp.ear

The TEM-Configuration-Assistant.zip file, delivered with Banner Travel and
Expense Management, configures tvlexp.ear for SSO support. Refer to the Banner
Travel and Expense Management Handbook for instructions on using this tool.
The Configuration Assistant uses the following properties to configure SSO within
tvlexp.ear. If you are accessing the application using the Oracle HTTP Server (OHS),
you should use the same URL for the following configuration.
Property name Purpose
SSO Enables single sign on
casServerLoginUrl CAS or portal login URL
tvlexpAppURL URL for the Banner Travel and Expense Management

application
logout.success.url Logout URL to return to the portal
portalURL URL where a user is redirected if access to Banner Travel

and Expense Management fails
waitSeconds Number of seconds to wait before the redirect
assertionAttribute Attribute that is used to assert identity. UDC_IDENTIFIER is

the default. Can be configured if a different attribute is used.
Property name Purpose
accessErrorMsg Message that is displayed if the required role is missing
loginErrorMsg Message that is displayed if credentials do not match

GOBUMAP
When the Configuration Assistant is run with the preceding properties, the following files
are modified to enable SSO:
web.xml
applicationContext-springSecurity.xml
Step 2 - Configure a CAS service for Banner Travel and Expense

Management
The CAS server needs to know that the Banner Travel and Expense Management URL is
protected for SSO. This is accomplished by configuring a CAS service for Banner Travel
and Expense Management. Use the following steps to configure the CAS service that
protects Banner Travel and Expense Management.
administrator).
Name Travel and Expense Management

Service URL http(s)://<Travel and Expense
server>:<Travel and Expense port>/
<context root>/**
Description Protecting Travel and Expense Management
via CAS
Theme Name TETheme
5. Click Save Changes. The CAS server is now protecting Banner Travel and Expense
Management.
Processing notes
• The following URL must be used to access CAS-enabled Banner Travel and Expense
Management:
https://<TEM server>:<port>/tvlexp/tvlexp-flex/index.html
• If you get a certificate error when you launch Banner Travel and Expense Management,
you must import the certificate from the CAS server into the Java Developer’s Kit (JDK)
that is running the Banner Travel and Expense Management application server.
Configuring Banner Workflow for
CAS
This chapter describes the configuration of Banner® Workflow to support single sign on
(SSO) via Central Authentication Service (CAS). In a CAS-based environment, users
authenticate to CAS instead of Banner Workflow.
Note: Banner Workflow also supports SSO with third-party access

managers such as Oracle Access Manager. Refer to the Banner
Workflow Technical Integration Guide for details.
Prerequisites
The external ID of Banner Workflow users must be set to the users’ UDCIdentifiers.
Processing flow
The following processing occurs when Banner Workflow is accessed in an SSO session:
User 1. Opens a web browser and requests access to Banner

Workflow through a protected URL:
https://<workflow server>:<workflow
port>/<web context name>
3. Logs in to CAS.

6. Redirects the ticket to Banner Workflow, passing the ticket
as a parameter in the URL.
Banner Workflow 7. Calls the CAS /samlValidate service.
CAS Single Sign On Handbook | Configuring Banner Workflow for CAS 116

10.Returns the ticket to Banner Workflow.
Banner Workflow 11. Grants access to the user.
Configuration steps
Use the following steps to configure Banner Workflow for CAS:
• Step 1 - Modify configuration.xml

• Step 2 - Register the SSL certificate for the CAS server
• Step 3 - Register the SSL certificate for the Banner Workflow server
• Step 4 - Configure a CAS service for Banner Workflow
• Step 5 - Modify Banner Forms technology type
Step 1 - Modify configuration.xml

Use the following steps to modify the Banner Workflow configuration.xml file.
1. Navigate to WORKFLOW_HOME/instance/config.
2. Open configuration.xml using a text editor.
3. Modify Authentication mode as follows:
Authentication mode - "CAS"
4. Modify the following properties in the CAS section:
Property Description
ServiceURL Banner Workflow URL that is used to

service requests from the CAS server.
Format is <protocol>:<workflow
host>:<workflow port>/
<workflow root>/j_spring_
cas_security_check.
Example:
http://school.edu:7777/
workflow/j_spring_cas_
security_check
LoginUrl URL used to log in to CAS
AuthenticationProviderKey Key required by Banner Workflow’s CAS

authentication provider to identify tokens
that it previously authenticated
ProxyTicketValidatorUrl URL of CAS
Example:
http://school.edu:7777/cas
ExternalIDAttribute Name of the attribute that is returned by
/samlValidate in the SAML assertion and
contains the value used to look up a user
by external ID.
CAS is configured to return the

UDCIdentifier to Banner Workflow in the
SAML attribute UDC_IDENTIFIER. The
value of ExternalIDAttribute
must be UDC_IDENTIFIER.
5. (Optional) If you wish to provide an external link to log users out of Banner Workflow
and CAS, set the <LogoffUrl> element as the last child element under
<SecurityIntegration>.
Note: If you do not set this element, the Logoff link in Banner Workflow
does not log users out of Banner Workflow or CAS.
Step 2 - Register the SSL certificate for the CAS server
The CAS server runs under SSL (Secure Sockets Layer). Register the SSL certificate
used by the CAS server into the keystore file (cacerts) that the Oracle WebLogic
Server uses for the Java installation. This is typically done by using the keytool command.
Example:
<JAVA_HOME>/bin/keytool -import -file <cas.cert> -
keystore <JAVA_HOME>/jre/lib/security/cacerts
<JAVA_HOME> is the path of the JDK that is used to launch the Banner Workflow
application server container, and <cas.cert> is the path of the certificate file for
the CAS server.
The keytool prompts for a password, which is typically 'changeit' for a default Java
installation.
Step 3 - Register the SSL certificate for the Banner Workflow server
The CAS-enabled Banner Workflow server also runs under SSL (Secure Sockets Layer).
Register the SSL certificate used by the Banner Workflow server into the keystore file
(cacerts) that the CAS server uses for the Java installation. This is typically done by
using the keytool command.
Example:
<JAVA_HOME>/bin/keytool -import -file <workflow-
server.cert> -keystore <JAVA_HOME>/jre/lib/security/
cacerts
<JAVA_HOME> is the path of the JDK that is used to launch the CAS application
server container, and <workflow-server.cert> is the path of the certificate
file for the Banner Workflow server.
The keytool prompts for a password, which is typically 'changeit' for a default Java
installation.
Step 4 - Configure a CAS service for Banner Workflow

The CAS server needs to know that the Banner Workflow URL is protected for SSO. This
is accomplished by configuring a CAS service for Banner Workflow. Use the following
steps to configure the CAS service that protects Banner Workflow.
administrator).
Name Banner Workflow

Service URL https://<workflow host>:<workflow port>/
<web context name>/**
Example: https://school.edu:7777/workflow/**
Description Protecting Banner Workflow via CAS

5. Click Save Changes. The CAS server is now protecting Banner Workflow.
Step 5 - Modify Banner Forms technology type

Use the following steps to specify the URL for accessing Internet-Native Banner when
SSO is implemented.
1. Log in to Banner Workflow as an administrative user.
2. Select Administration > Workflow System Administration.
3. Click Technology Types.
4. Click Banner Forms.
5. Click the values displayed in Web Launch Parameters.
6. Change the value of banner_inb to the following:
http://<host>:<port>/ssomanager/c/INB
This is the URL that is used to access Internet-Native Banner when SSO is
implemented.
7. Click Save.
Integration with BDM

Banner Workflow can be integrated with Banner Document Management (BDM) to
streamline document-based processes. The following features can be combined to build
powerful workflows that efficiently route documents among participants in a workflow:
• Three URL links, contained in BDM, can be used to open a document, search for
documents, or upload a document.
• The Custom Activity Designer, contained in Banner Workflow, can be used to create
custom activities. A custom activity can include simple HTML tags such as <href> for
URL links that use workflow context parameters.
• Business event parameters are delivered as part of the integration between BDM and
Banner Workflow.
Refer to “Integration with Banner Workflow” on page 94 for integration details.
Configuring Ellucian Degree Works
for CAS
This chapter describes the configuration of Ellucian Degree Works to support single sign
on (SSO) via Central Authentication Service (CAS). CAS integrates Degree Works with
portals and other web applications.
CAS supports SSO by issuing a one-use ticket to an end user. The ticket can be validated
by a client application and is also used to retrieve the identity of the end user for internal
use. Degree Works uses different IDs to internally identify each end user and to log the ID
in to CAS. For example, an end user usually logs in to CAS using the LDAP ID, while
Degree Works internally uses the rad_id. As part of the CAS configuration, you must set
up a mapping of user IDs in your authentication data store to Degree Works IDs.
Note: The rad_id is used when Degree Works is integrated with Banner®
and equals the spriden_id.
Prerequisites
Degree Works uses AuthCasDgw.pm to support CAS single sign on for the main web
application. AuthCasDgw.pm is a Perl module that Degree Works adapted from an
open-source module called AuthCAS. Several other Perl modules are also required due to
dependencies from AuthCasDgw.pm.
Note: Degree Works Windows-based applications such as Transfer

Equivalency, Transit, and Scribe do not support CAS single sign on.
The Web09 server and the IRISLink.cgi server use AuthCasDgw.pm. If these
components are deployed on different servers, for example the application server and the
web server, you must install the prerequisite Perl modules on both servers. Information on
installing CPAN Perl modules is available at http://www.troubleshooters.com/codecorn/
littperl/perlcpan.htm.
The AuthCasDgw.pm Perl module requires the IO::Socket::SSL and the

LWP::UserAgent classes. Therefore, its dependencies are SSL.pm, which in turn has
several dependencies including SSLeay.pm.
To install the Perl modules, log in as root and run the following commands:
perl -MCPAN -e 'shell'
install HTML::Entities
install IO::Socket::SSL
install LWP::UserAgent
install XML::DOM
CAS Single Sign On Handbook | Configuring Ellucian Degree Works for CAS 122
When you are prompted to include prerequisites/dependencies for each module, answer
[yes].
Note: This process varies, depending on the platform.
Processing flow
The Degree Works IRISLink.cgi CGI checks for a CAS ticket. If a ticket is not
present, the request is redirected to the CAS server. After CAS authentication takes place,
the CGI passes the user’s ticket to the Degree Works application server, Web09, where
the ticket is validated. The end user’s Degree Works ID is retrieved from CAS during ticket
validation.
Configuration steps
To configure the Degree Works Administrative Shell (DWShell) for CAS, all configurations
described in the following steps must be completed, including the configuration of the
Shepherd Settings. For Degree Works Web alone, the Shepherd Settings are not
required.
Use the following steps to configure Ellucian Degree Works for CAS:
Step 1 - Configure the Degree Works Banner extract
Step 2 - Configure a CAS Service for Degree Works
Step 3 - Export the CAS SSL certificate
Step 4 - Configure Degree Works for CAS support
Step 5 - Customize Degree Works Web and shpscripts pages
Step 6 - Configure Shepherd Settings for administrative shell (dwshell)
Step 1 - Configure the Degree Works Banner extract

The Degree Works Banner extract is configured to extract each user’s UDCIdentifier and
store it in Degree Works.
Select access must be granted to the GOBUMAP table in Banner, for the Degree Works
user (typically dwmgr). When the Banner extract is run, if a GOBUMAP record is found for
the individual, the GOBUMAP_ID is loaded into the SHP_USER_MST.SHP_ALT_ID.
Refer to the Degree Works Banner Considerations Technical Guide for more details on
running Banner extracts.
Step 2 - Configure a CAS Service for Degree Works
The CAS server needs to know that the Degree Works URL is protected for SSO. This is
accomplished by configuring a CAS service for Degree Works. Use the following steps to
configure the CAS service that protects Degree Works.
administrator).
Name Degree Works

Service URL http(s)://<Degree Works classic webserver>:
<Degree Works classic webserver port>/**
Description Protecting Degree Works through CAS
5. Click Save Changes. The CAS server is now protecting Degree Works.
Step 3 - Export the CAS SSL certificate

The CAS server and the Degree Works Web server must run in the HTTPS/SSL mode. To
enable Degree Works to make an HTTPS connection to your CAS server, export the SSL
certificate used on your CAS server to a file and make it accessible to Degree Works on
both the host/application server and its web server. The location of this certificate authority
or certificate file is configured in the CgiSettings.pl $CAS_CAFile. The format of
the certificate file is .pem.
Consult the documentation from your certificate provider, for example VeriSign or Thawte,
for more information on exporting SSL certificates to a file and converting between various
certificate formats.
Step 4 - Configure Degree Works for CAS support

Use the following steps to configure Degree Works for CAS support.
1. Navigate to $LOCAL_HOME/app/perl_libs/CgiSettings.pm on your
application server.
2. Copy all previously backed-up IRISLink.cgi settings (for example,
$DEF_SERVER_NAME and $DEF_PORT_NUMBER) into CgiSettings.pm.
3. Set $CAS_Enabled = $TRUE;
4. Set the CAS server URL.
Example: $CAS_URL = 'https://your.cas.server:8443/cas-
server-webapp-3.3.3';\
5. Set the location of the CAS server’s SSL certificate.
You can set the location two different ways, depending on how you set up your
certificates:
$CAS_CAFile = '/etc/httpd/conf/ssl.crt/ca-bundle.crt'
or
$CAS_CAFile = "/usr/local/certificates/tomcatcert.pem";
6. Set the user ID attribute name to the same value that is configured in CAS
attribRepository for the user ID attribute mapping:
$CAS_ID_Attribute_Name = 'UDC_IDENTIFIER';
This file is also located on your web server. You should make the same changes to
that file. The location of that file varies, but can be found by looking in
CgiSettingsDir.pm in the Degree Works Web root directory.
Step 5 - Customize Degree Works Web and shpscripts pages

Use the following steps to customize Degree Works Web and shpscripts pages.
1. Configure the CAS login link as follows:
1.1. Configure your web server to turn off access to webroot/default.html.
This is the default login page, which is no longer used.
1.2. Provide a CAS login link on a page of your choice (for example, a portal home
page). The following code snippet illustrates this:
<a href="IRISLink.cgi?CAS=ENABLED&SERVICE=LOGON&SCRIPT=SD2WORKS&"
target="_new">
Click here to use CAS
</a>
2. If you want to redirect users to a page or if you want to log users out of CAS when they
click Logout, configure the following settings in dwenv.config and then issue the
webrestart command:
ENABLE_EXTERNAL_LOGOUT=1
gsCfgExternalLogoutUrl=http://for.example.your.server/cas-web/logout
3. Customize the 0775 error message that Degree Works issues when CAS validation
fails. You can customize the message by editing shpscripts/SERR0775.
Step 6 - Configure Shepherd Settings for administrative shell (dwshell)

For DWShell only, configure the core.security.cas.enable and
core.security.cas.loginUrl settings.
Do not enable both core.security.externalAccessManager.enable and
core.security.cas.enable. Only one should be enabled at a time.
Make sure the setting for core.security.cas.loginUrl matches the value

defined in CgiSettings $CAS_URL.
Configuring Ellucian Luminis
Platform 5 for CAS
The Luminis® Platform 5 installation process includes an option to install a CAS server.
The method used to configure a CAS server depends on whether a CAS server is already
installed:
• If a CAS server is already installed, do not install the CAS server that is delivered with
Luminis Platform 5. Rather, you must install and configure Luminis Platform 5 against
the existing CAS server. Refer to Chapter 6, "External CAS Installation and
Configuration," in the Luminis Platform 5.1 Installation Guide for specific instructions.
• If a CAS server is not already installed, install the CAS server that is delivered with
Luminis Platform 5. Refer to the Luminis Platform 5.1 Installation Guide to review all
deployment options and associated instructions.
CAS Single Sign On Handbook | Configuring Ellucian Luminis Platform 5 for CAS 127
Glossary
account provisioning
A process that creates, maintains, and deactivates user identity data in a central
directory or multiple applications.
Banner Enterprise Identity Services (BEIS)

A collection of Banner® components that support account provisioning and single sign
on (SSO).
BEIS
See "Banner Enterprise Identity Services."
CAS
See "Central Authentication Service."
central access manager

A generic term for a software application that controls access to user information in an
SSO environment.
Central Authentication Service (CAS)

An open source single sign on (SSO) authentication service for web applications.
Originally developed by Yale University. Became a Jasig project in 2004.
claims-based authentication
A method of authenticating a user’s identity where a trusted entity issues and signs a
trusted ticket that contains claims about the user’s identity.
deep-linking
The ability to bypass a menu page and hyperlink directly to a specific page in Self-
Service Banner (SSB) or to a specific form in Internet-Native Banner (INB).
federated identity
A method that connects a user’s digital identity and attributes across multiple identity
management systems.
CAS Single Sign On Handbook | Glossary 128

IAM
See "identity access management."
identity access management (IAM)

and
identity management (IdM)
A framework of business processes that capture, record, and manage digital user
identities and their access privileges to applications across your institution.
IdM
See "identity management."
Jasig
Java Administration Special Interest Group, a US-based, nonprofit organization that
creates open source software for higher education.
SAML
See "Security Assertion Markup Language."
Security Assertion Markup Language (SAML)

An XML-based standard that is used to authenticate and authorize data exchanged
between parties, specifically between an identity provider and a service provider.
single sign on (SSO)

Business processes and a supporting infrastructure that allow a user to securely
access multiple systems with a single login.
SSO
See "single sign on."
third-party authentication
A process that uses a trusted external source to facilitate access to specific
applications.
SSO Manager
A BEIS component that acts as an SSO gateway for Internet-Native Banner (INB) and
Self-Service Banner (SSB).

UDCIdentifier
A globally unique, system-generated identifier (GUID) that is assigned to each user at
your institution and stored in a central identity vault. This ID provides the basis for
SSO among Ellucian applications.

Troubleshooting
Refer to the following articles on the Ellucian Support Center (https://ellucian.force.com/

clients/home/home.jsp) for CAS troubleshooting information:
Article Title
1-1459RA7 How to Implement Banner 9 SSO with Luminis 5/CAS
1-13L1FQ7 Switching between Banner 9 Catalog and Schedule and Events is

prompting for login credentials
1-17LP4OF CAS authentication returning login_error=1 with CAS Standalone
1-1459RAB Banner 9 Luminis/CAS error No valid assertions from the SAML

response found
1-18AH27R CAS BEIS SSO (SSO manager) integration with Active Directory
1-1BM9F1F Banner 9 CAS outline and trouble shooting
1-1CQKQS8 Banner XE CAS implementation prompts for logon again
1-1F3JTLY Identity mapping CAS configuration file deployerConfigContext.xml
CAS Single Sign On Handbook | Troubleshooting 131

CAS Single Sign On Handbook

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CAS Single Sign On Handbook

Hochgeladen von

Copyright:

Verfügbare Formate

CAS Single Sign On Handbook

©2013-2014 Ellucian Company L.P. and its affiliates.

Prepared by: Ellucian

Ellucian integration with CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

What is third-party authentication? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

What is claims-based authentication? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

What is a common identifier? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

How does Banner support identity management? . . . . . . . . . . . . . . . . . . . . . . . . . 12

Plan your CAS implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Configure the CAS server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

CAS Single Sign On Handbook | Contents 3

Configuring Banner for CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

SSB configuration for CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

INB configuration for CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Banner 9.x configuration for CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Configuring Banner Document Management for CAS . . . . . . . . . . . . . . 89

CAS with ApplicationXtender products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Integration with Banner Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

CAS Single Sign On Handbook | Contents 4

Configuring Banner Effort Reporting and Labor Redistribution for

Configuring Banner Flexible Registration for CAS . . . . . . . . . . . . . . . . . 103

Supported versions of CAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Processing flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

CAS-protected URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Configuring Banner Integration for Ellucian Talent Management Suite

Processing flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Processing notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Configuring Banner Travel and Expense Management for CAS . . . . . . 112

Processing flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Processing notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

CAS Single Sign On Handbook | Contents 5

Processing flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Integration with BDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Configuring Ellucian Degree Works for CAS. . . . . . . . . . . . . . . . . . . . . . 122

Processing flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Configuring Ellucian Luminis Platform 5 for CAS. . . . . . . . . . . . . . . . . . 127

CAS Single Sign On Handbook | Contents 6

• Account provisioning creates, maintains, and deactivates user identity data in a

Ellucian integration with CAS

Note: Refer to http://downloads.jasig.org/cas for a list of available CAS

Banner - Self-Service (SSB) Page 29

Banner - Internet-Native (INB) Page 41

CAS Single Sign On Handbook | Introduction 7

Banner - 9.x Page 78

Banner Document Management Page 89

Banner Effort Reporting and Labor Redistribution Page 102

Banner Flexible Registration Page 103

Banner Integration for Ellucian Talent Management Suite Page 108

Banner Travel and Expense Management Page 112

Banner Workflow Page 116

Ellucian Degree Works Page 122

Ellucian Luminis® Platform 5 Page 127

CAS Single Sign On Handbook | Introduction 8

• Improved developer productivity and efficiency. SSO provides a common authentication

• Enhanced security. Having a single password promotes stronger passwords.

What is third-party authentication?

• Open source - Central Authentication Service (CAS) and Shibboleth

CAS Single Sign On Handbook | Functional Concepts 9