If you can't find the product or version you're looking for, visit support.ataccama.com/downloads

Authentication Service Component

The Authentication Service component is used to protect invoking of services by using a username and password. Only the HTTP BASIC algorithm is used, so there is no secure encryption applied to usernames and passwords.

The component assigns some roles to each request and then compares the list of assigned roles with the role required in order to be allowed to invoke the service.

Since version 12, Authentication Service component is used only to secure OnlineCtl commands sent to the server via the internal server communication port. Using the component for other purposes is not supported.

The Authentication Service component has two main sections:

Authentication methods - Definition of the authentication method.
Role mapping providers - Assigns roles based on the authentication method and requester’s IP address.

Sample Authentication Service component configuration

<component class="com.ataccama.dqc.server.services.AuthenticationService">
    <methods>
        <method>
        ...
        </method>
    </methods>

    <roleMappingProvider class="com.ataccama.dqc.communication.auth.server.FileRoleMapping">
        <configFile>role-mapping.xml</configFile>
    </roleMappingProvider>

</component>

Authentication methods

The Authentication Service component authenticates the user accessing the server based on the methods configured. Once the user is authenticated, the component uses role mapping providers to assign roles to the user.

The Authentication Service component offers several methods of authentication:

Trust server method - No authentication at all.
Secret server method - Simple authentication based on a passphrase.
Password server method - Standard username and password authentication based on the defined authentication provider (file, LDAP). Recommended.

Trust server method

This method defines that there should be no authentication at all. If specified, all requests get the identity defined in the identity sub-element. Using TrustIdentity as in the following example, that identity has all possible roles, allowing it to execute all services.

<method class="com.ataccama.dqc.communication.auth.server.TrustServerMethod">
    <identity class="com.ataccama.dqc.communication.auth.server.TrustIdentity">
        <name>Trusted User</name>
    </identity>
</method>

Secret server method

This method provides basic security and can be used only for internal communication, that is, the secret method cannot be used to protect access to deployed web services. The secret method defines one passphrase that must be provided.

If the passphrase is correct, the request has the assigned identity defined in the element identity, as shown in the following example. Here you can also use the TrustIdentity as in the Trust server method example.

<method class="com.ataccama.dqc.communication.auth.server.SecretServerMethod">
    <secret>secret_word</secret>
    <identity class="com.ataccama.dqc.communication.auth.server.StandardIdentity">
        <name>Secret User</name>
        <roles>
            <role>users</role>
            <role>admin</role>
        </roles>
    </identity>
</method>

Password server method

This method is the recommended solution for password-protecting the access to the server. The password server method uses the provider that returns the identity according to the username and password extracted from the request.

The definition of the usernames, passwords, and roles that form the identity together with the IP address of the client depends on the provider. The localConnectionAllowed property of the password server method allows password-protecting the access to the server depending on how the user is accessing the server. The implementation is shown in the following sections.

Properties

Property Value Description

Property	Value	Description
localConnectionAllowed	true (default)	When set to `true`, the user can execute commands without providing credentials using the OnlineCtl command line tool when running the server locally (for example, `localhost`). For access to the remote server, the user is required to provide credentials.
false	When set to `false`, the user is required to provide credentials for each execution of commands that are provided by the OnlineCtl command line tool. This is also applicable when the user is running the server locally (for example, `localhost`).

localConnectionAllowed

true (default)

When set to true, the user can execute commands without providing credentials using the OnlineCtl command line tool when running the server locally (for example, localhost).

For access to the remote server, the user is required to provide credentials.

false

When set to false, the user is required to provide credentials for each execution of commands that are provided by the OnlineCtl command line tool. This is also applicable when the user is running the server locally (for example, localhost).

<method class="com.ataccama.dqc.communication.auth.server.PasswordServerMethod" localConnectionAllowed="true">
</method>

Providers

File based identity provider - Reads user and role definitions from an XML configuration file.
LDAP identity provider - Reads the identity from an LDAP source.

File based identity provider

The file based identity provider is used to retrieve identity information from a configuration file. It uses the username and password provided in the request and, if it is defined somewhere in the users section, it assigns roles defined as a comma-separated list in the roles attribute.

<provider class="com.ataccama.dqc.communication.auth.server.FileBasedIdentityProvider">
    <configFile>users.xml</configFile>
</provider>

Sample users.xml file

<dqc-users>
  <users>
    <user username="pepa" password="one" roles="admin" />
    <user username="joseph" password="two" roles="role1,role2" />
  </users>
</dqc-users>

In this example, joseph would have role1 and role2 roles if he uses the correct password (two).

LDAP identity provider

The LDAP identity provider is used to retrieve identity information from an LDAP source. It has the following configuration parameters:

