web single sign on with ichain and novell access manager l.
Skip this Video
Loading SlideShow in 5 Seconds..
Web Single-Sign-On with iChain and Novell Access Manager PowerPoint Presentation
Download Presentation
Web Single-Sign-On with iChain and Novell Access Manager

Loading in 2 Seconds...

play fullscreen
1 / 29

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

  • Uploaded on

Web Single-Sign-On with iChain and Novell Access Manager. E. Axel Larsson Drew University elarsson@drew.edu 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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
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

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

E. Axel Larsson

Drew University


TTP EMEA Conference 2007

  • 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
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
  • 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


GWGuardian Web Quarantine

GroupWise WebAccess

GroupWise Mobile


SIRSI Web2 Library Web Catalog

SupportWorks Helpdesk Self-Service

vBulletin Forums

A few applications
  • What is iChain? What is Access Manager?
  • Networking Considerations
  • Access Control Policies
  • Basic Form-Fill
  • Basic Identity Injection (OLAC)
what is ichain
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
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
  • J2EE Agents
  • Access Gateway appliance is the direct replacement for the iChain appliance
networking considerations
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
out of band communication
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
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.
  • E. Axel LarssonDrew Universityelarsson@drew.edu