Web single sign on with ichain and novell access manager
Download
1 / 29

Web Single-Sign-On with iChain and Novell Access Manager - PowerPoint PPT Presentation


  • 951 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Web Single-Sign-On with iChain and Novell Access Manager' - ryanadan


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Web single sign on with ichain and novell access manager l.jpg

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

E. Axel Larsson

Drew University

[email protected]

TTP EMEA Conference 2007


Agenda l.jpg
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 l.jpg
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 l.jpg
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 l.jpg

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

A few applications


Fundamentals l.jpg
Fundamentals

  • What is iChain? What is Access Manager?

  • Networking Considerations

  • Access Control Policies

  • Basic Form-Fill

  • Basic Identity Injection (OLAC)


What is ichain l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
iChain networking at Drew

Load Balancer

(Zeus ZXTM)

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

iChain 1

iChain 2

Post-iChain load balancer resource

Web Server

Web Server

Web Server

Private Post-iChain VLANs


Authentication and access policies l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 control24 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 communication28 l.jpg
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.


Slide29 l.jpg

  • Questions?

  • E. Axel LarssonDrew [email protected]


ad