You can set up access to PhixFlow either through PhixFlow Managing the User List, by integrating with your Active Directory infrastructure, or with SAML. If you integrate with SAML, Access Control is maintained by mapping Active Directory Groups to PhixFlow User Groups, as described below. By using the SAML integration users will be redirected to a chosen identity provider page where they will enter their username and password. If they are successfully authenticated they will then be redirected to PhixFlow and logged in.
This page describes how to integrate PhixFlow with SAML. Insert excerpt _admin_user_topic _admin_user_topic nopanel true
Contents
| Table of Contents |
|---|
Configure phixflow-login.xml
Configuration details for SAML are configured in the file phixflow-login.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-login.xml.example (see Install PhixFlow Webapp).
Configure the authentication manager
Add the SAML auth provider (which is already defined) to the authenticationProvider.
Find this section of the file:
| Code Block |
|---|
<security:authentication-manager alias="authenticationManager"> <!-- test authentication provider, leave commented out --> <!-- <security:authentication-provider ref="testAuthProvider" /> --> <!-- local authentication provider - provide access for CenterView database users. Don't change it --> <security:authentication-provider ref="localAuthProvider" /> <!-- Add an Active Directory Authentication Provider below this line; uncomment if using active directory integration --> <!-- <security:authentication-provider ref="exampleActiveDirectoryAuthProvider" /> --> <!-- Add SAML Authentication Provider; uncomment if using saml / single sign-on --> <!-- <security:authentication-provider ref="samlAuthProvider"/> --> </security:authentication-manager> |
... and edit it to look like this (omitting comments):
| Code Block | ||
|---|---|---|
| ||
<security:authentication-manager alias="authenticationManager"> <security:authentication-provider ref="localAuthProvider" /> <security:authentication-provider ref="samlAuthProvider" /> </security:authentication-manager> |
We recommend that you do not remove the localAuthProvider, and that you retain a local administrator user so that you can still login in the event of a problem with the SAML integration.
Configure Login Forms
Login forms define the login options (local, single sign-on, active directory) to be presented on the login screen when a user opens the PhixFlow URL. This mechanism allows you to define a default form tailored to regular users and one or more forms for advanced users.
See Configure Login Forms for how to configure and use login forms.
Enable SAML beans
These 2 blocks serve to disable the bulk of the file for the normal case where SAML is not required.
Find these lines and remove them or comment them out:
| Code Block |
|---|
<!-- comment out to enable saml / single sign-on --> <beans profile="saml"> |
E.g.
| Code Block |
|---|
<!-- comment out to enable saml / single sign-on --> <!-- <beans profile="saml"> --> |
Find these lines, near the end of the file, and remove them or comment them out:
| Code Block |
|---|
<!-- comment out to enable saml --> </beans> |
E.g.
| Code Block |
|---|
<!-- comment out to enable saml --> <!-- </beans> --> |
Configure the keyManager
The SAML integration requires one or more public/private keys. These are stored in a Java keystore file, and the information needed to access that file is configured in the keyManager.
Instructions for creating a keystore can be found here: Configure Tomcat For HTTPS.
Below is an example of a keystorekeymanager bean configuration:
| Code Block | ||
|---|---|---|
| ||
<!-- The KeyStore stores encryption keys --> <bean id="keyManager" class="org.springframework.security.saml.key.JKSKeyManager"> <!-- the keystore file --> <constructor-arg value="file:/opt/tomcat/secure/keystore.jks" /> <!-- password protecting the keystore --> <constructor-arg type="java.lang.String" value="keyStorePassword" /> <constructor-arg> <map> <!-- key alias and key-specific password; add one entry for each key in the keystore --> <entry key="keyAlias" value="keyPassword" /> </map> </constructor-arg> <!-- default key alias --> <constructor-arg type="java.lang.String" value="defaultKeyAlias" /> </bean> |
For the most basic configuration just replace the "file:/.../keystore.jks" with your keystore, "KeyStorePassword" with your keystore password and "keyPassword" with your key password.
| Warning |
|---|
For security reasons, access to phixflow-login.xml and to keystore.jks should be restricted so that they are read-only to the tomcat user / account and not readable by regular users. |
Configure the Context Provider
The context provider communicates the external view of the PhixFlow server to other parts of the configuration.
If the server does not run behind a reverse proxy, you can skip the rest of this section.
If the server runs behind a reverse proxy, a different context provider must be configured to reflect the public view of the service.
Find this section:
| Code Block |
|---|
<!-- Context Provider --> <!-- context provider when behind reverse proxy --> <!-- see https://docs.spring.io/autorepo/docs/spring-security-saml/1.0.x/reference/html/configuration-advanced.html --> <!-- <bean id="contextProvider" class="org.springframework.security.saml.context.SAMLContextProviderLB"> <property name="scheme" value="https"/> <property name="serverName" value="www.myserver.com"/> <property name="serverPort" value="443"/> <property name="includeServerPortInRequestURL" value="false"/> <property name="contextPath" value="/spring-security-saml2-sample"/> </bean> --> <!-- context provider when not behind reverse proxy --> <bean id="contextProvider" class="org.springframework.security.saml.context.SAMLContextProviderImpl" /> |
Edit this by deleting the original contextProvider, uncommenting the reverse proxy version, and changing the serverName, serverPort and contextPath to match the public view.
It should look something like this (comments omitted):
| Code Block |
|---|
<bean id="contextProvider" class="org.springframework.security.saml.context.SAMLContextProviderLB"> <property name="scheme" value="https"/> <property name="serverName" value="myserver.com"/> <property name="serverPort" value="443"/> <property name="includeServerPortInRequestURL" value="false"/> <property name="contextPath" value="/phixflow"/> </bean> |
Configure the Metadata Generator
The core of the interaction between a SAML identity provider (e.g. Active Directory Federation Services) and a SAML Service Provider (e.g. PhixFlow) relies on the exchange of metadata. Each party generates metadata which describes how to connect to it, and that metadata must be installed into the other party before any connection can be made.
The metadata generator generates the PhixFlow server's metadata based on configuration parameters and data available when a user tries to connect to it.
Find the metadata generator section:
| Code Block |
|---|
<!-- filter that generates metadata based on configured properties --> <bean id="metadataGeneratorFilter" class="org.springframework.security.saml.metadata.MetadataGeneratorFilter"> <constructor-arg> <bean class="org.springframework.security.saml.metadata.MetadataGenerator"> <property name="entityId" value="urn:test:phixflow:phixflow" /> <property name="entityBaseURL" value="https://myhostname:myport/phixflow" /> <property name="extendedMetadata"> <bean class="org.springframework.security.saml.metadata.ExtendedMetadata"> <property name="idpDiscoveryEnabled" value="false" /> </bean> </property> </bean> </constructor-arg> </bean> |
Then
- change the entityId value to something that globally identifies the PhixFlow instance
- change the entityBaseURL value to the URL normally used to start PhixFlow. If PhixFlow is running behind a reverse proxy, this should be the public URL, not the internal URL which only the proxy sees.
...
How you do this is specific to the Identity Provider. For a Windows Server ADFS identity provider, follow the steps given to Add a Service Provider, on the /wiki/spaces/INTRANET/pages/817070323 page.
Configure Attribute Map
As part of the SAML / Single sign-on process, the identity provider sends details of the user who is logging in as a set of name/value pairs. An Attribute Map defines how PhixFlow maps the identity provider's attribute names to the names required by PhixFlow.
these steps:
Log into the Windows ADFS Server. Run the command mmc.exe - this will open the windows server management console. Go to File -> Add/Remove Snap in... and add ADFS.
In the left hand tree view that appears, open Relying Party Trusts, then click on Add Relying Party Trust..., in the right hand menu.
Select Claims aware.
Next, choose to 'import data about the relying party from a file'. Browse to the service provider metadata xml file created in the previous step, and select it. Give the new relying party a name. Choose Access Control Policy: Permit Everyone. On the final screen you can review the details of the relying party that will be created. You should not have to edit any of this information.
A new entry will appear in the list of relying party trusts on the mmc.exe management console.
Configure Attribute Mapping on the Identity Provider
Select the relying party trust that has been created. In the right-hand menu, click on Edit Claim Issuance Policy. This will bring up a list of Issuance Transform Rules, initially empty. Click on Add Rule. For the claim rule template, select Send LDAP Attributes as Claims. On the next screen, give the claim rule a name (anything will do), and select Active Directory as the attribute store.
The Mapping of LDAP attributes to outgoing claim types determines which of the user fields held on the active directory server are transmitted to the service provider. The name of the field on the right hand side does not matter, but you should try to pick something semantically close to the LDAP Attribute.
- You must include the Name ID as an Outgoing Claim Type, and it should be mapped to the User-Principal-Name - this is the username, and without this PhixFlow will reject the SAML login request.
- The mapping for user groups is not obvious, and is also mandatory for the SAML login request. You should map 'LDAP Attribute Token-Groups - Unqualified Names' to 'Role', as shown in the screenshot below.
- Finally, when configuring the attribute mapping on the Service Provider (PhixFlow) side, make sure to match the domain to the service provider domain(?).
For the remaining LDAP Attributes, you can try out different mappings, to see what they actually contain when sent down to the phixflow application server.
Configure Attribute Map in PhixFlow (Service Provider)
As part of the SAML / Single sign-on process, the identity provider sends details of the user who is logging in as a set of name/value pairs. An Attribute Map defines how PhixFlow maps the identity provider's attribute names to the names required by PhixFlow.
Each of the Outgoing Claim Types has a unique urn, which can be found under ADFS -> Service -> Claim Descriptions. E.g. Name ID has a urn (Claim Type) of http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier. This Claim Type should go into the attribute mapping in phixflow-login.
Alternatively, you may inspect phixflow.log to see what attributes are being sent down.
| Info |
|---|
Turn on debug logging in logback.xml for com.accipia.centerview.util.security, the log file will show the attributes and values that are available. |
As long as you have correctly mapped the username and domain and the rest of the SAML setup is correct, you should see lines like:
| Code Block |
|---|
2019-08-21 16:28:38,839 DEBUG [http-nio-8080-exec-3] o.s.s.s.w.WebSSOProfileConsumerImpl [WebSSOProfileConsumerImpl.java:237] Including attribute http://schemas.microsoft.com/ws/2008/06/identity/claims/role from assertion _8c9686b7-9029 |
The urn is the same as the urn given in the list of Claim Descriptions.
Back in phixflow-login.xml, Find the attribute map section:
...
Change the domain to the value you want to be displayed as the domain for any users who login using SAML (it is hard-coded).
Change the property values to match the attributes supplied by the identity provider.
...
.
Configure SAML User Details Service
...