ldapContextFactoryClass - Factory class name that should be used to create the LDAP context. If left unspecified, the component tries to use the factory specified in the LdapIdentityProvider.contextFactory system property or it uses the default com.sun.jndi.ldap.LdapCtxFactory.
urls - Sub-elements defining the URL locations of the LDAP source that are queried in order to resolve user identity.
basePath - All search queries in the LDAP source are done in the subtree defined by this path.
userQuery - Defines the search query that finds the user node in the LDAP source. In the query you can use ${login} that is replaced by the user login name from the HTTP authentication header.
dnAttribute - Sets the name of the attribute where stored the user’s distinguished name is stored. Defaults to distinguishedName` as it is used by ActiveDirectory.
authType - Value specifying the security level to use. The value is one of the following strings: "none", "simple", "strong".
authUser - The name of the user identity used for initial access to the LDAP source when looking for the user node corresponding to the user who is authenticating.
authPass - Password for the user specified in authUser parameter.
groupResolvers - Group resolvers are used to retrieve the mappings between the user and the role from LDAP. Then, the roles to which you want to assign certain permissions have to be created manually. When a role is created, users with this role automatically appear on the right side.

The following group resolvers are available: * *MemberAttributeResolver - The name of the group (role) is retrieved from the attribute of the authenticated user’s node. The name of the attribute is defined in the attribute attribute.

+ If the value is a valid distinguished name, the group name is the value from the most specific key-value pair of the distinguished name.
- ReverseMemberAttributeResolver - Tests if the group identified by the groupPath attribute has stored the authenticated user’s distinguished name in the attribute defined by attribute attribute.
  
  If the test is successful, the name of the group (role) is the value from the most specific key-value pair of the group’s distinguished name (that is, groupPath).
- GroupByMemberResolver - Similarly to ReverseMemberAttributeResolver, it tests whether some of the groups have the authenticated user’s distinguished name defined in the attribute attribute.
  
  The difference is that the search is recursive starting from the node basePath defined in the basePath attribute.
attributes - Attribute resolvers are used to read and assign the attribute value to the parameter. This attribute value is later accessible from the running plan using the getParameterValue() function.

The following attribute resolvers are available: * *BasicAttributeResolver - Reads the authenticated user’s attribute ldapAttribute and stores the value as user parameter named as specified in the name attribute. The value is later accessible using the function getParameterValue(key). The key is composed of the prefix "security.user." and the attribute name defined in the name attribute.

The access to the LDAP server requires creating an instance of the LDAP context factory class. Such class is specific for the Java runtime, so it is possible to define the class name that should be used as the LDAP context factory in case you cannot or don’t want to use the Sun’s implementation.

The LDAP initial context factory is specified by the Java runtime environment variable "LdapIdentityProvider.contextFactory" on the command line that starts the online server.

$JAVA_HOME/java -DLdapIdentityProvider.contextFactory=com.sun.jndi.ldap.LdapCtxFactory com.ataccama.dqc.server.bin.OnlineCtl start

Sample Authentication Service component definition

<provider class="com.ataccama.dqc.communication.auth.server.LdapIdentityProvider">
    <urls>
        <url>ldap://ldap1.company.net:3238</url>
        <url>ldap://ldap2.company.net:3238</url>
    </urls>
    <basePath>OU=Department1,DC=company,DC=net</basePath>
    <userQuery>(&amp;(objectclass=person)(!(objectclass=computer))(sAMAccountName=${login}))</userQuery>
    <dnAttribute>distinguishedName</dnAttribute>
    <authType>simple</authType>
    <authUser>ldap@company.net</authUser>
    <authPass>secret</authPass>

    <groupResolvers>
        <gr class="com.ataccama.dqc.communication.auth.server.MemberAttributeResolver" attribute="memberOf"/>
        <gr class="com.ataccama.dqc.communication.auth.server.ReverseMemberAttributeResolver" attribute="member" groupPath="CN=Developers,OU=mail,OU=Department1,DC=company,DC=net" dnAttribute="distinguishedName"/>
        <gr class="com.ataccama.dqc.communication.auth.server.GroupByMemberResolver" attribute="member" basePath="OU=Department1,DC=company,DC=net" dnAttribute="distinguishedName"/>
    </groupResolvers>
    <attributes>
        <!-- for getParameterValue("security.user.user_phone") -->
        <attr class="com.ataccama.dqc.communication.auth.server.BasicAttribibuteResolver" name="user_phone" ldapAttribute="mobile" />
    </attributes>
</provider>

Role mapping providers

In order to provide further role assignment, it is possible to configure a role mapping provider. The role mapping provider assigns roles based on the roles resolved by the authentication method or requester’s IP address.

Currently, the following role mapping provider is available:

File Role Mapping - Gets the role assignment definition from an XML file.

File role mapping

The file role mapping provider reads role assignment configuration from a file. The role is assigned to the user if the conditions defined in child elements are fulfilled.

There are four elements that can be combined and used to define various conditions.

require: Checks whether the user making the request already has a particular role (<require role="admin"/>) or whether the request uses the HTTPS protocol (<require ssl="true"/>).
location: Checks whether the request is processed from a particular location defined by the IP address and subnet mask (<location ip="172.16.17.72" mask="255.255.248.0"/>).

When it is necessary to combine several conditions for a role mapping definition, it is possible to use the following operators:

and: Assigns a role only if all conditions are satisfied.
or: Assigns a role if at least one condition is satisfied.

Sample role-mapping.xml file

<dqc-roles>
  <roles>
    <role name="admin_or_user">
      <!-- role 'admin_or_user' will be assigned to the user if they already have the role 'admin' or 'user' -->
      <or>
        <require role="admin"/>
        <require role="user"/>
      </or>
    </role>
    <role name="ssl_role">
      <!-- role 'ssl_role' will be assigned if the request is using the https protocol -->
      <and>
        <require ssl="true"/>
      </and>
    </role>
    <role name="manager">
      <or>
        <require role="admin" />
        <location ip="172.17.17.71" mask="255.255.248.0" />
        <and>
          <require role="role1" />
          <location ip="172.16.17.72" mask="255.255.248.0" />
        </and>
      </or>
    </role>
    <role name="ip_based_role">
      <location ip="172.16.17.72" mask="255.255.248.0" />
     </role>
  </roles>
</dqc-roles>

Was this page useful?