LDAP & Kerberos SSO - User attribute mapping
The authentication at censhare via 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 ldapsearch command (only UNIX-based OS), the 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 an 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 simple mapping)
Login name (via simple mapping)
Display name (via simple mapping)
Default role (via complex mapping)
Default domain (via 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:
<mapping default="0" dest="@isgroup"/>
<mapping default="en" dest="@locale"/>
<mapping default="0" dest="@auth_standard"/>
<mapping default="1" dest="@auth_extern"/>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 through the source attributes (binding.attr) and pairs each source attribute with the corresponding censhare attribute. For example:
<mapping src="^.principal@name" dest="@login"/>
<loop src="binding.attr">
<mapping>
<switch src="@name">
<case value="displayName">
<mapping src="@value" dest="@display_name"/>
</case>
<case value="givenName">
<mapping src="@value" dest="@firstname"/>
</case>
<case value="sn">
<mapping src="@value" dest="@name"/>
</case>
<case value="mail">
<mapping src="@value" dest="@email"/>
</case>
<case value="userAccountControl">
<mapping>
<bsh>
// decode userAccountControl bit flags
int userAccountControl = src.getInt("@value", 0);
if ((userAccountControl & 0x02) > 0) // ACCOUNTDISABLE
dest.put("@isactive", 0);
else
dest.put("@isactive", 1);
</bsh>
</mapping>
</case>
</switch>
</mapping>
</loop>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.
The following snippet runs through the binding.attr elements reads the LDAP flag attributes maps the values to respective censhare attribute (isactive):
<mapping src="^.principal@name" dest="@login"/>
<loop src="binding.attr">
<mapping>
<switch src="@name">
<case value="userAccountControl">
<mapping>
<bsh>
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);
}
</bsh>
</mapping>
</case>
</switch>
</mapping>
</loop>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.