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

E. Axel LarssonDrew Universityelarsson@drew.eduTTP 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

Load Balancer(Zeus ZXTM)

Web Server Web Server Web Server

iChain 1 iChain 2

Public Resource (I.e. www.drew.edu)

Post-iChain load balancer resource

Private Post-iChain VLANs

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 - 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/*

An ASP.NET based content management system running under IIS 6 on Windows Server 2003

http://www.drew.edu/admblog/* 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: 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 LarssonDrew Universityelarsson@drew.edu