The LDAP-based security sources, as is the case for all Exalead CloudView security sources, provide two main functions:
• User authentication.
• User security tokens computing.
The former is possible only if user login functionality is enabled on the LDAP server. The latter authentication using an LDAP security source is a three-step procedure:
• User full DN retrieval: First, using the user login, which may be the full DN or any other valid login value, the security source tries to guess the user’s full DN.
• User identity validation: After the resolution of the user's full DN, the user's password is checked by opening an LDAP connection on the LDAP server. This action uses the user's full DN and the user's supplied password. If the connection is successfully opened, the computed user security tokens are returned.
• Security tokens computing: In the final step of authentication, the security source computes the security groups that the user belongs to and returns all the user security tokens to the application.
Security Servers
There are many implementations of LDAP. There are, however, several commonly deployed LDAP security servers. For these specific LDAP implementations, there are dedicated security sources in Exalead CloudView. The following is the list supported:
• OpenLDAP
• Active Directory (Microsoft windows user/group repository)
There is also a generic LDAP security source that is fully configurable, allowing you to configure any LDAP server.
Authentication Method
The LDAP security source primarily supports the following authentication methods:
• None (anonymous access enabled)
• Simple
Other values are permitted depending on your configuration and the LDAP implementation. For more details, see Context.SECURITY_AUTHENTICATION on http://docs.oracle.com/javase/jndi/tutorial/ldap/security/auth.html.
Authentication Protocol
The LDAP security source supports the following authentication protocol versions:
• LDAP v2
• LDAP v3
Caching Group Information
The groups a user belongs to are using:
• Group parents attributes: the list of attributes that contain the parents of a given group.
• Group members attributes: the list of attributes that contain the members of a given group.
• Person parents attributes: the list of attributes that contain the parents of a given user.
Groups inclusion is the relationship between groups. When groups inclusion is configured in the LDAP server (group-expand=true), it is resolved once and set in the cache, as computation is very costly. It requires full LDAP groups listing. Use the Scheduler process to refresh the cache at an appropriate interval.
To refresh the source cache, click Manage and select MAMI master in the API Console. Under Configuration, select the setSchedulingConfig method and then edit the configuration:
For all security sources, the Security Manager allows you to test the authentication for a user. When you configure a LDAP-based security source, you can test the user authentication on the configuration page with the Test button. This allows you to specify a Login and a Password for authentication. If the user is:
• Authenticated, the Display name and the security Tokens display.
• Not authenticated, an error message displays.
You can choose whether or not to perform a password check.
Note: Each call performs a new group cache computation and may take a few minutes, depending on the size of the LDAP source.
OpenLDAP Security Source
OpenLDAP is an open-source LDAP client and server implementation.
This section describes:
User Login
In the OpenLDAP, the inetOrgPerson object class identifies persons. User login match is case insensitive. A valid user login can use several values:
• EnableDN Login, for OpenLDAP, this allows the user to log in its full DN. Only DNs rooted on the defined LDAP search base are allowed.
• Attribute value cn, which is the common name.
There can be only one match for the value on the OpenLDAP server, otherwise, the login fails. The first step in the user login phase resolves the full user DN.
In some cases, the LDAP server login is not used and only security tokens are resolved.
Groups
In OpenLDAP, the groupOfNames object class identifies groups. To compute the groups a user belongs to, the member attribute defines the group entries.
Display Name
The cn attribute of the OpenLDAP builds the user display name.
Security Tokens Format
The security tokens are:
• ldap:USERFULLDN
• ldap:USERGROUPFULLDN for each group the user belongs to.
The OpenLDAP security source primarily supports the following authentication methods:
• None (anonymous access enabled)
• Simple
Other values are permitted depending on your configuration and the LDAP implementation. For more information, see Context.SECURITY_AUTHENTICATION on http://docs.oracle.com/javase/jndi/tutorial/ldap/security/auth.html.
OpenLDAP Software 2.x implements LDAP version 3 (default) and OpenLDAP Software 1.x implements LDAP version 2.
For more information, see .
Active Directory Security Source
The Active Directory is a Microsoft Windows-based implementation of LDAP. The Active Directory security source inherits the generic LDAP security source behavior with a specific configuration.
This section describes the Active Directory specific LDAP implementation.
Important: The Active Directory security source does not update security information automatically. The workaround to this limitation is to run the following command in your <DATADIR>\bin directory:
In the Active Directory, the user object class identifies users. The user login match is case insensitive. You can use several attributes for a valid user login.
Attribute
Description
DN login
Allows the user to log in with the full DN. Only DNs rooted on the defined LDAP search base are allowed.
sAMAccountName
The windows account name, for example, doe.
mail
The user email address, for example, john.doe@exalead.com.
userPrincipalName
The user principal name, for example, doe@office.exalead.com.
Exalead CloudView tries to match the user login with these attributes in this order. There must be a unique match for the value on the Active Directory server, otherwise, the login fails. The first step in the user-login phase resolves the full user DN.
In some cases, the Active Directory server login is not used and only security tokens are resolved.
Display Name
The displayName attribute of the Active Directory generates the user display name.
Group Configuration
In Active Directory, the group object class identifies groups. The groups a user belongs to are computed at login time, using the configuration lists:
• Group > Additional LDAP attributes: the list of attributes that contain the additional attributes to return for a given group.
• Group > Groups attributes: the list of attributes that contain the members of a given group. To compute the groups a user belongs to, the memberOf attribute defines the group entries.
• Person > Groups attributes: the list of attributes that contain the groups of a given user.
Security Tokens
In Active Directory, user security tokens are generated based on the user entry and the group. Security tokens are built from windows object SIDs. The generated security tokens allow the matching of security tokens that can be set by a filesystem, Microsoft Exchange, or Microsoft Office Sharepoint Server connector.
Security tokens can be generated from the user entry. For example, if the user CN=John Doe, OU=Exalead Users, DC=office, DC=exalead, DC=com has the following LDAP attributes:
• objectSid: S-1-5-19819-101018018-189989898
• primaryGroupId: 1891
The following security tokens are generated:
• windows:S-1-5-19819-101018018-189989898
• windows:S-1-5-19819-101018018-189989898-1891
• windows:S-1-5-32-545 (BUILTIN\Users group)
Security tokens can be generated from groups to which the user belongs. For example, if the group CN=Administrators, CN=Exalead Users, DC=office, DC=exalead, DC=com has the following LDAP attributes:
objectSid: S-1-5-19819-101018018-189989898
The generated security tokens for this group is:
windows:S-1-5-19819-101018018-189989898
Lotus Domino Security Source
The Domino Directory is an LDAP implementation shipped within any standard installation of Lotus Domino. It is activated by default but you can deactivate it for custom setups.
The Domino Directory security source inherits the generic LDAP security source behavior with a specific configuration.
This section describes the Domino Directory specific LDAP implementation:
User Login
In the Domino Directory, the dominoPerson object class identifies persons. User login match is case insensitive. You can use several values for a valid user login:
Important: For Domino Directory, users can also log in using their full Lotus Notes DN. Write the DN in LDAP style, using comma separators. Specify enableDNlogin to true.
• Attribute uid is the user short identifier.
• Attribute mail is the user internet address.
• Attribute cn is the common name.
Exalead CloudView tries to match the user login with these attributes in this order. There must be a unique match for the value on the Domino Directory server, otherwise, the login fails. The first step in the user login phase resolves the full user DN.
Authentication Using the Domino Directory
If you want to authenticate the Exalead CloudView user with the Domino Directory security source, set the internet password on the Domino Directory. On the Domino Directory, activate the option to copy the user password from notes.id into the internet password of the user.
If the Domino Directory security source is used for authentication, the password entered by the Exalead CloudView user is compared to the internet password for the user profile in Lotus Domino.
Display Name
The cn attribute of the Domino Directory builds the user display name.
Groups
In Domino Directory, the dominoGroup object class identifies groups. To compute the groups a user belongs to, the member attribute defines the group entries.
Security Tokens
For a given user, the Domino Directory generates security tokens based on the user DN and the group.
Security tokens can be generated from the user DN. The user DN (LDAP format) is CN=Jane Smith,CN=madvs001,DC=preprod. The following security tokens are generated.
• notes:builtin:-Default-
• notes:CN=Jane Smith/CN=madvs001/DC=preprod
• notes:*/CN=madvs001/O=preprod
• notes:*/O=preprod
• notes:*
This automatic splitting on the user full DN is used for matching wildcard ACLs that could have been defined in the Lotus Notes databases that have been indexed. The separator , is replaced with / to match the security tokens that may have been set by the Lotus Notes connector.
Security tokens can be generated from groups to which the user belongs. The group DN (LDAP format) is CN=Users,CN=madvs001,DC=preprod. The following security tokens is generated.
• notes:CN=Users/CN=madvs001/DC=preprod
Limitations
Below is the list of Lotus Notes security features that this security source does not support:
• Handling of the security defined at the view level.
• Handling of the security defined at the item level.
• Handling of database ACL entries of type Unspecified. Only entries of type Person or Group are supported.
• Sequential checking of the ACL entries in the following order - user, group, and wildcard - until a match is found thus granting the highest access level and allowing access privileges at the same level to be grouped. Exalead CloudView Search denies access to a database if there is an ACL entry match at any level with no read access.
Configure an LDAP Security Source
You can follow the procedure below to configure an LDAP security source.
1. In the Administration Console, go to Search > Security Sources and click Add security source.
a. In Name, enter a descriptive name.
b. In Type, select an LDAP source type.
c. Click Accept.
2. Go to the Configuration tab and verify that the Deployed check box is selected.
3. Under Connection, enter the LDAP-based Server Address for the security source. For example, directory.exalead.com.
4. Enter the login credentials in Username and Password.
5. Enter the LDAP's Authentication method.
The default value corresponds to the default behavior for each security source.
6. Enter the LDAP Protocol.
The default value corresponds to the default behavior for each security source.
7. Select an Encryption method.
8. Enter the LDAP's search Base. For example, cn=Users,dc=office,dc=exalead,dc=com.
9. Enter the Timeout value for the connection.
10. To make LDAP attribute matching case-insensitive, select Ignore case.
11. Click Apply.
Local Windows Security Source
This section describes the configuration of a local Windows security source on Windows platforms.
Technical Overview
The local Windows security source actually corresponds to the instance of a local security source in an Exalead CloudView installation on a Windows system (2000 / XP / 2003 / Vista / 2008).
The Windows local security source implementation relies on the Windows SSPI authentication tools used for managing user authentication on a Windows system. This means that every user with login rights to the system where Exalead CloudView is installed can be identified by this security source.
User Login
Users are identified by their Windows account name.
User Groups
The Windows group the user belongs to are returned.
Security Tokens
Security tokens are generated for each user. These security tokens may match the document's ACLs from a filesystem, Microsoft Exchange, or Microsoft Office Sharepoint Server connector.
There are security tokens generated for the user and group. The following are examples of security tokens generated from users and groups.
• If the user smith has an SID S-1-5-19819-101018018-189989898, the following security tokens are generated: windows:S-1-5-19819-101018018-189989898.
• If the group Exalead has an SID S-1-5-19819-101018018-189989898, the generated security tokens for this group are windows:S-1-5-19819-101018018-189989898.
Configuring the Security Source
The following parameters control the local windows connection used for implementing this security source.
• Domain: Domain used to identify the user.
• login as a token: To push the login as a security token.
The local UNIX security source actually corresponds to the instance of a local security source in a Exalead CloudView installation on a UNIX system.
This security source implementation relies on PAM subsystem's password authentication module. For more information, see your PAM configuration, in particular the /etc/pam.d configuration.
For a Local UNIX security source on a UNIX system, this section describes:
Technical Overview
User Login
Users are identified by their UNIX account name.
User Groups
The groups a user belongs to are computed from information found in the system user database.
Security Tokens
For a given user, the following security tokens are generated. These security tokens are built so that ACLs of documents indexed on a UNIX file system can be matched by Exalead CloudView on a UNIX system.
There are security tokens generated for the user and group. The following are examples of security tokens generated from users and groups.
• If the user UNIX account name is smith and the user identifier (UID) is 501, the following security token are generated unix:user:501.
• If the group UNIX name is exalead and its UID is 601, the following security token are generated unix:group:601.
Prerequisites
For this security source to be functional, the user running Exalead CloudView must have read access to the system user database.
Limitation
The UNIX security source is only compatible with NIS-based authentication.
Configuring the Security Source
The following parameters control the local UNIX connection used for implementing this security source.
• Domain: If empty, the default PAM login is used. Otherwise, the specified PAM service is used. The typical configuration is /etc/pam.d/<service>.
• login as a token: To push the login as a security token.
This section explains how remote HTTP security works, as well as how to configure both the security on the source and on Exalead CloudView.
Exalead CloudView provides a remote security API based on a simple HTTP GET or POST / XML protocol. Remote security providers can therefore supply a way for Exalead CloudView to authenticate a user and to retrieve its security tokens. These security tokens are then used by Exalead CloudView to secure document access: the user can only see the documents that match user security tokens of this given user.
Mandatory Services
• Authenticate (GET or POST): authenticates a user
Must be available on <URL>/authenticate and on <URL>/.
• Reset (GET): restores the security source to its initial state
Must be available on <URL>/reset.
Authentication Request
Exalead CloudView Search triggers a remote security query to the remote security connector using a simple HTTP GET or POST. Authentication parameters, login and password, pass through the url. If there is no need for authentication, the url parameter checkPassword with the value false can be passed and the password parameter is optional.
Authentication Response
Whether the remote security source succeeded to authenticate the user, it sends back a 200 OK and embeds in the http body the authentication result (XML representation) with it is state.
If the authentication succeeded, it contains the list of security tokens of the user; otherwise it contains the cause of failure.
Required Response Format
The AuthenticationResult must be in XML, with the following attributes:
• xmlns (required): internally used by Exalead CloudView. The value is always exa:com.exalead.security.sources.common.
• success (required): it defines if the authentication succeeded. Possible values: true or false.
• userId (required): the login used to authenticate the user.
• userDisplayName: The real name of the authenticated user. Used only when authentication is successful.
• cause: the reason of failure. Used only when authentication fails.
If authentication is successful, the node also contains a list of security tokens.
A SecurityToken has one attribute.
• token: the value of the security token, which must be the same value than the one used during indexing.
Configuring a Remote HTTP Security Source
In the Administration Console, go to Search > Security Sources and click Add security source.
• For Type, select Remote Http.
• The isAlivepath parameter defines the path to a service that must reply with an http code below 400. When using multiple hosts, it helps Exalead CloudView to detect available hosts. Leave this field empty to disable this option.
• The service path parameter defines the path to access the security service.
• The maxRetries parameter defines the number of trials before giving up on a host connection.
To provide high availability, you can declare multiple hosts with the following parameters:
• The Host parameter defines the host name of the remote security provider.
• The Port parameter defines the port of the remote security provider.
• The Priority parameter is only used if you specify multiple hosts. Connections are made first on a host with higher priority. In case of equality, it is randomly selected.
Federate Several Security Sources
You can use security source dispatchers to federate several security sources.
Documents are coming from several different connectors. Each connector is associated to a security model with different credentials. The goal is to provide a unified page so that the user only needs to log on once, and see all the documents from all the sources the user can access to.
Define:
• The security source tokens to retrieve.
• For each security source:
◦ Is the user who they claim to be?
◦ What are the access rights linked to the user?
Security Source Logins
If the login is not identical on each source, you need to map the login entered by the user with the pattern that exists in all the other security sources. In this case, use the Login rewriting field and the $login variable.
Example:
John Doe is identified by mydomain\jdoe in the first security source and by jdoe@mycompany.com in the second security source.
To map both logins, enter in the Login rewriting field:
• mydomain\$login for the first security source
• $login@mycompany.com for the second security source
Authentication checks that the user exists and that their password is correct. It is mandatory for at least one security source.
Authorization retrieves access rights granted to the user (security tokens). Password is optional. If the password check fails, no access right is granted to the user for the security source.
Create a Security Source Dispatcher
1. In the Administration Console, go to Search > Security Sources and click Add security source.
2. In Name, enter a name for the security source.
3. In Type, select Security source dispatcher.
4. Click Accept.
5. In the Configuration tab, configure the Authentication behavior:
◦ First: retrieves the tokens for the first security source on which the user successfully authenticates.
◦ Merge: retrieves the tokens for all security sources on which the user successfully authenticates.
◦ No authentication: removes the authentication constraint. This is useful when users connect through SSO.
6. In the Configuration tab, configure the Additional tokens: for example, if you need to create a group of users, add security tokens.
7. In the Configuration tab, configure the Security sources:
a. Name: select the security sources you want to federate.
b. Login rewriting: if required, set the login schema to use.
c. Source type: select either the authentication or authorization mode.
d. Check password: select this check box if you want to check the password when using the authorization security source.
e. Actions: use the arrows to organize security sources.
8. Test user authentication to make sure that your security source dispatcher is properly configured.