160 likes | 443 Views
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
E N D
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 • Case Study – On request of Audience • Integrated Identity Management Architecture
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
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
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
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
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
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
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
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)
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
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
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
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