Web single-sign-on with iChain and Novell Access Manager
Download
Report
Transcript Web single-sign-on with iChain and Novell Access Manager
Web Single-Sign-On with Novell
iChain and Novell Access
Manager
E. Axel Larsson ([email protected])
Enterprise Integration Specialist
Drew University
TTP Summer Conference 2007
Agenda
iChain and Access Manager fundamentals
What are iChain and Access Manager
How does web-SSO relate to IDM
Networking Considerations
Access Control, Form-Fill, and Identity Injection
Troubleshooting Tools and Tips
Advanced Functionality
A few SSSO-enabled apps at Drew
Ad-Astra Portal
Adobe Connect
(Macromedia Breeze)
Aptron CampusWeb
Blackboard 6
Ektron Content
Management
EZProxy
GWGuardian Web
Quarantine
GroupWise WebAccess
GroupWise Mobile
NetStorage
SIRSI Web2 Library
Web Catalog
SupportWorks
Helpdesk Self-Service
vBulletin Forums
Fundamentals
What is iChain? What is Access Manager?
Networking Considerations
Access Control Policies
Basic Form-Fill
Basic Identity Injection (OLAC)
What is iChain?
Reverse proxy based SSO soft-appliance
Sits in front of web servers
Authenticates clients and applies access control policies
Authenticates clients to backend web servers on the behalf
of users.
Two principle facilities for providing single-sign-on
Form-Fill
OLAC - Object Level Access Control (now called Identity
Injection in AM3)
Non-invasive integration
What does Access Manager add?
Unified administration console
Identity Server
Federation
iManager-based
Manage configuration for proxy appliances, identity
servers, policies, etc. from one place
SAML 1.1, SAML 2, and Liberty Alliance
SSL VPN
J2EE Agents
Access Gateway appliance is the direct replacement
for the iChain appliance
How does Web-SSO relate to
Identity Management?
Enterprise Identity Management system
Sits in between applications and authoritative data
sources.
Provisions security principals in backend directory
services, applications’ local data stores
Based upon entitlements which correspond with
organizational roles or established workflows.
Web Single-Sign-On system
Sits in between users and web applications.
Provides credentials or assertions to apps on behalf of
the user
For user convenience and/or to enforce a security
policy.
Networking Considerations
AuthN/AuthZ for your web apps are delegated to the
Access Gateway proxy
Web servers trust injected identity information provided by
the Access Gateway
Clients should not have direct access to backend web
servers.
Web servers should be placed in a private network behind
the Access Gateway
Fault tolerance for the Access Gateway will require
use of an L4 switch (load balancer)
Collaboration with your networking team is
essential for a successful Web-SSO deployment!
At Drew
Public Resource (I.e. www.drew.edu)
iChain 1
Load Balancer
(Zeus ZXTM)
iChain 2
Post-iChain load balancer resource
Web Server
Web Server
Web Server
Private Post-iChain VLANs
Authentication and Access Policies
Protected resources defined by URL path:
iChain – three levels
i.e. www.drew.edu/secret-stuff/*
Public – Allows anonymous access
Restricted – Requires any authenticated user
Secure – Uses ACLs (static or dynamic membership) to
determine access
Access Manager adds
Identity server roles – Based upon a number of criteria.
LDAP attributes, Liberty profile fields, client IP address,
time of day, etc.
ACL policies for SSO applications
Blanket approach
Protected resource for the entire site:
i.e. webmail.drew.edu/*
Require auth for all access
Surgical approach
Trust the application’s session management
Application may offer differentiated content for anonymous
and authenticated users
Only protected the login “endpoint” (either a page with a
login form, or basic auth)
Example:
Spam.drew.edu/* -- Public
Spam.drew.edu/Quarantine/login.aspx -- Restricted
The basics of Form Fill
Non-invasive integration method
Fills out login forms on behalf of user
Form matching criteria
URL
Text on page
Form filling
Done client-side, form HTML is substituted with JavaScript
generated by the appliance
User’s login credentials
LDAP attributes
Can pass embedded JavaScript back to client
Identity Injection (Called OLAC in
iChain)
Injects identity information into HTTP requests
Useful for
HTTP Authorization header (HTTP Basic Auth)
Arbitrary HTTP Headers or query string (GET parameters)
Applications that support basic auth
Applications designed for SSO integration (look for header
based SSO in the docs)
Home-grown apps designed only for deployment behind
the access gateway
Protects against client request forgeries.
Appliance scrubs client HTTP requests of all headers used
in an injection policy.
When things go wrong…
Troubleshooting tools
Firefox
Interception proxy
Burp Proxy – portswigger.net/proxy
Test scripts
Web-developer’s toolbar
Tamper data extension
On the web server – to print out request variables and
compare with expected
Traffic analysis
On the Access Gateway appliance (tcpdump or pktscan) to
capture traffic
On the client – Wireshark
Cool value add: Path-based multihoming
Allows you to stitch together multiple
applications under a single URL namespace
Example setup at Drew:
http://www.drew.edu/*
http://www.drew.edu/admblog/*
An ASP.NET based content management system
running under IIS 6 on Windows Server 2003
A Drupal based blog running under Apache on a SLES 9
server
http://www.drew.edu/qfsearch/*
The Novell QuickFinder engine running on NetWare
Questions?
E. Axel Larsson
Enterprise Integration Specialist
Drew University
[email protected]