1

Single Sign On: Jagged Little Pill?

2

What is Single Sign On?

• A central authentication and authorization service.

• Allows a token to be shared across systems to provide “logging in” to other applications without requiring userid and password again.

• May provide data about someone and authorize their use of the system.

• Name

• Email Address

• Student Number

• Degree Program / Course Enrollments

• University Affiliations

• Application Roles

• more ....

3

Where did we start?

Identity Systems Application Development

Homegrown IDM

Lotus DominoAuthentication/Authorization

4

Results

• Notes was secure but creating accounts for the entire student body had issues.

• The internal structure of Notes

• Not scalable in our environment

• Vendor Lock-in

• IBM started moving to WebSphere

• Could not buy off the street Notes developers

• Decision to move to a Java-based environment

5

Go Java!

Authentication/Authorization:Oracle Named Users with Roles for Admin Side

Table with:Student Number / PIN

6

Results

• Application Administrators required a new set of passwords

• Student Number / PIN were stored in the clear

• Application Development was much better

• Extracting data for reporting was trivial

• Needed to find a way to use the Email usernames and passwords

• Decision to build out a directory for identities: Enter LDAP

7

Go LDAP!

Identity Systems Application Development

Homegrown IDM

Authentication/Authorization:LDAP lookups for the Admin Side

Table with:Student Number / PIN

EJB

Web Services

8

Results

• Using NetIDs gave more trust to the identity of the Application Administrators

• Student Number / PIN were stored in the clear and still an issue

• Signing into each application was getting tedious for central applications

• CAS requires each page to be protected by custom code

• Java developers built a Struts extension to protect pages and servlets

• Now the problem: Applications were available through various departmental websites.

• Now we need a Web Portal or Application Registry and we need Single Sign On

9

It’s JES Time!

10

Java Enterprise System

11

Single Sign On Component

1. Access Manager Server

• Deployed to a set of central servers

• Interfaces with Directory (Query/Update)

2. Policy Agent

• Deployed to Application Servers and Web Servers

• Interfaces with Access Manager Server for access policy decisions and performs people data-retrieval

3. Access Manager Software Development Kit (AMSDK)

• Java or C API for developing applications

1. Can be used for more sophisticated querying/updating

12

Why use it - Technical

• Web applications share an SSO session no need to authenticate again

• No need to maintain an in-house custom login session manager

• No need to store passwords in external systems

• No need to understand LDAP or the internals of SSO

• Access rules are centrally configured based on any LDAP filter.

• All access attempts are logged

• Identity content is controlled by IDM as a result it is the latest available

• Anyone with a NetID can authenticate

• An expanded and better defined attribute release vocabulary than CAS

13

Why use it - Business

• Can concentrate on the application not identity data.

• No need to store passwords

• No need to configure password management rules

• No need to load identity data

• Access rules are centrally configured based on any LDAP filter.

• Access attempts success or failure can be audited

• Identity content is the latest available

• Anyone with a NetID can authenticate

• Application can be seamlessly launched from MyQueensU

14

Go SSO!

Identity Systems Integration Development

Homegrown IDM

EJB

Web Services3rd-Party Applications

15

Now where are we?

16

Now where are we?Moved Remaining Java Applications to SSO and terminate the direct LDAP lookups

Moved to an Open-Source Java Container

PeopleSoft Financials integrated with SSO

JIRA and Wiki moved off of SSO

17

What have we learned?

18

Benefits

• SSO protects the entire Web Server not just individual pages

• Developers want to do it!

• Central IT benefits tremendously as passwords are secure at all levels

• Changing online identity policy is now in a single location

• MyQueensU is in the AM-SSO-REALM

• Keeps the login process consistent

19

Drawbacks

• Some departments may feel a loss of control

• Very few applications have OOTB support

• 3rd-party applications require integration/customization effort

• The fear of a Single Point of Failure

• Logout/Close browser window debate

• Password Compromise

• The application owner/business makes integration decisions

20

The Reality

• Take a step back

• It’s all about the Business Units

• Budget pressure -> Reduce paper processes

• Priority #1: The Business Application

• There is a place for everything and everything has it’s place

• 3rd-party applications typically cost money/time to integrate

• Custom built applications should be a no-brainer

• Not all applications are suited to be integrated into SSO

• Some kids just don’t want to play in the same sandbox

21

• Budget Pressure

• The Business continues to focus on their Business

• More demand from ITS

• Take stock: What do we have, use and need?

• Understand the campus landscape and their priorities/needs

• SSO/Identity is just one facet of what the Business will need

• Keep an eye on what others do - Vendors/Communities/Peers

• Keep moving forward

• More integrations (3rd-party and Applications) on campus

Future