Excerpt |
---|
The authentication at censhare via a directory service (LDAP/AP) requires a mapping of user attributes. When you use Single Sign-On (SSO) via Kerberos, a directory service and the respective attribute mapping is also required. |
Context
The mapping is stored in the XML configuration file of the respective authentication method.
Prerequisites
You need the initial user data from the directory. You can use the
For more information, see this ldapsearch
command (only UNIX-based OS), theFor more information, see this Jxplorer
tool, or export the data from the LDAP server.Always involve the censhare Solution development to implement a mapping.
Introduction
The authentication sequence from the censhare Client / censhare Web to the directory service (LDAP/AD) retrieves user profiles that are stored in the directory service. The retrieved values are written into a ticket and sent to the censhare Server. The censhare Server logs in the user with the attributes from the ticket.
At login, a user can be unknown to censhare, even if the user was already added to the directory service. Therefore, all required user data must be stored in the directory LDAP/AD. If only a user name and password is stored, the user must be added and logged in to censhare with default attributes.
The user attribute mapping ensures that a user that is authenticated via LDAP/AD, has the correct user settings in the censhare environment.
All the above is also valid if you use Kerberos SSO as authentication method for censhare.
Minimum required data
The minimum required data are mandatory attributes. To create a user in censhare, the following attributes are required:
Name (via
For more information, see the anchor [LINK:simple_mapping]
)Login name (via
For more information, see the anchor [LINK:simple_mapping]
)Display name (via
For more information, see the anchor [LINK:simple_mapping]
)Default role (via
For more information, see the anchor [LINK:complex_mapping]
)Default domain (via
For more information, see the anchor [LINK:complex_mapping]
)
When a user logs in via LDAP/AD, it must be ensured that the minimum required user data are queried.
Mappings
Defaults mapping
Usually, some attributes in a project can be set with their standard values. These defaults do not have to be queried. Instead, they can be set with their fixed values in the mapping. For example:
The attribute @isgroup attribute with the value 0 defines that the queried data refers to an individual user, not a group. The @locale attribute selects the user interface language at start. The @auth_standard attribute with the value 0 disables the standard login method. The @auth_extern attribute with the value 1 enables the LDAP/AD login.
Simple mapping
Attributes with a one-to-one relation can be retrieved and mapped directly to the corresponding censhare attribute. In the element, this is done in a that runs though the source attributes (binding.attr) and pairs each source attribute with the corresponding censhare attribute. For example:
// decode userAccountControl bit flags int userAccountControl = src.getInt("@value", 0); if ((userAccountControl & 0x02) > 0) // ACCOUNTDISABLE dest.put("@isactive", 0); else dest.put("@isactive", 1);
The @login name equals the principal@name source attribute. The target attributes @display_name, @firstname, @name, and @email are mapped to the respective sources. A beanshell script checks if the user is active or disabled, and sets the @isactive attribute (0/1).
Complex mapping
A complex mapping is required for the domains and roles that are assigned to a user in censhare. Besides the default role and default domain, users can have secondary domains and roles. Depending on the domain framework and governance model, secondary domains and roles are necessary for users to work with the censhare platform. For more information, see
For more information see this article [LINK:4388617]
.The following snippet runs through the binding.attr elements, reads the LDAP flag attributes maps the values to respective censhare attribute (isactive):
String dn = src.getEx("binding@dn"); if (dn.contains("OU=Developer")) { dest.put("@main_role", "developer"); dest.put("@main_domain", "root."); dest.put("@main_domain2", "root."); } else if (dn.contains("OU=Support")) { dest.put("@main_role", "support"); dest.put("@main_domain", "root."); dest.put("@main_domain2", "root."); } else { dest.put("@main_role", "nirvana"); dest.put("@main_domain", "root."); dest.put("@main_domain2", "root."); dest.put("@isactive", 0); }
The beanshell script retrieves the @dn source attribute and maps it to a target value set (@main_role, @main_domain, and @main_domain2). All three target attributes are mapped to only one source attribute. Similarly, a mapping for secondary roles and additional groups can be configured.
Result
When a new user logs in to censhare Web or the censhare Client, the user information is retrieved from the LDAP server and a new user is created in censhare with attributes returned from the LDAP server.
Next steps
Configure the LDAP/AD custom authentication method or Kerberos authentication method for the censhare Client and censhare Web.
Related content
For more information see this article [LINK:4843153]Page properties | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
|