Applications

Imagination
To
Realization
Options for Single Sign On
Presented by: Vishal Goenka, Advisory Architect,
Technology Strategy, SunGard Higher Education
Tuesday, April 4, 2006
1:30 – 2:30 pm
Evaluation Code 140
April 2-5 Orlando, Florida
Session Rules of Etiquette
ƒ Please turn off your cell phone/pager
ƒ If you must leave the session early, please do so as
discreetly as possible
ƒ Please avoid side conversation during the session
Thank you for your cooperation!
Evaluation Code 140
2
Session Objective
ƒ Understanding the 3 dimensions of Single Sign on
ƒ Recognizing the key aspects for any SSO
implementation
ƒ Using ‘Right Tool for the Job’ – asking the right
questions
ƒ Overview of Luminis SSO protocol suite
ƒ Examples of current SSO implementations across
SunGard Higher Education solutions
Evaluation Code 140
3
The 3-Dimensions of Single Sign On
ti
a
r
t
inis
• Not having to re-enter passwords
Experience
Enhanced User
• Seamless access to applications
on
dm
alls ng
c
A
f
sk ioni
o
e
se
p d rovis
l
a
e
E
e h ser p
c
du e u
e
• R educ d
• R rhea
e
ov
Secure Access
• Fewer passwords to remember/change
• One “strong” password vs. many
“weak” ones
Evaluation Code 140
4
Imagination
To
Realization
Enhance User Experience
• Seamless access to applications
• Not having to re-enter passwords
April 2-5 Orlando, Florida
Users Experience Web via Enterprise Portal
Evaluation Code 140
6
Users Directly Access Enterprise Resources
Evaluation Code 140
7
Some Resources Are Linked With Another
Evaluation Code 140
8
How Do Users Experience Web @ EDU?
All (most) web applications are
accessed via an Enterprise Portal
All (most) web applications are
accessed directly in no specified
order
Some web applications are
accessed by traversing links or
actions in another application
Evaluation Code 140
9
Application Access via Enterprise Portal
Access
Login (User)
Portal Activity
Logout
Portal
Render Portlet
Get “Portlet”
Keep Session Alive
Application
Login as User
Logout User
Evaluation Code 140
10
Direct Application Access w/ Web SSO
Get Content (Not Authenticated)
Redirect to Web AuthN Server
Get Token
(App1)
Login (User)
Token (App1)
Validate Token = User
ion)
Application Content (App1 Sess
Logout (User)
Web AuthN
(Optional) Logout
Application
Get Content w/ Token (App1)
Logout (User)
Evaluation Code 140
11
Application to Application Single Sign On
Login (User)
Interact w/ App #1
Click on App
#2 Link
p p#2
A
o
t
t
c
e
ir
d
Re
Login as User
Interact w/ App #2 (App #2 links session)
App #1 Activity
Keep Session Alive
App #2
App #1
Logout
Logout User
Evaluation Code 140
12
Summary - SSO With Different Interactions
Get Content (No Auth Token)
Redirect to WebISO for AuthN
Access
Get Token
(A
Login (User)
pp1)
Login (User)
Token (App1)
Login as User
Keep Session Alive
Get Content w/ Token (App1)
Validate Token = User
)
Application Content (App1 Session
Logout (User)
Logout User
Web ISO
(Optional) Logout
Application
Logout
Get “Portlet”
Application
Portal Activity
Portal
Render Portlet
Logout (User)
Login (User)
Interact w/ App #1
Click on App
#2
Link
#2
p
p
A
to
Redirect
Login as User
Interact w/ App #2 (App #2 links session)
App #1 Activity
Keep Session Alive
App #2
App #1
Logout
Logout User
Evaluation Code 140
13
Imagination
To
Realization
Secure Access
ƒ
ƒ
Fewer passwords to remember/change
One “strong” password vs. many “weak” ones
April 2-5 Orlando, Florida
User Security – Is it all about Passwords?
ƒ User Security is a key motivation for Single Sign On
ƒ Fewer Passwords are “Easier” to remember and can
be made to be H@rd_2_Gu3ss
ƒ Requiring too many passwords prompts user to use
simple to remember passwords [myEmail1,
myShell4]
ƒ The difference between “One” password versus
“Same” password is important and affects how users
change/manage passwords
Evaluation Code 140
15
Using Different Passwords
Sync
ƒ All web applications use different passwords
ƒ Passwords may be synchronized to appear same
ƒ Or an application knows the users passwords for other
applications to enable SSO experience via direct linking
Evaluation Code 140
16
The Perils of Keeping Someone’s Secrets
ƒ Secret Store allows seamless Single Sign On across
systems with distinct credentials, however:
ƒ Raises security concerns about how the secrets are protected.
ƒ Should Admin of “SecretStore” be able to see each user’s
passwords to all enterprise apps that are SSO enabled?
ƒ How are the secrets “provisioned”?
ƒ How are they “seamlessly” updated?
ƒ What if the Secret Store is compromised?
ƒ Use Secret Store only as a “Stop Gap” against legacy
solutions, not a preferred SSO strategy
Sync
Evaluation Code 140
17
One Password
ƒ All web applications use “One” password by referencing an
AuthN Server
ƒ Applications “ask for user’s password” and validate against an
Enterprise Directory (LDAP)
ƒ SSO is possible since any application can replay cached
passwords to authenticate the user to another application
Evaluation Code 140
18
Why LDAP Alone Doesn’t Address SSO?
ƒ Directory Lookup to validate password allows all applications
to use the same password
ƒ It obviates the need for a Secret Store (and all its perils)
ƒ However, each application now gets to “see” the password
and cache it (heard of a leaky cache?)
ƒ Passwords may also be exposed on the network (admit it, all
apps are NOT SSL enabled …)
ƒ Therefore, we need a way to Single Sign On without giving
passwords out to each application
Evaluation Code 140
19
Applications Don’t See Passwords!
issue
verify
issue
verify
ƒ Web applications don’t ask for passwords
ƒ Instead use opaque “Tokens” or “Assertions” issued by a
“trusted” issuer (Authentication Server)
ƒ SSO is feasible in “Direct Access” mode. Each application
redirects to AuthN Server, which asks for login credentials
once during a session
Evaluation Code 140
20
If You Say So, Mr. Authenticator!
ƒ Applications need to “trust” a service (Aha, SOA!) that issues
and validates “authentication tokens”
ƒ User authenticates to a Web AuthN Server
ƒ When user needs to access an application, Web AuthN
Server issues an assertion/token that is presented to the
application
ƒ Application validates the assertion/token to know the user’s
identity
ƒ Assertions are either “digitally signed”, Tokens are opaque,
both have short life times and restricted use
issue
verify
issue
verify
Evaluation Code 140
21
How are Passwords Managed @ EDU?
All (most) web applications use
separate passwords (perhaps
synchronized to appear same)
Sync
All (most) web applications use
“One” password by referencing an
AuthN Server (LDAP, Kerberos, …)
issue
Some web applications don’t use
Passwords. Instead use opaque
“Tokens” or “Assertions”
verify
issue
verify
Evaluation Code 140
22
Imagination
To
Realization
Ease of User Administration
• Reduce Help Desk calls
• Reduce provisioning overhead
April 2-5 Orlando, Florida
User Administration (a.k.a. Provisioning)
Enterprise Portal
(Luminis Portal)
Student System
(Banner Student)
Message Queue
(Luminis Message Broker)
Directory Lookup
Workflow
Library System
e-Learning
Evaluation Code 140
24
User Administration – Key Questions
ƒ Is a user’s login-id “unique” across all enterprise
applications?
ƒ Do different systems have “potentially” different
passwords?
ƒ How is password change handled across all
systems; self-service as well as administrative
reset?
Evaluation Code 140
25
Single Sign On – Identity Mapping
sid: 13456
Email: [email protected]
uid: jdoe
SIS
13456
Workflow
13456
Library
21105
E-Learning
jdoe
Enterprise Portal
Student System
(e.g., Luminis Portal)
(e.g., Banner Student)
uid: jdoe
John Doe
uid: 13456
Directory Lookup
uid: 21105
uid: jdoe
SIS
13456
LDAP
jdoe
Workflow
Library System
e-Learning
Evaluation Code 140
26
User Administration – Key Observations
ƒ Identity mapping isn’t fun, but that is the reality
ƒ Until applications can all agree on a common,
externally generated user identifier, SSO efforts will
be plagued by creating and maintaining user-id
mappings
ƒ In lieu of externalization of user identifier (uid) or
external (perhaps LDAP) lookup for application
specific uid, enterprise web SSO will be reduced to
many point-to-point SSO connections
Evaluation Code 140
27
Imagination
To
Realization
Lets talk specifics …
• Now that we have discussed “concepts”
• How they apply to SunGard HE solutions
April 2-5 Orlando, Florida
SSO Protocol Summary (as of Luminis Platform IV)
ƒ CPIP – Campus Pipeline Integration Protocol
ƒ Server to Server Authentication with “session-handoff” to the
browser
ƒ Allows session management (coordinated session timeout) and
single logout
ƒ Allows on-the-fly user provisioning to target system
ƒ Requires “Programming” the application adapter
ƒ CPIP Generic Connector
ƒ Think of it as a generic application adapter, out-of-the-box, which
can be configured as opposed to programming
ƒ CAS – Open Source WebISO implementation that supports
trust based authentication, proxy authN
Evaluation Code 140
29
The Matrix: User Experience & Password
Management
Different Credentials
One/Same
Credential
Token or Assertion
Access via
Enterprise
Portal
A “Secret Store” contains
users’ credentials for various
systems. Portal can access
Secret Store to proxy
authenticate
Portal caches user’s login
credentials and replays
them to proxy authenticate.
No permanent credential
storage
Portal obtains proxy
authentication “token” or
assertion from issuer for
each application at the time
of access
Direct
Access w/
Web AuthN
Gateway
As above, except that AuthN
Gateway must now perform
proxy authentication
As above, except that
AuthN Gateway must now
perform proxy
authentication using cached
credentials
Standard usage with
WebISO based AuthN
Gateways. WebISO itself
issues “tokens”, no need for
proxy tokens
App to App
link/launch
Uni-directional link setup for
each pair of applications by
“manual” provisioning of
access to credentials for
another app
As above, except
Application caches
credentials and performs
proxy authentication
- NA (If token based AuthN is
used, it is no longer an app
to app link/launch)
Summary
Replay saved credentials
(“Secret Store”)
Replay cached credentials
Trusted third-party authN
Evaluation Code 140
30
The Matrix “Reloaded” (SunGard Higher Ed.)
Different
Credentials
One/Same
Credential
Token or
Assertion
Access via
Luminis Portal
CPIP (or Generic
Connector) w/ Pipeline
Secret Store. Provisioning
credentials and keeping
them in sync is out-ofband.
CPIP (or Generic
Connector) w/ “cptool sync
password” to use inmemory cached
credentials. No credential
provisioning/sync needed
Use CAS protocol and
set application to use
Luminis as CAS Server.
Luminis issues and
validates CAS tokens.
Direct Access
w/ Luminis as
Web AuthN
Gateway
Use CPIP. Application
MUST redirect to Luminis
with redirection parameter
set to CPIP URL. Out-ofband credential
provisioning and sync.
App to App
link/launch
CPIP and CAS (or other
“one-off” implementations)
◄ ‘+' ▲
◄
▲
If the application linked
to supports CAS, this
usage will be identical
to both scenarios above
Evaluation Code 140
31
Usage Examples in SunGard Higher Education
Access via
Luminis Portal
Direct Access w/
Web AuthN
Gateway
App to App
link/launch
CPIP (Generic
Connector) w/
Different
Credentials
CPIP (Generic
Connector) w/
Same Credential
CAS Token
Luminis Æ Banner Self
Service (6.x)
Luminis Æ WebCT
Luminis Æ Outlook (Web
Access)
Luminis Æ EDU apps
Luminis Æ Banner Self
Service (7.x)
Luminis Æ INB (6.x & 7.x)
Luminis Æ Workflow
Luminis Æ EDU apps
Luminis Æ Matrix
Luminis Æ EDU apps
-
Luminis Æ Banner
Channels
-
Workflow Æ INB
-
-
Evaluation Code 140
32
Summary of SunGard Higher Education SSO
Options
ƒ CPIP (Generic Connector) for “legacy applications that
require raw credentials”
ƒ CAS for “applications that can consume opaque tokens
from a trusted authority”
ƒ Both CPIP and CAS are published protocols that are easy to
wire to, but assume some out-of-band provisioning if user’s
id/passwords are different across applications
ƒ Some “proprietary” point-to-point SSO connections are
available between various applications, but generally not
as published protocols
Evaluation Code 140
33
When to Use CAS – Checklist
ƒ Application can use Luminis UserId and doesn’t directly need the
password
ƒ Login to Luminis is “politically” acceptable as “a gateway” to the
application
ƒ CAS is “technically” feasible if one of the following is true
ƒ Application controls (or can) the authentication code, and source is
available
ƒ Uses container-managed authentication & CAS module is available for
the container. For example:
ƒ Tomcat and most J2EE App Servers that allow pluggable
authentication (including JAAS modules)
ƒ Apache (mod-CAS is available)
ƒ IIS – CAS_Login.asp is available
ƒ Single Logout or Session Management is not currently critical
ƒ Although there are some ‘weak’ strategies that you can implement today
Evaluation Code 140
34
When to Use CPIP Generic Connector – Checklist
ƒ Application needs raw user-id and password
ƒ Application supports a feasible web authentication
mechanism such as HTML Form, HTTP BasicAuth that
can be “re-played” by Luminis without executing a clientside script (such as JavaScript)
ƒ Application doesn’t change authentication behavior
significantly based on browser-type
ƒ Coordinating session timeouts with Luminis is less
critical
ƒ Can kill session on server-side without resetting browser
cookie (a “weak” strategy is feasible otherwise)
Evaluation Code 140
35
When to Write Your CPIP Adapter – Checklist
ƒ Application can be changed to introduce a CPIP
connector to handle login, logout and session
management
ƒ Application needs raw user-id and password
ƒ Application needs coordinated session timeout, single
logout
ƒ You have resources to write and maintain “code”
ƒ Can kill session on server-side without resetting browser
cookie
Evaluation Code 140
36
Questions, surely you have some!
Vishal Goenka
[email protected]
Please complete the on-line Evaluation Form
Evaluation Code 140
Without limitation, SunGard, the SunGard logo, Banner, Campus Pipeline, Luminis, PowerCAMPUS, Matrix, and
Plus are trademarks or registered trademarks of SunGard Data Systems Inc. or its subsidiaries in the U.S. and
other countries. Third-party names and marks referenced herein are trademarks or registered trademarks of their
respective owners.
© 2006 SunGard. All rights reserved.
Evaluation Code 140
37