Single sign-on Mike Ladd Nazia Raoof Bret Walker Kumar Mukherjee Rajesh Radhakrishnan

Agenda Overview Process Technology Challenges Business and Legal Corporations and Industry

Overview Nazia

Overview Single sign-on for user Maintain one profile with user credentials Access multiple applications and/or third party sites Case Study  Corporation has 15,000 retail stores  Looses more than $1,000,000/year  High labor costs multiple authentication, unnecessary user clicks, forgotten passwords, multiple profiles  Limited time and resources to develop IT solutions

Benefits Better integration with third party websites Eliminates multiple authentication Reduces unnecessary user clicks Reduces initial setup of profiles Reduces time spent on forgotten passwords Reduces volume of help desk calls

Components evaluated Security Portability Usability Cost Manageability

Process Intranet portal Middleware External (Third Party) websites Internal web application Firewall

Availability Integrity ConfidentialityAuthentication User logs into the intranet portal Process Flow Clicks on a third-party site/application CGI script gathers User information Hashes and encrypts with private key Visible to user Not visible to the user Third-party site validates IP add and hash, and decrypts with public key Logs the user in with appropriate credentials Displays user information and grants access to application

Technology Mike

TechnologyProsCons LDAP Widely used Might not be supported by app Complex coordination Kerberos Widely used Complex May not be open to outside world Custom solution Fits needs exactly Single use Potentially more complex / insecure Windows Live ID Web-based Users may already have account Not widely supported Managed by third party

Hash Fixed-length digital representation of a message (message digest) Input -> fixed-size string (the hash value) “digital fingerprint”

SHA Collection of five cryptographic hash functions SHA-1: used in security protocols such as TLS, SSL, PGP, SSH  Recently compromised  Output = 160 bits  Block = 512 bits  80 rounds

Possible Improvements Upgrade to SHA2 Integration w/ LDAP / AD Implement Shibboleth  Open-source implementation of Federated Identity  User information stored across multiple distinct identity management systems

Challenges Rajesh

Challenges Build or Buy decisions Integration issues Still in infancy & little or no standards Avoiding high availability and Enterprise wide issues Service offerings vs. appropriate users Licensing issues Write your own SSO server?  Myriads of interfaces to write Buy?  Limited options  Proprietary implementations Legacy applications, Solutions, Content Management solutions, Mainframe/Unix/Windows, owned solutions Availability of connectors JSSO/SAML emerging but in infancy Open to whole world scenario if not carefully planned

Glossary SAMLSecurity Assertion Markup Language JSSOJava Single Sign On IDMIdentity Management Solution IAMIdentity Access Management

Build Components

Build High Level Development Tasks Develop SSO Server - Modules to maintain repository & policy files - Loopback AUTH routines Develop AUTH EXIT routine for partner apps to check if user is logged on to SSO Server Develop AUTH EXIT routine for external apps to request user ID/Password from SSO Server

Build Challenges From Internal Applications Challenge 1 - Myriads of internal applications with application centric security modules Challenge 2 – Developer’s resistance to give up applications centric security module (legacy) From third-party software Challenge 3 - No control over third-party applications - No support from vendors for something that you build - Upgrade & maintenance

Build Handling challenges Challenge 1 Internally developed applications all use a common EXIT routine that is centrally developed by a common component team in your organization Challenge 2 Architecture standards discouraging application centric authentication Challenge 3 Build based SSO on standards SAML & JSSO Include a step in every vendor evaluation process to validate support for SSO standards and interoperability with your own SSO solution

Buy? Options Total IDM or IAM solution? SSO only? Gartner Magic Quadrant

Buy? Challenges Proprietary/Vendor lock in Support for third-party applications Legacy support (mainframe) Internal application resistance & support issues Integration issues Cost -Cost of hardware, software, & maintenance - Cost of integration - Cost of development (existing internal application unwiring application centric logic)

Buy? Handling Challenges Proprietary/Vendor lock in – Support for standards Support for third-party applications – Request for Proposals Legacy support (mainframe) – Request for Proposals Internal application resistance & support issues – Architecture Standard Definition & Management support Integration issues – Request for proposals Cost -Cost of hardware, software, & maintenance – RFP to Multiple vendor - Cost of integration - Cost of development (unwiring application centric logic from existing internal application)

High Availability - Setup

High Availability - Issues Issue-> Data Synch issues Solution->Check Sync programs

IDM – Logical diagram

Cost Benefits 1Password related helpdesk costHigh 2Workstation supportMedium 3Management cost of unacceptable number of user ID/passwords Medium 4Application centric security hardware/software/development cost High 5Productivity increaseHigh

Business and Legal Consequences Bret

Identity Provider Businesses must decide who is the “identity provider” Being the identity provider means more responsibility.  Legal responsibilities  Business agreements Source for all business legal slides:

Agreements with partners Service Levels  Businesses must work out consequences for SLAs Support  Must dictate who provides support  Decide when support is available  Decide whether support is provided by third party

Agreements with Partners (con’t) Fees  Businesses must work out payment info for contracts  Agreements on fees for upgrade, maintenance and upkeep Auditing  Businesses must agree on auditing methodologies  Agreements on who audits

Regulations Partnerships might bring about more regulation  Are you doing business with a university (FERPA), health care provider (HIPAA) or publicly-traded company (SOX)?

Liability – questions to consider Have you committed to service levels? Have you implied or committed to a level of security? What happens after authentication? Are you liable for poor programming on your partner’s end? How do you deal with confidential information? Are you providing “reasonable” protection?

Insurance You and your partner should insure SSO- related systems Insurance should cover all workers working with SSO (workers compensation, injury, etc.) as well as users and businesses (information disclosure)

Policies and Procedures You must define policies and procedures for:  How authorizations will be communicated  How and where credentials are stored  How backup and redundancy solutions are implemented  Which technical standards will be used You must define how these can be updated as partnership matures

Corporations and Industry Kumar

Corporate and Industry Context SSO is a solution that is feasible in all industries across the board:  Agriculture  Automotive & Transportation  Construction  Education  Financial Services  Government  Healthcare  Real Estate

Corporate and Industry Context SSO can be implemented in any particular industry or corporation:  SSO can be implemented and aligned with the business strategy  SSO can meet business needs  Costs associated with implementing SSO are justifiable

Thank you! © Copyright 2008 MSIT RoadRunners Co. All rights reserved.