Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

You can set up access to PhixFlow either through PhixFlow Users, by integrating with your Active Directory infrastructure, or both. If you integrate with Active Directory, Access Control is maintained by mapping Active Directory Groups to PhixFlow User Groups, as described below. By using the Active Directory integration users will login to PhixFlow using the same username and password as their Microsoft Windows domain login.

This page describes how to integrate PhixFlow with Active Directory:

Table of Contents
maxLevel1

Configure phixflow-domains.xml

Connection details to the domain servers are configured in the file phixflow-domains.xml, under [tomcat root]/webapps/phixflow/WEB-INF/classes. When you first install PhixFlow, you probably created a copy of this file by simply copying the example file phixflow-domains.xml.example (see Install PhixFlow Server InstallationWebapp).

Create domain reference

To create a reference to a domain, update the section in the example file:

Code Block
languagexml
        <!-- Template of a authentication-provider -->
        <!-- 
        <security:authentication-provider ref="exampleActiveDirectoryAuthProvider" /> 
        -->

For example, if this domain will be referred to as corporate, update this to (remembering to remove the surrounding comment):

Code Block
languagexml
        <!-- Template of a authentication-provider -->
        <security:authentication-provider ref="corporate" /> 

Add connection details

Simple connection

The simplest type of connection is illustrated below, referencing a single AD server.

Update the section in the example file:

Code Block
languagexml
    <!-- Template of a bean providing domain and url to authentication-provider -->
    <!--
    <bean id="exampleActiveDirectoryAuthProvider" parent="activeDirectoryAuthProvider">
        <constructor-arg index="0" value="narnia.local" />
        <constructor-arg index="1" value="ldap://192.168.150.81" />
    </bean>
    -->

to include connection details to the domain. For example, if the domain is called corporate.local and this is manged by the domain controller at 10.23.109.45, update this to (remembering to remove the surrounding comment):

Code Block
languagexml
    <!-- Template of a bean providing domain and url to authentication-provider -->
    <bean id="corporate" parent="activeDirectoryAuthProvider">
        <constructor-arg index="0" value="corporate.local" />
        <constructor-arg index="1" value="ldap://10.23.109.45" />
    </bean>

Advanced options

For the connection you can also specify:

OptionPurposeExample
Multiple serversSome domains are served by multiple servers, to provide resilience and load balancing. These can be specified in a list. PhixFlow will try each of these in turn.
<constructor-arg index="1" value="ldap://ad1.example.com ldap://ad2.example.com" />
Root DNIf you have a large AD tree, searches may take some time, and this could lead to slow authentication for users. Therefore it is possible to specify a root DN (Distinguished name) at which PhixFlow will begin searching for the user. The Distinguished Name format is standard and further details can be found on the web.
<constructor-arg index="2" value="ou=User Accounts,ou=Operations,dc=emea,dc=example,dc=com" />
Timeout

You can specify a timeout. For each server specified, if the server does not respond within the limit specified by the timeout, it will try the next server. If the last server in the list times out, then the authentication will fail.

The timeout is specified in milliseconds.

<property name="timeout" value="5000"/>

The following example, in phixflow-domains.xml.example, illustrates the application of all advanced options:

Code Block
    <!-- Template of a bean providing domain, multiple servers, connection timeout and separate rootDn -->
    <!--
		<bean id="exampleActiveDirectoryAuthProvider" parent="activeDirectoryAuthProvider">
            <constructor-arg index="0" value="example.com" />
            <constructor-arg index="1" value="ldap://ad1.example.com ldap://ad2.example.com" />
            <constructor-arg index="2" value="ou=User Accounts,ou=Operations,dc=emea,dc=example,dc=com" />
            <property name="timeout" value="5000"/>
		</bean>
    -->


...

FieldValueExample
Default DomainThis is the domain that users will be presented with when they open PhixFlow. They will be able to select a different domain by selecting from a drop-down list, which will show all configured domains, as well as local. The local domain is used when logging in as an internal PhixFlow user User.


Code Block
local


Code Block
narnia.local


Active Directory Login Group

The list of names of Active Directory groups authorized to use this instance of PhixFlow, separated by semicolons. There must be no spaces between the groups listed, just semicolons.

Use {instance} to include the PhixFlow instance name (this is set up in System configurationConfiguration).

Note that these groups do not have to be mapped to any of the PhixFlow User Groups (see below), although they can be if you wish.


Code Block
PHIXFLOW_ADMINS; PHIXFLOW_USERS_{instance}


...

Enhanced diagnostics can be generated by adding the linelines

Code Block
# detailed logging for AD connection attempts
log4j.logger.org.springframework.security=debug
log4j.logger.com.accipia.centerview.util.ContextUserExtractor=debug
log4j.logger.com.accipia.centerview.util.security=debug
log4j.logger.com.accipia.centerview.model.POJOImpl=debug

to your log4j.properties file - see Server Logging for details on controlling logging options with this file, and where to find the results.

Note that with all options applied, the log files generated will be very large. You must switch off these options as soon as you have completed your tests. You can comment out the lines in the log4j.properties file, if you want to keep them in the file, by placing a # at the beginning of each line.

You could also consider applying a more limited set of debugging options, e.g.

Code Block
log4j.logger.org.springframework.security=debug
log4j.logger.com.accipia.centerview.util.security=debug

This will not give you as complete a log of what is happening during a login attempt, but the log files generated will be smaller. In particular, this reduced set of debugging options will include messages from

Code Block
com.accipia.centerview.util.security.ActiveDirectoryLdapAuthenticationProvider

which provides information about what groups the user attempting to login belongs to.