Single Sign-On in a Single Day
Jack McAfee
www.triaworks.com
Agenda
• Different SSO Approaches
• The IBM approach
– Enterprise Identity Mapping (EIM)
– Kerberos or Identity Tokens
• Implementation Overview
Page 2
A “Typical” Configuration
Who Benefits from SSO?
1. End Users  Higher Productivity
2. Administrators  Less Password Management
3. Programmers  More Secure Applications
UID: JACKM
PWD: HOUSTON
i1
OS/400 V5R2
i2
OS/400 V5R3
End
Users
UID: JACK
PWD: LONGHORN
x1
Windows 2003
Server
UID: jmcafee
PWD: LoneStar
i3
OS/400 V5R3
UID: rjmcafee
PWD: SpaceCenter
p1
Linux
UID: RJMCAF
PWD: ALAMO
Page 3
Synchronization SSO Approach
User ID/Password Synchronization
•
•
•
•
•
No end user productivity gains (not really SSO)
Implementation cost is high to synchronize UIDs/PWDs
Administration cost is high to maintain synchronization
UIDs and PWDs are limited by platform
Synchronization is not always reliable
UID: JACKM
PWD: TEXAS
i1
OS/400 V5R2
i2
OS/400 V5R3
End
Users
UID: JACKM
PWD: TEXAS
x1
Windows 2003
Server
UID: JACKM
PWD: TEXAS
i3
OS/400 V5R3
UID: JACKM
PWD: TEXAS
p1
Linux
UID: JACKM
PWD: TEXAS
Page 4
Centralization SSO Approach
User ID/Password Centralization
•
•
•
•
•
End user productivity gains
Implementation cost is high to capture and replay UIDs/PWDs
Administration cost is high to maintain centralization
Management cost is high to synchronize and secure list
Synchronization is not always reliable
UID: JACKM
PWD: HOUSTON
i1
OS/400 V5R2
i2
OS/400 V5R3
End
Users
UID: JACK
PWD: LONGHORN
x1
Windows 2003
Server
UID: jmcafee
PWD: LoneStar
i3
OS/400 V5R3
Central Repository
UID:
UID:
UID:
UID:
UID:
jmcafee
JACKM
JACK
RJMCAF
rjmcafee
PWD:
PWD:
PWD:
PWD:
PWD:
LoneStar
HOUSTON
LONGHORN
ALAMO
SpaceCenter
UID: rjmcafee
PWD: SpaceCenter
p1
Linux
UID: RJMCAF
PWD: ALAMO
Page 5
The IBM Approach
Single Sign-On Components
• Kerberos for authentication
– Uses strongly encrypted tickets and not passwords
– Implemented on all major platforms
• Enterprise Identity Mapping (EIM) for authorization
– Maps people to their user identities on various registries
– Registry might be a platform, application, or middleware
• Applications enabled for Kerberos and EIM
– IBM has enabled many popular services in V5R2 and i5/OS
– You can also enable your applications
Page 6
What is EIM?
IBM’s Enterprise Identity Mapping (EIM) is an
infrastructure for associating a unique person
with one or more user identities in various
registries across the enterprise
Jack
McAfee
Person
Associations
(EIM Identifier)
Registries
pSeries
rjmcafee
zSeries
RJM46D
iSeries
JACKM
User Identities
Page 7
Where is the EIM Domain kept?
• On a Domain Controller in an LDAP directory
• IBM Directory Server offers broad platform support:
– Windows® 2000, AIX®, Solaris™, and HP-UX™
– As well as Linux distributions for Intel™, and
– IBM eServer iSeries, pSeries, and zSeries platforms
EIM Application
Domain Controller
EIM Domain
People
Associations
VERY SECURE!
Neither User Identities
nor Passwords are
maintained in the
EIM Domain!
Registries
Page 8
Source and Target Associations
• Source
• Target
– For initial authentication
– Typically, desktop or laptop
– For subsequent authentication
– Typically, servers
– User Identity, Registry  Person
– Person, Registry  User Identity
Jack McAfee
People
Person
User
Identity
Registry
Association
Type
Person
User
Identity
Registry
Association
Type
Jack
McAfee
jmcafee
Gatekeeper
Source
Jack
McAfee
JACKM
Production
Target
User Identity:
jmcafee
User Identity:
JACKM
Page 9
The EIM and Kerberos Approach
Source
EIM and Kerberos
•
•
•
•
End user productivity gains
Easy to implement – no synchronization
Easy to manage – no centralization
Reduces password management cost!
EIM Identifier
Target
jmcafee on x1  Jack McAfee  JACKM on i1
UID: JACKM
PWD: HOUSTON
i1
OS/400 V5R2
Source
EIM Domain
Controller
Key Distribution Center (KDC)
i2
OS/400 V5R3
End
Users
x1
Windows 2003
Server
Targets
UID: jmcafee
PWD: LoneStar
Sign-On to x1 as jmcafee and get Kerberos TGT
KDC on x1 sends a Kerberos ST to i1
i1 authenticates the Kerberos ST
EIM  Jack McAfee is authorized on i1 as JACKM
UID: JACK
PWD: *NONE
i3
OS/400 V5R3
UID: rjmcafee
PWD: SpaceCenter
p1
Linux
UID: RJMCAF
PWD: ALAMO
Page 10
The EIM and Kerberos Approach
Services or Applications enabled by IBM
• OS/400 V5R2
–
–
–
–
–
–
iSeries Access
iSeries Navigator
Telnet (includes PC5250)
ODBC/JDBC/DRDA
LDAP
QFileSvr.400
• Post V5R2 GA
– Apache Web Server (PTF Group SF99098)
– IBM Websphere Host On-Demand (PTF level IP22748)
Page 11
SSO Approach Comparison
Cost to...
Acquire
Implement
Maintain
IBM Approach
Synchronization
Centralization
(+) Infrastructure
integrated into
OS/400, i5/OS by
IBM, and Windows
by Microsoft
(-) Infrastructure
provided by ISVs
(-) Infrastructure
provided by ISVs
(+) No Agents to deploy
(+) EIM and Kerberos
APIs are open
source
(-) Agents likely
deployed
(-) Must synchronize
UIDs/PWDs
(-) Potential changes to
security schemes
(-) Agents deployed
(-) Must synchronize and
secure centralized list
of UIDs/PWDs
(-) PWDs eventually
made available in
clear-text
(+) Infrastructure
supported by IBM
(+) No centralized list of
UIDs/PWDs to
secure or
synchronize
(-) Must maintain
synchronization
(-) UIDs/PWDs limited by
“weakest” platform
(-) Synchronization not
always reliable
(-) Scripts must be
maintained to capture
UIDs/PWDs
(-) Synchronization not
always reliable
Page 12
SSO Approach Comparison
Benefits...
IBM Approach
Synchronization
(+) Fewer UIDs/PWDs
(+) Fewer Sign-Ons
(+) Fewer UIDs/PWDs
(-) Same number of
Sign-Ons
(+) Fewer UIDs/PWDs
(+) Fewer Sign-Ons
(+) Fewer PWD reset
issues
(+) Fewer PWDs to
manage!
(+) Improved security
(+) Fewer PWD reset
issues
(-) Synchronization
issues
(+) Fewer PWD reset
issues
(-) Capture and
Synchronization
issues
(-) UIDs/PWDs reside
in two locations
(-) Limited benefit to
Programmers
(-) Some benefit to
Programmers – if
they can access
centralized
UID/PWD repository
End Users
Administrators
(Kerberos tickets,
*NONE passwords)
Programmers
(+) Leverage the same
EIM domain
managed by
Administrators
Centralization
Page 13
IBM Approach Benefits
• End Users
– Increased productivity
– No longer need to write down multiple passwords
– Only need to remember a single, strong password
• Administrators
–
–
–
–
–
Less time resetting passwords
More secure enterprise (including *NONE passwords)
No need to secure or synchronize another registry
Platform authorization schemes are not changed
Incremental roll-out
• Programmers
– Increased productivity
– User identities and passwords no longer hard coded
– Utilize same EIM domain maintained by administrators
Page 14
SSO in a Single Day! (Really)
• SSO requires extensive planning
– Everyone must be enabled at the same time
Not any more... End-user client applications (i.e. iSeries Navigator and PC5250) are configured to use Kerberos for authentication
– Platform authorization schemes need to be changed
Not any more... Authorization continues to be determined by user identity controls
• SSO configuration is a challenge
– EIM
IBM Directory Server integrated into OS/400; iSeries Navigator EIM Configuration wizard simplifies EIM configuration
– Kerberos
You are probably already using Kerberos; iSeries Navigator Network Authentication Service wizard simplifies Kerberos configuration
• SSO weakens overall security
– Passwords must be centrally stored and synchronized
EIM does not centrally replicate user identities and passwords; Kerberos tickets are used for authentication
– Single point-of-access for people with malicious intentions
Today, most end users already down their passwords or use password synchronization? Also 2-factor authentication is a countermeasure
• Expensive (time and or money)
– Deployment
Not any more... IBM has integrated EIM and Kerberos into OS/400 starting with V5R2
– Ongoing maintenance
TriAWorks Identity Manager for Single Sign-On (TIM SSO) make is easy to populate EIM, create associations, and identify problems
Page 15
SSO in a Single Day Implementation
1. Configure Kerberos
2. Configure EIM
3. Populate EIM
4. Create Associations
5. Configure Applications
Page 16
SSO in a Single Day Implementation
But what about web applications?
Page 17
The EIM and Identity Tokens Approach
Single Sign-On Components
• Client – Any web browser or Java application
– No change to WAS authentication model
• Middleware – WebSphere Application Server (WAS)
– WAS V5 or Express V5
– IBM Java Toolbox (JT400) Java Connector Architecture (JCA)
• Application – Enabled to create Identity Tokens
–
–
–
–
iSeries Access for Web
WebFacing
WebSphere Development Studio Client (WDSc) Web Tools
And YOURS!
• Back-end Server – V5R2 or i5/OS V5R3 iSeries
– Using the Java Toolbox (JT400)
– Which uses the iSeries Access host servers
Page 18
The EIM and Identity Tokens Approach
Enabled Single Sign-On Host Servers
• Sign-on server
• Central server
• File server
• Database server
• DRDA and DDM server
• Data queue server
• Remote command server
• Distributed program call server
• Network print server
Page 19
The EIM and Identity Tokens Approach
Single Sign-On Configuration
1.
Apply requisite PTF support
2.
Deploy WebSphere JT400 JCA and define:
a) The EIM domain location
b) Provide its authentication credentials
(i.e. userid and password)
c) Provide a WAS registry name
3.
Enable your WAS or Java application for SSO by adding
code to create Identity Tokens – jt400.jar in
http://www-1.ibm.com/servers/eserver/iseries/toolbox/downloads.htm
Page 20
The EIM and Identity Tokens Approach
Single Sign-On PTFs
The V5R2 Identity Token PTFs are:
PTF/FIX #: SI14141 - OS/400 - Extended Base Directory Support
LICENSED PROGRAM: 5722SS1
New function. Enterprise Identity Mapping (EIM) Identity Token Connection Factory.
(This is to enable the WebSphere JCA component)
PTF/FIX #: SI10930 - Operating System/400 LICENSED PROGRAM: 5722SS1
Identity token support added for the operating system.
PTF/FIX #: SI11002 - Operating System/400 LICENSED PROGRAM: 5722SS1
This PTF supplies support for identity tokens within the host servers.
PTF/FIX #: SI11003 - Operating System/400 LICENSED PROGRAM: 5722SS1
This PTF supplies support for identity tokens within the host servers.
The V5R3 Identity Token PTFs are:
PTF/FIX #: SI14181 - OS/400 - Extended Base Directory Support
LICENSED PROGRAM: 5722SS1
New function. Enterprise Identity Mapping (EIM) Identity Token Connection Factory.
(This is to enable the WebSphere JCA component)
Page 21
The EIM and Identity Tokens Approach
1. Sign-On to WebSphere application as jack
2. WAS application creates an Identity Token
JCA connector returns an ID Token to the app
The app forwards the ID Token to a JT400 object
JT400 presents the ID Token to the back-end iSeries
3. OS/400 accepts the Identity Token for authentication
4. EIM  jack in WebSphere is JACKM on i1
Write X1 QAUDJRN audit record
5. Pass Identity token to i3
6. EIM  jack in WebSphere is RJMCAF on i3
Write X1 QAUDJRN audit record
TriAWorks Identity Manager
for Single Sign-On
(TIM SSO)
TIM SSO imports people,
makes associations, and
maintains your SSO integrity
UID: JACKM
PWD: HOUSTON
i1
OS/400 V5R2
EIM Domain
Controller
UID: JACK
PWD: *NONE
x1
Windows 2003
Server
Targets
UID: jack
PWD: LoneStar
i3
OS/400 V5R3
Source
End
Users
UID: rjmcafee
PWD: SpaceCenter
p1
Linux
UID: RJMCAF
PWD: ALAMO
Page 22
Identity Tokens Code Sample
// Use the identity token J2C connector to obtain and return an identity token
private IdentityToken getIDToken() {
IdentityToken idToken = null;
ConnectionFactoryImpl cf = null;
Context ic = null;
try {
// Look-up a connection factory instance
ic = new InitialContext();
// Create and configure a managed connection factory instance. Note
that properties were set when managed conection factory was deployed. Lookup
the factory using an indirect JNDI (alias) name, configured in the
applications web.xml. Note that the value of the alias must match the JNDI
name used when the connector was deployed. Note you must use an indirect
lookup, WAS will not pass a Subject to the JCA if you use a direct lookup.
cf =
(ConnectionFactoryImpl) ic.lookup(
"java:comp/env/eis/IdentityToken_Shared_Reference");
} catch (Exception e2) {
out.println( "The lookup for the connection factory failed. Either,
the connector is not configured, or the servlet's resource reference (JNDI
name) is not set correctly in the web.xml file. The servlet expects the
resource reference in web.xml to be eis/IdentityToken_Shared_Reference");
Page 23
Identity Tokens Code Sample
// Use the identity token to create a connection object to the OS/400 (host
command server).
private AS400 getOS400Connection(IdentityToken idToken) {
AS400 OS400CmdConnection = null;
try {
// Create an AS400 object, and set the IdentityToken into it.
OS400CmdConnection = new AS400(remoteSystemName);
OS400CmdConnection.setIdentityToken(idToken.toBytes());
OS400CmdConnection.connectService(AS400.COMMAND);
} catch (Exception e) {
out.println(e.getMessage());
e.printStackTrace(out);
}
return (OS400CmdConnection);
}
Page 24
Summary
The IBM approach
– Enterprise Identity Mapping (EIM) for
authorization
– Kerberos or Identity Tokens for
authentication
Kerberos for Windows based applications
Identity Tokens for WAS based applications
Page 25
For More Information
Links can be found on www.triaworks.com
• Windows-based Single Signon and the
EIM Framework on the IBM eServer
iSeries Server Redbook
• Experts’ Guide to OS/400 & i5/OS Security
by Carol Woodbury and Patrick Botz
• http://www1.ibm.com/servers/eserver/security/eim/
• http://web.mit.edu/kerberos/
Page 26