1 / 29

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

tori
Download Presentation

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

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Single-Sign-On with iChain and Novell Access Manager E. Axel Larsson Drew University elarsson@drew.edu TTP EMEA Conference 2007

  2. 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

  3. 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

  4. 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

  5. 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

  6. Fundamentals • What is iChain? What is Access Manager? • Networking Considerations • Access Control Policies • Basic Form-Fill • Basic Identity Injection (OLAC)

  7. 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)

  8. 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

  9. 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

  10. 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

  11. 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.

  12. 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

  13. 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

  14. 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

  15. 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

  16. Advanced Functionality • Integrating login and logout with your applications • Embedded login forms • Single logout • Seamlessly integrating multiple applications with path-based multihoming

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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.

  22. 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.

  23. 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.

  24. 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

  25. 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

  26. 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.

  27. Questions? • E. Axel LarssonDrew Universityelarsson@drew.edu

More Related