Transcript Web Single-Sign-On with iChain and Novell Access Manager

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.



2003-2007: iChain



Difficult to integrate non-open source or homegrown software.
Special proxy auth module developed to support NetMail
WebAccess.
Blackboard implementation demanded a more robust, noninvasive 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 singlesign-on


Form-Fill
OLAC - Object Level Access Control (now called
Identity Injection in AM3)
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
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
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 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



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
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 - http://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:

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
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: nocache (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 formfill 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]