Integration with CA Identity Manager

Contents
gm12602cr1
 
Contents
 
 
 
CA Identity Manager is an identity lifecycle management product that enables you to manage user identities and govern what they can access based on their role.
 
Identity Governance
 is an identity lifecycle management product that enables you to develop, maintain, and analyze role models. 
Identity Governance
 also provides centralized identity compliance policy controls and automates processes associated with meeting compliance demands.
When you integrate CA Identity Manager and 
Identity Governance
, you can do the following:
  • Validate that CA Identity Manager user privileges are granted in accordance with business compliance policies
  • Get suggested roles and compliance checking when creating or modifying CA Identity Manager users, roles, and accounts
  • Understand what roles exist in your organization, establish a role model that fits your organization, and re-create the desired role model within CA Identity Manager 
  • Analyze and maintain the role model as the business evolves
The following graphic details the architecture when you integrate 
Identity Governance
 and CA Identity Manager:
  Integrating CA Identity Governance with CA Identity Manager  
Use Case Certifying CA Identity Manager Provisioning Role Assignments
As an Administrator, you want to allow managers to review and certify the provisioning roles of CA Identity Manager users they manage.
Perform the following process to allow managers to perform user certifications.
  1. Integrate 
    Identity Governance
     with CA Identity Manager.
  2. Import data from CA Identity Manager to 
    Identity Governance
    .
    This procedure updates the Master and the Model configuration in 
    Identity Governance
    .
  3. Kick off a user certification to review and approve user provisioning role assignments (and direct permissions).
    This certification updates the 
    Identity Governance
     Model configuration.
  4. Once the certification is completed, export the differences generated by the certification. The changes are applied to CA Identity Manager directly.
    CA Identity Manager records these changes in the task persistence database, where they can be viewed in the View Submitted Tasks task.
After completing this process, role assignment data between 
Identity Governance
 and CA Identity Manager is synchronized and approved by CA Identity Manager user managers.
Use Case Maintaining Compliant CA Identity Manager Roles
As an Administrator, you want to be sure that when a new employee is added to CA Identity Manager, they automatically get privileges that are appropriate to their function within the company, and compliant with business policies.
Integrating with 
Identity Governance
 and enabling Smart Provisioning in an CA Identity Manager environment provides suggested roles and compliance checking when you create or modify users, roles, and accounts in CA Identity Manager.
For example, a new employee starts in the finance department at your company When you create the new user in CA Identity Manager, you specify that this person is part of the finance department. When you submit the Create User task in CA Identity Manager, 
Identity Governance
 returns a list of the following suggested roles for the new user:
  • FinanceApplicationUser—This role allows access to the financial application.
  • FinanceDept—This role gives general privileges to the new user that match other finance employees, such as an email account.
In addition, 
Identity Governance
 verifies that the existing privileges (if any) of the new user do not violate any business policy rules (BPRs).
Perform the following process to be sure that any new user added to CA Identity Manager gains the appropriate privileges that are compliant with company policy.
  1. Integrate CA Identity Manager and 
    Identity Governance
    .
  2. Import CA Identity Manager user, role, and account data to 
    Identity Governance
    .
    This procedure creates the Master and the Model configuration in 
    Identity Governance
    .
  3. Clean up the imported data in 
    Identity Governance
    .
    This procedure removes suspect entities and suspect relationships between entities and updates the Model configuration.
  4. Create Business Policy Rules (BPRs) in 
    Identity Governance
     that reflect business restrictions and limitations regarding user privileges.
  5. Run the BPRs created in Step 4 against the Model configuration.
  6. Export any changes made to the Model configuration during Step 5 back to CA Identity Manager.
    This step updates the Master also.
After completing this process, 
Identity Governance
 suggests roles and performs compliance checks against business policy restrictions and limitations when you create and modify users, roles, or accounts in CA Identity Manager. Any day-to-day changes made in CA Identity Manager that affect users, roles, or accounts are updated in 
Identity Governance
 using Continuous Update.
Associations Overview
Object in CA Identity Manager compared to objects in 
Identity Governance
 
When looking at 
Identity Governance
 and CA Identity Manager and how they handle linked objects, there are some differences. Because of these differences, we must map associations between the two systems so that both 
Identity Governance
 and CA Identity Manager understand the relationships between objects. In 
