The Homegrown Single Sign On (SSO) Project at UM – St. Louis

Introduction

Kyle Collins – Principal Systems Administrator

Kelly Crone-Willis – Expert Systems Administrator

Outline

Problems And Goals Why An In-House Solution? Where We Started From SSO Version 1 SSO Version 2 SSO Version 3 Key Concepts Conclusion

Problems and Goals

Multiple Ids On Varying Systems

Non-synched Passwords

Expanding Services

End User Support For Multiple Accounts And Systems

Users Have One ID For All Systems

Synchronize Passwords

Improve And Simplify Support

Flexibility To Add New Systems

***One Login******One Login***

Why An In-House Solution?

University Environment Had Many Platforms For Computing

Standardizing On A Single OS Not Possible

Vendor Solutions Very Expensive Unreliable And Undeveloped Long Term Effort

Where We Started From

New Account System Introduced System Wide

Oracle Meta-database New Systems Being Deployed

Provided An Opportunity To Start SSO

Created A New Default Password For All SSO Based Accounts

SSO Version 1

Oracle Server Holds Account Information And Unique ID For Each User

Individual Servers Create Accounts Based Upon Metadata

Accounts All Created With A Standardized Default Password

SSO Version 1 (cont.)

User Goes To SSO Web Page To Sync Passwords

Auths To Kerberos To Verify

Linux Server Initiates Password Change To All Servers

SSO Version 1 (cont.)

Accomplishments ID And Passwords

Synchronized Across Systems

Password Complexity Enforced

Continuing Issues Did Not Work For

Non-hr/SIS Accounts

No Helpdesk Tools Administrators

Had To Fix Problems/Handle Special Cases

SSO Version 2

Replaced Kerberos Backend With Active Directory

Consolidated System Accounts Where It Made Sense

Provided Tools To Helpdesk And User

SSO Version 2 (cont.)

Presented A Central Point To Access Various Services

Users Still Had To Login To Each Service Individually

SSO Version 2 (cont.)

SSO Version 2 (cont.)

Accomplishments System Works For

Non-hr/SIS Accounts

Provided Helpdesk Tools To Reset Passwords And Assist Users

Provided Users Tool To Self Reset Passwords

Continuing Issues Users Still Had To

Login Each Time For Each System On Campus

SSO Version 3

Utilize A Redirection Service To Achieve A Single Login For Users

Using Blackboard Version 6 As A Central Point To Access Services

Achieved One Login*

How It Works

Email Server

Link

Client

Portal Server

SSL

Link

SSO Version 1

Client SSO Server

Portal Server

SSL

SSO Version 3

Portal Server Email Server

Link

Client SSO Server

SSL

SSO Version 3 (Cont.)

SSO Version 3 (cont.)

Demonstration https://mygateway.umsl.edu https://sso.umsl.edu

SSO Version 3 (cont.)

Accomplishments Users Login To

One Point, One Time, To Access Most Services On Campus

Can Be Leveraged For Shibboleth Like Functionality

Continuing Issues Unix Shell

Accounts Using NIS

Moving To Account Activation

Key Concepts

Single Repository For Account Information This Must Be The Authority For All Accounts

Leverage A Flexible Network Directory System For Centralizing Authentication This Helps To More Easily Bring In New

Systems Plan For Flexibility

Not Everything Makes Sense To Centralize Focus And Limit Divergence From The

System

Conclusion

The Most Difficult Tasks Finding A Starting Point Bringing In New Systems Selling The Initial Pain

The Most Important Objectives Make The System As Flexible As Possible New Systems Should Conform To The Standard Management Buy In

Questions?

Contact Information

Kyle Collins Email – collinsk@umsl.edu

Kelly Crone-Willis Email – cronek@umsl.edu

Thank you for attending!

Copyright Kyle Collins and Kelly Crone-Willis 2005. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.