1 / 16

Deploying Tivoli Access Manager with an Identity Management System

Deploying Tivoli Access Manager with an Identity Management System. Prepared by Sridhar Muppidi, Sr. Security Architect Delivered by Ivan Milman imilman@us.ibm.com. Agenda. Touch Points between Access Manager and Identity Management System TIM-TAM Integration Architecture

rianne
Download Presentation

Deploying Tivoli Access Manager with an Identity Management System

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. Deploying Tivoli Access Manager with an Identity Management System Prepared by Sridhar Muppidi, Sr. Security Architect Delivered by Ivan Milman imilman@us.ibm.com

  2. Agenda • Touch Points between Access Manager and Identity Management System • TIM-TAM Integration Architecture • Case Study – On request of Audience • Integrated Identity Management Architecture

  3. Touch Points between Access Manager and Identity Management System (IDMS) • Authentication and Session Management • SSO and Authentication • Session Management • Single Sign-Off • Common User Registry • TAM Authorization to ID Management System • TAM User & Policy Management by ID Management System

  4. SSO to Identity Management System • Classic TAM application integration • Basic Auth, Forms, Web Trust, LTPA, TAI, etc. • Web Trust is the suggested approach (in all cases!) • WebSEAL would authenticate the user and pass a trust assertion over the HTTP header • The IM component will accept this assertion, trust it and build it’s own security context. • Using Access Manager Authentication gives IDMS System Advanced Authentication capabilities • Desktop based SSO to TAM means Desktop SSO to IDMS • Switch User - Useful for Administrators to see a specific user’s view • Step-up Authentication - Allows sensitive resources to require stronger authentication • Authentication Policy • “n” Strikes on Login, with Account Lockout for “m” minutes (or until reset) • Password Expiry and Account Expiration

  5. Session Management • Typically, TAM and IDMS maintain separate sessions with the user (browser) • Session state is left lying around when using independent session management in an integrated environment • One solution is to call an IDMS logout servlet at TAM logout • Another solution is to clean up the cookies on the browser • IDMS should be able to leverage TAM session management • do not need to set separate session cookies at the browser

  6. Single Sign-Off • Sign-off from Access Manager • Need to clean up the IDMS session • Modify Access Manager’s logout.html to call a logout servlet • Modify Access Manager’s logout.html to clean up the cookies • Sign-off from IDMS • Use Access Manager logout from the application • Determine the hostname of Access Manager (WebSEAL) • Post to /pkmslogout • All WebSEAL sessions for a user can be terminated via API or CLI

  7. Common User Registry • Many IDMS use LDAP as a user repository. • Sharing this LDAP between TAM and IDMS can be problematic • Access Patterns • TAM use of LDAP is primarily for read access • IDMS use of LDAP is a mix of read and write • Schema Modifications • Both TAM and IDMS extend the schema • Customer specific extensions (e.g. MyCompanyPerson auxiliary class) • Directory Information Tree • Both TAM and IDMS have a private space • store policy information • User and Group space • Company specific attributes • Since they are logically separate, it is recommended to leverage two physical directory servers if possible. • Performance, Scalability and Security reasons. • In any case, tuning is VERY critical for good performance and availability

  8. Authorization • Access Manager provides a rich set of features for URL level access control • Static content hosted on IDMS servers can easily be protected • Ability to add servlet contexts and other dynamic URL components to address space to allow security policy to be attached and enforced • Also web apps for self care • Dynamic rules can be used to validate the parameters passed to servlets • Typically, fine grained authorization within IDMS is proprietary and complex • So, integration with TAM is not appropriate at this level

  9. User and Group Management • Typical IDMS User Management Features Applicable to TAM • User self care functions • self-registration, self-help (forget pwd), change pwd web apps • Driven by IDMS APIs • These web apps can be placed behind TAM • Integrated on TAM logon page (must be unauth) • TAM password exits can forward changes to IDMSfor enforcement of pwd rules and for pwd sync • User account/resource management • Provisioning of users to TAM (using TAM API) • May combine with provisioning of additional LDAP attributes • Accommodate TAM schema changes across releases • Policies for Password, Provisioning, Identity, etc (pwd sync) • Delegation of user management, Help desk functions

  10. Policy Integration between TAM and IDMS • General Model • User --> Role  Permission -> Resource • Use Access Manager for Authorization Policy Management • Supports ACLs, Protected Object Polices (and Business Rules) to define policy • Enforces policies for web resources • For J2EE, does user/group to Role mapping • Use IDMS for binding users to roles (groups)

  11. TIM-TAM Integration Architecture

  12. TIM-TAM Integration Features • Single Sign-On • Single Sign-Off • Password Management • Password Strength and Password Synchronization • Self-Registration • Validation • Self-Help • Subscription Mgmt. • Application Provisioning • Attributes, Group Membership, GSO Lockbok • Delegated Administration • Integrated use of LDAP

  13. TIM/TAM SSO/Session Management/Logoff • TIM uses Web Trust • Servlet on TIM server parses IV-USER HTTP Header • TIM documentation describes how to install and run servlet • In future will use TAI • TAM and TIM have independent session management • TAM can pass the TIM session cookie • For session termination, the cleanest way is to either exit the browser or clean up the TIM cookies on the browser. • Single Logoff With Tivoli Identity Managerand TAM • Clean up TIM cookies from TAM logout.html • Modify the signoff.jsp page (in TIM) to redirect to TAM logout

  14. TAM and TIM use of Directory Server • Logically, both of the use separate schemas and DITs so can be on one physical directory server. • Smaller set of directory servers to manage • Need to leverage load balanced directory servers for performance and scalability • However we recommend separate directory servers if possible. • Better tuning capability – so better performance • More hardware but better scalability, performance & security

  15. Authorization and Management Integration • Authorization within Tivoli Identity Manager • It can take advantage of TAM URL level authorization • For fine grained authorization, TIM has a ACI model which is completely independent of TAM • TIM can provision to TAM via TAM agent • Today LDAP attributes can be provisioned by linking to LDAP service in TIM • Future – Group Discussion • TIM password policy can be enforced by plugin to WebSEAL password change/password policy exits • Libraries available with ITIM 4.5.1 • ITIM Self help/sef-reg servlets examples also shipped with ITIM 4.5.1 and can be integrated behind TAM

  16. The Big Picture and Questions

More Related