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
Firewall
Intranet portal
External (Third Party)
websites
Middleware
Internal web application
Process Flow
User logs into
the intranet portal
Clicks on a
third-party
site/application
Authentication
CGI script gathers
User information
Confidentiality
Hashes and
encrypts
with private key
Integrity
Third-party site
validates IP add
and hash, and
decrypts with
public key
Logs the user in
with appropriate
credentials
Visible to user
Not visible to
the user
Availability
Displays user
information and
grants access to
application
Technology
Mike
Technology Pros
Cons
LDAP

Widely used

Kerberos

Widely used

Custom solution

Fits needs exactly

Windows Live ID

Web-based
 Users may already
have account
Might not be supported by
app
 Complex coordination
Complex
 May not be open to outside
world
Single use
 Potentially more complex /
insecure
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

Write your own SSO server?


Myriads of interfaces to write
Buy?

Limited options
 Proprietary implementations

Integration issues

Legacy applications, Email Solutions, Content
Management solutions,
Mainframe/Unix/Windows, owned solutions

Still in infancy & little or no
standards

Availability of connectors

Avoiding high availability
and Enterprise wide issues

JSSO/SAML emerging but in infancy

Service offerings vs.
appropriate users

Open to whole world scenario if not carefully
planned

Licensing issues
Glossary
SAML
JSSO
IDM
IAM
Security Assertion Markup Language
Java Single Sign On
Identity Management Solution
Identity 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
1 Password related helpdesk cost
2 Workstation support
3 Management cost of unacceptable
number of user ID/passwords
High
Medium
Medium
4 Application centric security
hardware/software/development cost
5 Productivity increase
High
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
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 SSOrelated 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.