Configuring Viewpoint > Configuring security in Viewpoint > Integrating Viewpoint with LDAP/Active Directory

2.4.4 Integrating Viewpoint with LDAP/Active Directory

Viewpoint is equipped with pluggable security that easily handles integration with LDAP/Active Directory. Configuration for setting up LDAP authentication and authorization requires editing four elements in the core.xml file.

When you select LDAP during Viewpoint installation, the core.xml file is automatically generated to include the login module, the permissions map, and a default, functional LDAP configuration; however, if you selected a different security method, you can manually configure Viewpoint to use LDAP/Active directory

Several rules apply to configuring LDAP in Viewpoint. The DSA may only have one DIT unless it is specifically configured to allow searching from DSE (as with referrals). Any entry can be either an LDAP or Application user, but they are different: an LDAP user's rights are based on LDIF access to directives or proprietary framework, and an Application user (Viewpoint, email, web application, etc.) uses the entry's attributes or group membership to determine roles and permissions in the application. Security such as SSL/TLS and SASL must be configured outside of Viewpoint, and the Viewpoint server must be configured accordingly.

To integrate with LDAP/Active Directory

  1. Open the core.xml file located in the Viewpoint home directory and locate the <login-module> element. Specify the class as "com.cri.security.server.modules.LdapLoginModule". Define the LdapLoginModule by inserting the <option> element within <login-module> and applying the name attribute for each of the following:
    2. Option Description
    connectionURL

    The fully-qualified name of the initial context factory that will be used. The format is <protocol>://<server>:<port>. <protocol> should be 'ldap' or 'ldaps', <server> should be the hostname or IP address, and port is optional if the default is used (389 if the protocol is ldap, and 636 if it's ldaps).

    Setting the protocol to 'ldaps' overrides the connectionProtocol, forcing its setting to 'ssl'.
    connectionUsername The distinguished name used by the login module for authentication on the LDAP server. In many cases, this will be the bind user or some other read-only account created specifically for this purpose. Active Directory also accepts the format <user>@<domain>.
    connectionPassword The credential (password) of the user set in connectionUsername that is used for the login module to authenticate on the LDAP server.
    userBase The distinguished name (baseObject) for the user search.
    userSearchMatching The criteria (filter) in the search for the user object; for example: (cn=Joe User). Additionally, you can pass a parameter instead of the literal value to the search filter. If you want to parameterize the value of the attribute type (as when inserting the username that the user entered), specify (cn = {0}) for the case where you want to insert the username.
    userRoleName LDAP attribute type for the user group membership. Different LDAP schemas represent user group membership in different ways. Examples are memberOf, isMemberOf, member, and so forth. For example, if you have: memberOf: cn=admin,ou=groups,dc=foo, specify memberOf as the value for the userRoleName option.
    roleBase The base distinguished name (baseObject) for the search for the groups of which the user is a member.
    roleSearchMatching The criteria (filter) to be used to search for the role object. In addition you can pass a parameter instead of the literal value to the search filter; for example: (uniqueMember = {0}) for the case where you want to insert the username.
    roleName The LDAP attribute type that identifies the group name attribute in the object returned from the group membership query. Note that group membership query is defined by the roleSearchMatching parameter. Often, the group name parameter is cn.
    authentication The security level to be used. The value must be 'non', 'anonymous', 'simple', or '<sasl-mechanism>'. Any values besides these are treated as a SASL mechanism like 'EXTERNAL' or 'GSSAPI'. In most cases, 'simple' should be used. 'none' and 'anonymous' have the same effect: they disregard connectionUsername and connectionPassword and attempt an anonymous bind. If not set, the value is determined by the LDAP server.
    userSearchSubtree This defines the directory search scope for the user. If set to true, directory search scope is SUBTREE, if set to false, directory search scope is ONE-LEVEL.
    roleSearchSubtree This defines the directory search scope for the role. If set to true, directory search scope is SUBTREE, if set to false, directory search scope is ONE-LEVEL.
    connectionProtocol The security protocol to be used. This value can be determined by the LDAP server. This can be 'ssl' or 'plain'; however, if another value is used, it is interpreted as 'plain'.
    followReferrals The aliasDeref for both user and group searches. The default is true (follow). If set to false, it is ignore.
    initialContextFactory The fully-qualified name of the initial context factory that will be used. This is always com.sun.jndi.ldap.LdapCtxFactory except for a super-advanced power user.

    For all searches (userSearchMatching and roleSearchMatching), RFC 2254 filters are allowed.

    Example 2-1: Active Directory

    <login-modules>

  <login-module flag="required" class="com.moab.api.login.MoabLoginModule" />
				
  <login-module class="com.cri.security.server.modules.LdapLoginModule" flag="required" >
    
    <!-- Should be set -->
    <option name="connectionURL">ldap://vp-ldap-ad1:389</option>
    <option name="connectionUsername">binduser@ldap</option>
    <option name="connectionPassword">binduser</option>
    <option name="userBase">cn=Users,dc=ldap,dc=ad</option>
    <option name="userSearchMatching">(&amp;(sAMAccountName={0})(objectClass=user))</option>
    <option name="userRoleName">memberOf</option>
    <option name="roleBase">cn=Builtin,dc=ldap,dc=ad</option>
    <option name="roleSearchMatching">(member={0})</option>
    <option name="roleName">sAMAccountName</option>
    
    <!-- Should be defaulted -->
    <option name="initialContextFactory">com.sun.jndi.ldap.LdapCtxFactory</option>
    <option name="authentication">simple</option>
    <option name="userSearchSubtree">true</option>
    <option name="roleSearchSubtree">true</option>
  </login-module>
				