Identity Governance
, two objects are linked without dealing with how they are linked. In CA Identity Manager, two objects are linked through an attribute. For example, in 
Identity Governance
, an Active Directory account and a resource that represents a group can be linked. In CA Identity Manager, the account is connected to the group through an attribute named "groupMembership". Without telling CA Identity Manager which attribute to use, you cannot connect the group to the account.
  • The Issue
    When mapping associations (which become links in 
    Identity Governance
    ) you must reduce the definition of the link from containing three values (from what object, to what object, and through which attribute) to only two values (from which object to which object). This reduction happens during import from CA Identity Manager to 
    Identity Governance
    , but an issue arises when building the three-value definition out of two values when exporting back to CA Identity Manager. Once you map an association, you provide both the attribute and the object names in CA Identity Manager. When you export a link, the connector then knows which resource is linked to the account. All three values are now available for 
    Identity Governance
     to export.
    Once mapped, the 
    Identity Governance
     resource refers to both the mapped object (AD group) and the attribute (groupMembership). If an account can be connected to the same object by different attributes, the account must be defined as multiple resources in 
    Identity Governance
    . Each resource then represents an object linked by a specific attribute. These multiple resource definitions allow the export to identify which attribute the user referred to when connecting a resource to the account.
     A resource with no association is not understood between the two systems.
  • Example
    For example, Unix has an account connected to Unix groups using either the "primary group" attribute or the "group membership" attribute. If there is only one resource in 
    Identity Governance
     named "Unix group" when it is mapped to an account, 
    Identity Governance
     does not know whether to use the primary group or the group membership attribute when exporting to CA Identity Manager. Therefore, you map two associations, each to a different resource. For example, if the Unix endpoint has group "A", then you map two resources, one representing "A", "primary group" and the other representing "A", "group membership". Then 
    Identity Governance
     reads the associations and understands which attribute was referred to when it exports the data.
  • Working with Associations
    After defining how endpoint objects are linked, you map them to 
    Identity Governance
     objects by giving names to the 
    Identity Governance
     roles and resources. Initially, an object on the endpoint is marked as a resource and 
    Identity Governance
     offers to name the resource using the name of the object. After an object is mapped to a resource, if that object is used in other associations, the existing resource or role definition must be used. However, if you have more than one association between two exact objects linked by different attributes, you cannot use the same resource or role definition for both associations, and the endpoint object must be mapped to a new resource or role in 
    Identity Governance
    .
    Because each resource is mapped to an object on the endpoint, attributes can be mapped from the endpoint object to the resource. For example, a resource representing an AD group can have an attribute containing the group description. This option is not currently applicable to roles, as they cannot have custom attributes in 
    Identity Governance
    .
    Associations that do not start from an account are only possible in a
     deep
     use case. A deep use case is only available with the CA IAM Connector Server. If a deep use case is used, the mapping must have an account connected to a role and a role connected to a resource. The association between the account and the resource directly should also be defined, though not enforced.
  • Custom Association Attributes (Link Attributes)
    An association itself can have attributes in the form of link attributes. Link attributes define that the link between two objects has a risk, so there is a risk attribute with a value. For example, you have an association between an SAP account and a role. A role is an object that can be mapped to a resource. Different accounts can have the same role. However, each account is linked to the role for a restricted time period. The association itself has attributes that contain the start and end dates for the restricted time period.
Enrichment
During an import, you can merge supplementary Human Resources (HR) data or additional role and resource data with the existing users, roles, and resources databases.
For every field in the database that has a matching field in the enrichment file, 
Identity Governance
 updates the record in the database according to the enrichment setting in the file. This feature allows you to add data that does not exist in the endpoint that may be useful during certification. Also, extra data may be required for correlation in some cases.
A supplementary enrichment file must be in CSV file format.
When performing enrichment, select the attribute in both the database and the enrichment file that you want to use to match records. You can specify this match to be case-sensitive.
 An enrichment file record can match multiple database records, for example, matching the department field in the users database updates all the users in the same department.
The following options are available when performing enrichment during an import:
(Users and Resources only) Update fields that are different from enrichment file
Select this option to change the fields in the database if they differ from the enrichment file. Clear the option to keep the data in the database and add any deltas from the enrichment file.
  • Clear Fields that are empty in the enrichment file
    Select this option to delete data for a field if the corresponding entry in the enrichment file is blank. Clear the option to disregard empty fields in the enrichment file and keep the existing content in the database.