The Admin UI Audit Logs can be configured to use security. When configured, whenever a user tries to access the UI via a browser, they will be redirected to the Login page. After the session is authenticated successfully, access to all pages can continue as normal.
On this page:
By default, security is disabled.
Access the settings.xml file in your distribution under the config folder.
1. Add the following element (if not present):
<authentication> <type>None</type> </authentication>
2. Change the authentication type based on your needs. Currently, there are three options:
When using ConfigFile authentication, you must set the password that the admin user will be validated against. The password to match is set in the system properties in the settings file in the adminPassword property. An example is shown below:
<!-- System properties --> <properties> <property name="adminPassword">searchtech</property> </properties>
For security reasons, it is recommended that you encrypt the password when setting the property. See Password Encryption for details on how to encrypt the password.
When LDAP authentication is selected, you must extend the authentication section to provide the LDAP server to authenticate with. By default, group based access is disabled, meaning that any user who is able to authenticate with the given LDAP server will be able to access the Aspire administration pages. To turn group based access on, you must further extend your configuration, adding the distinguished name (dn) of the group that controls access, an ldap query that will allow Aspire to establish the distinguished name (dn) of the user attempting log on from the user name they provided, the name of the attribute that holds the user to group membership information and an indicator as to whether that information is held in the user object or in the group object.
The following parameters may be used when configuring LDAP authentication:
Parameter | Type | Default | Description |
---|---|---|---|
/authentication/ldap/serverUrl | String* |
| The host and port of the ldap server to validate against |
/authentication/ldap/protocol | String |
|
|
/authentication/ldap/contextFactory | String | com.sun.jndi.ldap.LdapCtxFactory | The context factory class |
/authentication/ldap/authentication | String* | anonymous | Ldap authentication to use (anonymous/simple/DIGEST-MD5) |
/authentication/ldap/readTimeout | Integer | 5 minutes | The timeout when making reads. Numbers without suffixes are considered as milliseconds. Suffixes of ms (milliseconds), s (seconds), m (minutes), h (hours), or d (days) may be used |
/authentication/ldap/connectTimeout | Integer | 1 minute | The timeout when connecting. Numbers without suffixes are considered as milliseconds. Suffixes of ms (milliseconds), s (seconds), m (minutes), h (hours), or d (days) may be used |
/authentication/ldap/connectionPool | Boolean | True | Should a connection pool be used |
/authentication/ldap/referralType | String | Ignore | How LDAP referrals should be handled (ignore/follow) |
/authentication/ldap/searchBase | String | dc=search,dc=local | The search base for ldap queries for the user's dn |
/authentication/ldap/adminGroupDN | String |
| If empty, disables group based access control. Otherwise, holds the dn of the group that may access the administration pages. NOTE: currently, the user must be a direct member of this group (not a member of a group that is a member of this group) |
/authentication/ldap/groupsHoldMembers | Boolean | False | Indicates that ldap group objects hold the membership information. By default, user objects are expected to hold group membership |
/authentication/ldap/userDNQuery | String* |
| The ldap query to use to find the dn for the user that logged in. The information provided by the user as they logged in is available for substitution. See below for details. |
/authentication/ldap/memberAttr | String | memberOf | The attribute of the ldap object (be it user or group) that holds information about group membership |
* Mandatory
When group based access control is disabled, a simple validation of the credentials supplied by the user is all that is required to allow access to the Admin UI. Adding the dn of a group in to the configuration will enable group based access control and, following a successful validation of credentials, the ldap server is queried to see if the user belongs to the desired group. Two slightly different approaches are used depending on the setting of the groupsHoldMembers flag.
By default, groupsHoldMembers is disabled. In this configuration, Aspire queries the ldap server to get the user object using the query specified in the userDNQuery parameter. Once the user object has been found, the membership attribute (configured by the memberAttr parameter) is extracted and the values of this attribute are checked. If one is equal to the adminGroupDN from the configuration, the user belongs to the group and is granted access. Otherwise access is denied.
When groupsHoldMembers is enabled, Aspire again searches ldap for the user object. It then gets the membership attribute (configured by the memberAttr) parameter from the group (using the dn configured in the adminGroupDN parameter) and looks for the dn of the user object. If found, the user belongs to the group and access is granted.
In both the above scenarios, the user must be a direct member of the group configure in the adminGroupDN, not an indirect member (ie not in a group that is a member of the configured adminGroupDN)
When a user logs in to the user interface, they are first validated against ldap server using the username and password they supplied. If group based access control is disabled, no further checks are performed and the user is granted access (assuming their username and password are valid). If group based access control is enabled, following a successful validation by the ldap server, Aspire then needs to establish the distinguished name of the user who logged on in order to work out if the user is in the appropriate group.
The dn of the user is found by performing a query in ldap for the user, based on the user name used to login. The query entered in the configuration may contain ‘parameters’ that are then substituted. The following parameters are available:
fullname | The full username entered by the user in the login page |
username | The name entered by the user in the login page, less any domain. Thus an entry of myDomain\myUser would become myUser in this parameter |
domain | The domain from the username entered. An entry of myDomain\myUser would become myDomain in this parameter |
Parameters are entered in the query by enclosing them in curly braces {}. For example, (&(objectClass=person)(sAMAccountName={username})) would become (&(objectClass=person)(sAMAccountName=Administrator)), if the user logged in with either domain\Administrator or Administrator.
When entering queries in the setting file, you will need to use a <![CDATA[]]> around the query or escape any special characters such as &.
Below is an example of a configuration allowing any valid LDAP user to log in to the Aspire interface.
<authentication> <type>Ldap</type> <ldap> <server>ldap://myLdapServer:389</server> <authentication>simple</authentication> </ldap> </authentication>
Below is an example of a configuration allowing any validated LDAP user who is a member of the group with the distinguished nane CN=Administrators, CN=Builtin, DC=qa, DC=local to log in to the Aspire interface. In this configuration, the membership information is taken from user objects (the default action) and the memberOf attribute values are checked against the adminGroupDN value and if it is found, the user is granted access.
<authentication> <type>Ldap</type> <ldap> <server>ldap://myLdapServer:389</server> <authentication>simple</authentication> <searchBase>dc=qa, dc=local</searchBase> <userDNQuery><![CDATA[(&(objectClass=person)(sAMAccountName={username}))]]></userDNQuery> <adminGroupDN>CN=Administrators, CN=Builtin, DC=qa, DC=local</adminGroupDN> </ldap> </authentication>
Below is an example of a configuration allowing any valid LDAP user who is a member of the group with dn CN=Administrators, CN=Builtin, DC=qa, DC=local to log in to the Aspire interface. In this configuration, the membership information is taken from group object (due to the groupsHoldMembers flag) and the member attribute values from the group are checked against the dn of the user and if it is found, the user is granted access.
<authentication> <type>Ldap</type> <ldap> <server>ldap://myLdapServer:389</server> <authentication>simple</authentication> <searchBase>dc=qa, dc=local</searchBase> <userDNQuery><![CDATA[(&(objectClass=person)(sAMAccountName={username}))]]></userDNQuery> <adminGroupDN>CN=Administrators, CN=Builtin, DC=qa, DC=local</adminGroupDN> <groupsHoldMembers>true</groupsHoldMembers> <memberAttr>member</memberAttr> </ldap> </authentication>