Single sign-on

Mike Ladd

Nazia Raoof

Bret Walker

Kumar MukherjeeRajesh 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

Firew

all

Availability

Integrity ConfidentialityAuthentication

User logs into the intranet portal

Process Flow

Clicks on a third-party

site/application

CGI script gathersUser information

Hashes and encrypts

with private key

Visible to userNot visible to

the user

Third-party sitevalidates IP addand hash, and decrypts with

public key

Logs the user in with appropriate

credentials

Displays user information and grants access to

application

Technology

Mike

Technology Pros ConsLDAP 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, Email 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

SAML Security Assertion Markup Language

JSSO Java Single Sign On

IDM Identity Management Solution

IAM Identity Access Management

BuildComponents

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

BuildChallenges

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 2Architecture standards discouraging application centric authentication

Challenge 3Build 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

1 Password related helpdesk cost High

2 Workstation support Medium

3 Management cost of unacceptable number of user ID/passwords

Medium

4 Application centric security hardware/software/development cost

High

5 Productivity increase High

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:http://www.clareitysecurity.com/sso-video/Clareity-Single-Sign-On-Legal.pdf

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 regulationAre 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 communicatedHow and where credentials are storedHow backup and redundancy solutions are

implementedWhich 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 strategySSO can meet business needsCosts associated with implementing SSO are

justifiable

Thank you!

© Copyright 2008 MSIT RoadRunners Co. All rights reserved.