</login-modules>

    Example 2-2: OpenLDAP

    <login-modules>

  <login-module flag="required" class="com.moab.api.login.MoabLoginModule" />
				
  <login-module class="com.cri.security.server.modules.LdapLoginModule" flag="required" >
    
    <!-- Should be set -->
      <option name="connectionURL">ldap://localhost:389</option>
      <option name="connectionUsername">cn=binduser,cn=Users,dc=example,dc=com</option>
      <option name="connectionPassword">binduser</option>
      <option name="userBase">cn=Users,dc=example,dc=com</option>
      <option name="userSearchMatching">(uid={0})</option>
      <option name="userRoleName">role</option>
      <option name="roleBase">cn=Groups,dc=example,dc=com</option>
      <option name="roleSearchMatching">(member={0})</option>
      <option name="roleName">role</option>

      <!-- Should be defaulted -->
      <option name="initialContextFactory">com.sun.jndi.ldap.LdapCtxFactory</option>
      <option name="authentication">simple</option>
      <option name="userSearchSubtree">true</option>
      <option name="roleSearchSubtree">true</option>
  </login-module>

</login-modules>

    The MoabLoginModule is required even if you are using LDAP to authenticate. If Viewpoint displays "Welcome, null" at the top right corner of the page after you successfully log in, then you most likely need to add the line to configure MoabLoginModule, as shown above.

  2. Find the <role-definitions> element and set the roles, giving each one a unique definition name.

    3. If you are already using another login module, the role definitions will probably stay the same. Following an LDAP Viewpoint installation, however, the role definitions will probably need to change.

    Roles may be user-specific or apply to a group.

    1. Set the roles' permissions by inserting the <permission> element within definition and giving it a unique name. You may set multiple permissions for each role definition.
      2. <role-definitions>
  <definition name="bob">
    <permission name="random.permission" />
    <permission name="different.permission" />
  </definition>
  <definition name="admin">
    <permission name="admin.permission1" />
    <permission name="admin.permission2" />
  </definition>
</role-definitions>
  3. Locate the <permissions-map> section.
    1. Set <principal type="LdapGroupPrincipal"> for each group role. Set <principal type="LdapUserPrincipal"> for each user-specific role.
    2. Define the principal's role name as the same name used in the role definition section.
      3. <permissions-map>
  <principal type="LdapUserPrincipal" name="userA">
    <role name="bob" />
  </principal">
  <principal type="LdapGroupPrincipal" name="groupA">
    <role name="admin" />
  </principal>
</permissions-map>

    The userA principal grants the user the permissions given to user bob in role definitions. The groupA principal grants the users the permissions given to group admin in role definitions.

    A user may have multiple assigned roles. For example, if user bob is assigned the role bob and the role admin, he is granted both a unique set of permissions and the same set of a admin permissions shared by several users.

  4. Configure JAAS by adding the appropriate callback parameters to the <request-handler> element.
    1. Set the <parameter> child element with a callback value of "ProxyUserCallback". Specify the username.
    2. Set the <parameter> element with a callback value of "NameCallback". Specify the username.
    3. Set the <parameter> element with the callback value of "PasswordCallback" Specify the password.
  5. Restart Tomcat.

Related topics 

 

© 2012 Adaptive Computing