Single Sign On: Jagged Little Pill?
-
Upload
rubaina-manaf -
Category
Documents
-
view
44 -
download
2
description
Transcript of 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 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