When looking at CA GovernanceMinder and CA IdentityMinder 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 CA GovernanceMinder and CA IdentityMinder understand the relationships between objects. In CA GovernanceMinder, two objects are linked without dealing with how they are linked. In CA IdentityMinder, two objects are linked through an attribute. For example, in CA GovernanceMinder, an Active Directory account and a resource that represents a group can be linked. In CA IdentityMinder, the account is connected to the group through an attribute named "groupMembership". Without telling CA IdentityMinder which attribute to use, you cannot connect the group to the account.
When mapping associations (which become links in CA GovernanceMinder) 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 IdentityMinder to CA GovernanceMinder, but an issue arises when building the three-value definition out of two values when exporting back to CA IdentityMinder. Once you map an association, you provide both the attribute and the object names in CA IdentityMinder. When you export a link, the connector then knows which resource is linked to the account. All three values are now available for CA GovernanceMinder to export.
Once mapped, the CA GovernanceMinder 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 CA GovernanceMinder. 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.
Note: A resource with no association is not understood between the two systems.
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 CA GovernanceMinder named "Unix group" when it is mapped to an account, CA GovernanceMinder does not know whether to use the primary group or the group membership attribute when exporting to CA IdentityMinder. 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 CA GovernanceMinder reads the associations and understands which attribute was referred to when it exports the data.
After defining how endpoint objects are linked, you map them to CA GovernanceMinder objects by giving names to the CA GovernanceMinder roles and resources. Initially, an object on the endpoint is marked as a resource and CA GovernanceMinder 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 CA GovernanceMinder.
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 CA GovernanceMinder.
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.
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.
|
Copyright © 2014 CA.
All rights reserved.
|
|