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

1. Web Single-Sign-On with Novell iChain and Novell Access Manager E. Axel Larsson (elarsson@drew.edu) Enterprise Integration Specialist Drew University TTP Summer Conference 2007

2. Agenda • iChain and Access Manager fundamentals • What are iChain and Access Manager • How does web-SSO relate to IDM • Networking Considerations • Access Control, Form-Fill, and Identity Injection • Troubleshooting Tools and Tips • Advanced Functionality

3. 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 SSSO-enabled apps at Drew

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

5. 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) • Non-invasive integration

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

7. How does Web-SSO relate toIdentity Management? • Enterprise Identity Management system • Sits in between applications and authoritative data sources. • Provisions security principals in backend directory services, applications’ local data stores • Based upon entitlements which correspond with organizational roles or established workflows. • Web Single-Sign-On system • Sits in between users and web applications. • Provides credentials or assertions to apps on behalf of the user • For user convenience and/orto enforce a security policy.

8. 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) • Collaboration with your networking team is essential for a successful Web-SSO deployment!

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

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

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

12. 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 • HTTP Authorization header (HTTP Basic Auth) • Arbitrary HTTP Headers or 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 • Protects against client request forgeries. • Appliance scrubs client HTTP requests of all headers used in an injection policy.

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

17. Cool value add: 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

18. Questions? • E. Axel LarssonEnterprise Integration SpecialistDrew Universityelarsson@drew.edu