Single Sign On: Jagged Little Pill?

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 Domino Authentication/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 EJB Web Services Authentication/Authorization: LDAP lookups for the Admin Side Table with: Student Number / PIN

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 • Access Manager Server • Deployed to a set of central servers • Interfaces with Directory (Query/Update) • Policy Agent • Deployed to Application Servers and Web Servers • Interfaces with Access Manager Server for access policy decisions and performs people data-retrieval • Access Manager Software Development Kit (AMSDK) • Java or C API for developing applications • 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 Services 3rd-Party Applications

15. Now where are we?

16. Now where are we? Moved Remaining Java Applications to SSO and terminate the direct LDAP lookups PeopleSoft Financials integrated with SSO Moved to an Open-Source Java Container 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. Future • 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