This feature maps existing or new directory entries that behave like groups to Vantage external roles. The directory is searched to establish a principal’s authorizations.
The <AuthSearch> element enables lightweight authorizations.
The configuration is added to TdgssUserConfigFile.xml and defines the search parameters needed to locate group-like entries in a directory server.
<AuthSearch
Ref="service-id"
Base="search-base"
Scope="{onelevel|subtree}"
MemberAttribute="member-attribute-name"
ObjectClass="object-class-name"
NamingAttribute="naming-attribute-name"
<AuthSearchMap Match="regex" Pattern="pattern"/>
/>...
<AuthSearch
<AuthSearchMap Match="manager" Pattern="admin"/>
< AuthSearchMap Match="socal" Pattern="tduser">
/>
</Mechanism>
Attributes
| Attribute | Description |
|---|---|
| Ref | This attribute names the <Service> that performs the search. The value in the Id attribute of <Service> must be provided. The same rules apply to the Ref attribute that apply to the Ref attribute in the <IdentitySearch> and <IdentityMap> elements. The search is performed in the service that identified the user. The same service associated with the canonicalization that generates the principal’s distinguished name (DN) will be searched for mappings. The Ref attribute is used only when the <AuthSearch> is placed inside the <Canonicalizations> area of the <LdapConfig> section. It is not used when <AuthSearch> is placed inside the <MechanismProperties> element. |
| Base | [Optional] If not provided, the value is taken from the mechanism or service LdapGroupBaseFQDN property. The value defines the location where the search is to start to locate the group-like entries that represent Vantage external roles. |
| Scope | [Optional] This attribute specifies the search scope. It takes the values, “onelevel” or “subtree,” with “subtree” being the default. |
| MemberAttribute | The values of the MemberAttribute and ObjectClass attribute are used to construct a search filter. The MemberAttribute attribute is optional. MemberAttribute names the attribute in the directory which contains the DN of the identified user. If the attribute is omitted, the value defaults to “member”. This attribute MUST use the distinguishedNameMatch equality matching rule and the 1.3.6.1.4.1.1466.115.121.1.12 (distinguished name) syntax rule. |
| ObjectClass | [Optional] The object class of the authorization entry and causes an ObjectClass term to be included in the search. If the attribute is omitted, no ObjectClass term is included in the search filter.
If you don't set the ObjectClass, the default sets memberAttribute to “member” and ObjectClass to “groupOfNames”. For Active Directory, ADAM, and AD LDS set ObjectClass to "group". If an object class name is present, the generated search filter is of the following form: (&(member-attribute-name=dn-of-principal)(objectClass=object-class-name)) If an object class name is not present, the generated search filter is of the form: (member-attribute-name=dn-of-principal) |
| NamingAttribute | [Optional] The attribute in the directory entry which contains the external role name. It is used to limit the returned attributes to this one attribute.
|
| AuthSearchMap | [Optional] Configure as many AuthSearchMap elements as necessary. The Match and Pattern attributes of <AuthSearchMap> are used to filter out unwanted group names.
|
Editing Guidelines
- To set a value, you must manually add this property to the TdgssUserConfigFile.xml on the mechanisms that require it. See Editing Configuration Files.
- Zero or more <AuthSearch> elements are placed in the <Canonicalizations> area of the <LdapConfig> section or as a child of the <MechanismProperties> element. In both cases, the <AuthSearch> is a sibling of <IdentitySearch> and <IdentityMap> elements.
- Like <IdentitySearch> and <IdentityMap>, as many <AuthSearch> elements as necessary may be placed in the configuration. These elements may appear anywhere in the appropriate sections. They can be placed before or after the <IdentitySearch> and <IdentityMap> elements or they can be interleaved with the <IdentitySearch> and <IdentityMap> elements.
- The LdapSystemFQDN attribute does not need to be populated in the configuration. If populated, it is ignored when <AuthSearch> is present.
- If UseLdapConfig="yes" for the mechanism, then the <LdapConfig> section of the configuration file should contain the <AuthSearch> entries. To use this feature a value for the LdapServiceFQDN and LdapServicePassword properties must be provided and user identities must be discovered using <IdentitySearch> and/or <IdentityMap> elements. The LdapServiceFQDN and password are used to do the canonicalization of the user. After canonicalization, but before Authentication, the authorization is retrieved using the service bind. All the authorization entries (roles) are added to a roles list. The roles list is returned after successful authentication. These roles are used for database logon.