Web Single-Sign-On with iChain and Novell Access Manager
E. Axel Larsson
Drew University
[email protected]
TTP EMEA Conference 2007
Agenda
A history of Web SSO at Drew
iChain and Access Manager fundamentals
What is iChain? What is Access Manager?
Networking Considerations
Access Control, Form-Fill, and Identity Injection
Troubleshooting Tools and Tips
Advanced Functionality
Customizing login and logout
Leveraging accelerator/reverse proxy features
A history of Web SSO at Drew
2000-2003: Session Manager
Apache/mod_perl module, Single auth server
Applications needed to be modified to support Session Manager authentication.
Difficult to integrate non-open source or homegrown software.
Special proxy auth module developed to support NetMail WebAccess.
2003-2007: iChain
Blackboard implementation demanded a more robust, non-invasive SSO solution
Significant expansion of third-party apps not under Drew’ s control – GroupWise, Macromedia Breeze, etc.
Migration to Access Manager
Ongoing, expected cutover summer 2007
Today
iChain 2.3
Two iChain appliances
Zeus ZXTM load balancer in front
Approximately 40 web applications
100% coverage for Drew end-user web applications
A few applications
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)
What does Access Manager add?
Unified administration console
iManager-based
Manage configuration for proxy appliances, identity servers, policies, etc. from one place
Identity Server
Federation
SAML 1.1, SAML 2, and Liberty Alliance
SSL VPN
J2EE Agents
Access Gateway appliance is the direct replacement for the iChain appliance
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)
Beware of NAT issues with Access Manager and L4 switches
iChain networking at Drew
Authentication and Access Policies
Protected resources defined by URL path:
i.e. www.drew.edu/secret-stuff/*
iChain -three levels
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
Done client-side, form HTML is substituted with JavaScript generated by the appliance
Form matching criteria
URL
Text on page
Form filling
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 from the client
HTTP Authorization header (HTTP Basic Auth)
Arbitrary HTTP Headers
Arbitrary query string (GET parameters)
Useful for
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
When things go wrong
Troubleshooting tools
Firefox
Web-developer’ s toolbar
Tamper data extension
Interception proxy
Burp Proxy -portswigger.net/proxy
Test scripts
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
Advanced Functionality
Integrating login and logout with your applications
Embedded login forms
Single logout
Seamlessly integrating multiple applications with path-based multihoming
Embedded login forms
Replace application login forms with Access Manager or iChain login forms
Provides a seamless experience for the user
Works well for applications that provide differentiated content to anonymous / authenticated users.
Conditional display of login form facilitated by identity injection. (ID injection works on public resources)
In form POST need:
Username
Password
URL of site to redirect to after successful login
Single logout
Replace application logout links with iChain/Access Manager logout links
Can also be a post-logout redirect for applications that support it.
iChain – site/cmd/ICSLogout
Access Manager – https://IdentityServer:Port/nidp/app/logout
Path-based multi-homing
Allows you to stitch together multiple applications under a single URL namespace
Example setup at Drew:
www.drew.edu/*
An ASP.NET based content management system running under IIS 6 on Windows Server 2003
www.drew.edu/admblog/*
A Drupal based blog running under Apache on a SLES 9 server
www.drew.edu/qfsearch/*
The Novell QuickFinder engine running on NetWare
Common Problems and Solutions: Four Scenarios
1 – Improper cache control headers
2 – Embedded JavaScript on login forms
3 – Loopback communication
4 – Out of band HTTP and non-HTTP access by clients
Improper cache control
Beware of applications that do not set proper cache control headers on their responses
Access Gateway is a caching reverse proxy
Results of improperly cached content can range from merely embarrassing to a serious security issue.
Remember, the AG doesn’ t cause the issue, but may make it apparent for the first time.
Improper cache control
How do we fix it?
Fix the application (ideal)
Cache-control: private (allow pages to be cached by the browser but not intermediate proxies)
Cache-control: no-cache, no-store and Pragma: no-cache (do not allow the page to be cached anywhere)
Access Gateway / iChain workarounds
Pin-list with the bypass option. Tells the AG what URL patterns may not be cached on the appliance.
Disable allow pages to be cached at browser . Inserts cache control headers in all returned pages.
JavaScript in login forms
Some applications use JavaScript embedded in their login forms to manipulate form vars before posting back to the server.
Example: Blackboard Basic Edition MD5 hashes the password in JavaScript in an onSubmit form method.
Workarounds
Form-fill policies work by returning custom JavaScript to the client that fills and then auto-submits the form.
Configure form-fill policy to allow JavaScript code to pass unaltered to the client. Configure onSubmit action in form-fill policy.
Loopback communication
Applications assume that server-side components can communicate with each other using the public DNS name of the web server.
I.e. Blackboard Basic Edition tries to connect to it’ s MS SQL database at blackboard.site.edu.
Won’ t work because public DNS names of the application point to the Access Gateway or L4 switch.
Some applications do not allow for configuration of this behavior either due to poor design or software license restrictions. (single server deployment only)
Workaround
HOSTS file entry on each backend web server pointing the public host name of the site at itself or 127.0.0.1
Out-of-band communication
Some web applications make use of external helper programs or applets
Applets may need to connect to other services running on non-standard ports on the application server.
Examples
Blackboard Virtual Classroom on port 8010
Breeze Meeting / Flash Communication Server on port 1935
What to do?
Can we get the applet to talk directly to some other address than the hostname of the web server (the AG box)?
No – The security model for Java and Flash applets restricts them to opening socket connections to the box from which they were downloaded.
Use Access Gateway tunnels to open up ports on the AG
Out-of-band communication
HTTP requests by external applets
Must contain an AG session cookie to be considered authenticated.
Not a problem if the request goes through the browser’ s HTTP client. I.e. if the applet is embedded on a web page.
If the app launches an external helper program (Example: Breeze Presenter’ s Plugin) it will not have access to the browser’ s cookies. AG will deny request.
Workarounds
Use an interception proxy to figure out what URLs that external application is requesting. Alter AG access control rules as needed.
If the URLs needed are many and varied, consider using a surgical access control policy instead of a blanket policy.
Questions?
E. Axel Larsson Drew University [email protected]