In Direct Associations, references are persisted directly into a multivalued attribute on the endpoint. For example, in LDAP, a group's member attribute directly stores reference to the accounts it contains. Metadata of the following represents the group's member attribute:
<property name="eTDYNMember"> <doc>LDAP member [DN]</doc> <value> <setValue> <baseType> <flexiStrValue type="DN" /> </baseType> </setValue> </value> <metadata name="beanPropertyName"> <value> <strValue>member</strValue> </value> </metadata> <metadata name="isMultiValued"> <value> <boolValue>true</boolValue> </value> </metadata> <metadata name="connectorMapToAmbiguous"> <value> <sequenceValue> <baseType> <strValue /> </baseType> <val> <strValue> groupOfUniqueNames:uniqueMember </strValue> </val> <val> <strValue>groupOfNames:member</strValue> </val> </sequenceValue> </value> </metadata> <metadata name="refObjectType"> <value> <strValue>eTDYNAccount</strValue> </value> </metadata> <metadata name="isDNAbsolute"> <value> <boolValue>false</boolValue> </value> </metadata> <metadata name="DNLdapObjectClass"> <value> <strValue>eTDYNAccount</strValue> </value> </metadata>
Note: For more information about the various metadata settings, see the CA IAM CS Javadoc for the constants in MetaDataDefs.java matching each metadata property's name.
If a single associative attribute can contain references to multiple objectclasses, then the "DNLdapObjectClasses" attribute should be used instead of "DNLdapObjectClass". In either case the assocRefObjectClass setting is required and needs to have the same value (or any one of the values) of the DNLdapObjectClass(es) setting.
In the Direct case it is often useful to also define a virtual attribute (so called because it is calculated on the fly at possibly considerable runtime cost) which can pass back information about the association in the reverse direction. For instance the eTDYNMemberOf for an account returns the list of groups to which each account belongs calculated entirely from the group.member attribute discussed above. Its metadata would be defined as follows:
<property name="eTDYNMemberOf"> <doc>LDAP memberOf [DN]*</doc> <value> <setValue> <baseType> <flexiStrValue type="DN" /> </baseType> </setValue> </value> <metadata name="beanPropertyName"> <value> <strValue>groupNames</strValue> </value> </metadata> <metadata name="isMultiValued"> <value> <boolValue>true</boolValue> </value> </metadata> <metadata name="connectorMapTo"> <value> <strValue>memberOf</strValue> </value> </metadata> <metadata name="virtual"> <value> <boolValue>true</boolValue> </value> </metadata> <metadata name="forceModificationMode"> <value> <strValue>DELTA</strValue> </value> </metadata> <metadata name="assocRefObjectClass"> <value> <strValue>eTDYNGroup</strValue> </value> </metadata> <metadata name="assocAttr"> <value> <strValue>eTDYNMember</strValue> </value> </metadata> <metadata name="isDNAbsolute"> <value> <boolValue>false</boolValue> </value> </metadata> <metadata name="DNLdapObjectClass"> <value> <strValue>eTDYNGroup</strValue> </value> </metadata> </property>
In cases where the metadata values are similar to the member case, except that the forceModificationMode=DELTA setting, modifications are always expressed as a set of additions and deletions, easing the process of updating the various group.members list internally.
Copyright © 2013 CA.
All rights reserved.
|
|