You can set up access to PhixFlow either through PhixFlow Users, 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:
Table of Contents | ||
---|---|---|
|
Configure phixflow-login.xml
Configuration details for SAML are configured in the file phixflow-SAML.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).
Create SAML reference
To create a reference to SAML, update the section in the example file to:
Code Block | ||
---|---|---|
| ||
<!-- example of a SAML authentication provider
-->
<security:authentication-provider ref="samlAuthenticationProvider"/> |
Add key store details
In order to SAML A keystore must be included at [tomcat root]/webapps/phixflow/WEB-INF/classes/keystore/<<youtkeystorename.jks>>. Instructions for creating a keystore can be seen at Configure Tomcat For HTTPS. The configuration files included assume that the alias of the key is "PhixflowSAML", if you wish to use another alias you will have to replace all instances of "PhixflowSAML" with your alias. Below is an example of a keystore:
Code Block | ||
---|---|---|
| ||
<!-- An Example of a KeyStore File -->
<bean id="keyManager"
class="org.springframework.security.saml.key.JKSKeyManager">
<constructor-arg
value="classpath:keystore/samlKeystore.jks" />
<constructor-arg type="java.lang.String"
value="<<KeyStorePassword>>" />
<constructor-arg>
<map>
<entry key="PhixflowSAML" value="<<KeyPassword>>" />
</map>
</constructor-arg>
<constructor-arg type="java.lang.String"
value="PhixflowSAML" />
</bean> |
For the most basic configuration just replace the "/samlKeystore.jks" with your keystore, "<<KeyStorePassword>>" with the password to the keystore and then "<<KeyPassword>>" with the password for the key.
Metadata generator
...
...
Firstly replace the value of the entityId with something unique so that the service provider will correctly be associated with only you.
Code Block | ||
---|---|---|
| ||
<property name="entityId"
value="urn:test:phixflow:phixflow" /> |
Secondly replace the values under entityBaseURL to point at your tomcat configuration.
Code Block | ||
---|---|---|
| ||
<property name="entityBaseURL"
value="http(s)://<<hostname>>:<<port>>/Phixflow" /> |
For example if you are using the default tomcat configuration :
Code Block | ||
---|---|---|
| ||
<property name="entityBaseURL"
value="http://localhost:8081/Phixflow" /> |
or alternatively using a tomcat configured for HTTPS:
Code Block | ||
---|---|---|
| ||
<property name="entityBaseURL"
value="https://localhost:8443/Phixflow" /> |
Metadata configuration
The next step is to configure PhixFlow so that it knows where to look for both identity provider and service provider metadata. First we look at identity provider metadata:
With the default configuration the identity provider metadata is saved as a file under the metadata folder named "idp-metadata.xml". If you wish to use a different file name just change it here.
Code Block | ||
---|---|---|
| ||
<bean
class="org.opensaml.saml2.metadata.provider.FilesystemMetadataProvider">
<constructor-arg
<value type="java.io.File">classpath:metadata/idp-metadata.xml</value>
</constructor-arg>
<property name="parserPool" ref="parserPool" />
</bean> |
Next comes the service provider metadata. If you are using the metadata generator leave this next section commented out as if you do not PhixFlow will not start as it will be looking for a file that does not exist. Below is a completed service provider bean which will be broken down in more detail lower down.
Code Block | ||
---|---|---|
| ||
<bean
class="org.springframework.security.saml.metadata.ExtendedMetadataDelegate">
<constructor-arg>
<bean
class="org.opensaml.saml2.metadata.provider.ResourceBackedMetadataProvider">
<constructor-arg>
<bean class="java.util.Timer" />
</constructor-arg>
<constructor-arg>
<bean class="org.opensaml.util.resource.ClasspathResource">
<constructor-arg value="/metadata/sp-metadata.xml" />
</bean>
</constructor-arg>
<property name="parserPool" ref="parserPool" />
</bean>
</constructor-arg>
<constructor-arg>
<bean
class="org.springframework.security.saml.metadata.ExtendedMetadata">
<property name="local" value="true" />
<property name="alias"
value="urn:test:phixflow:phixflow" />
<property name="signingKey" value="PhixflowSAML" />
<property name="encryptionKey" value="PhixflowSAML" />
</bean>
</constructor-arg>
</bean> |
The first configurable part of the service provider metadata is the file name. By default this is expecting a file named "sp-metadata.xml" under the metadata folder. If you wish to use another file name change it here :
Code Block | ||
---|---|---|
| ||
<constructor-arg value="/metadata/sp-metadata.xml" /> |
Next we have the Extended metadata configuration. For the simplest setup all that needs changing here is the alias needs to be updated to the entity ID that you specified earlier. If you are using the recommended Key name of "PhixflowSAML" then no further configuration is required. If you are not using this key name then you will have to replace the PhixflowSAML with your keyname under the "signingKey" and "encryptionKey" sections.
Code Block | ||
---|---|---|
| ||
<!-- The following sections must be uncommented to enable SAML Login -->
<!--
<security:http entry-point-ref="samlEntryPoint"
pattern="/saml/**" use-expressions="false">
<security:intercept-url pattern="/**" access="ROLE_USER" />
<security:custom-filter after="BASIC_AUTH_FILTER" ref="samlFilter" />
</security:http>
<import resource="phixflow-SAML.xml/>
--> |
After this there is only one remaining section which contains a line that needs to be included when you wish to generate your metadata, but commented out if you do not wish to generate your own metadata. This line is as follows :
Code Block | ||
---|---|---|
| ||
<!--<security:custom-filter before="FIRST" ref="metadataGeneratorFilter"/>--> |
so to generate your metadata the configuration should look like
Code Block | ||
---|---|---|
| ||
<!-- with the exception of the metageneratorfilter line the following must be uncommented to enable SAML login -->
<security:http entry-point-ref="samlEntryPoint"
pattern="/SAMLLogin" use-expressions="false">
<security:intercept-url pattern="/**"
access="ROLE_USER" />
<security:custom-filter
after="BASIC_AUTH_FILTER" ref="samlFilter" />
<!-- uncomment the line below to generate your service provider metadata -->
<security:custom-filter before="FIRST" ref="metadataGeneratorFilter"/>
</security:http> |
and if you do not need to generate your metadata the configuration should look like
Code Block | ||
---|---|---|
| ||
<!-- with the exception of the metageneratorfilter line the following must be uncommented to enable SAML login -->
<security:http entry-point-ref="samlEntryPoint"
pattern="/SAMLLogin" use-expressions="false">
<security:intercept-url pattern="/**"
access="ROLE_USER" />
<security:custom-filter
after="BASIC_AUTH_FILTER" ref="samlFilter" />
<!-- uncomment the line below to generate your service provider metadata -->
<!--<security:custom-filter before="FIRST" ref="metadataGeneratorFilter"/>-->
</security:http> |
Other configuration
After this in order to enable SAML all that is required is to uncomment the following sections with a few exceptions. First uncomment all of the text listed below:
Code Block | ||
---|---|---|
| ||
<!--
<security:http entry-point-ref="samlEntryPoint"
pattern="/saml/**" use-expressions="false">
<security:intercept-url pattern="/**"
access="ROLE_USER" />
<security:custom-filter
after="BASIC_AUTH_FILTER" ref="samlFilter" />
</security:http>
<import resource="phixflow-SAML.xml/>
--> |
Metadata Generation
After completing this initial setup. It's time to generate the metadata. To do this setup the login configuration form to have a log in with SAML button and click it. You should be redirected to your identity provider and rejected, but your metadata will be generated by this step. Next log in as a local user then go to <<yourhost>>/Phixflow/saml/metdata in order to download an XML file of your metadata.This will need to be given to your identity provider to log in. In order to simplify configuration it is recommended to save this as metadata/sp-metadata.xml
At this point please refer to the Phixflow Active Directory Setup section for more information on how to connect your identity provider provided groups to PhixFlow groups. The "default domain" section is not needed.
Logging in as a SAML user
To log in, users simply have to select a login option with SAML and click on the login button where they will be redirected to the identity provider to enter their credentials. If the login form configuration has been set to automatically log in with SAML, then they will see this screen and will instead be redirected straight to the identity provider.
Troubleshooting
Enhanced diagnostics can be generated by adding the lines
Code Block |
---|
#Log information about the SAML login framework
log4j.logger.org.springframework.security.saml=DEBUG
log4j.logger.org.opensaml=DEBUG
log4j.logger.PROTOCOL_MESSAGE=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.
...
1.1 Specify the Authentication Manager
Edit the authenticationManager
section of phixflow-login.xml to add a samlAuthProvider
.
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> |
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> |
Tip |
---|
We recommend that you keep the |
1.2. Set up User Accounts
For mixed users in your SAML authentication system, create PhixFlow user accounts. Mixed users are authenticated by SAML but their access privileges are managed using User Groups in PhixFlow; see User.
1.3. Configure Login Forms
Edit the loginConfiguration
section of phixflow-login.xml to define the login form options (local, single sign-on, active directory). These specify what the user sees on their PhixFlow login screen. 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 details.
1.4. Enable a Cookie Filter
Edit the sameSiteCookieFilter
section of phixflow-login.xml to set the SameSite
property on the session cookie. This is required to initiate login from the PhixFlow login form.
Edit it to look like this:
Code Block | ||
---|---|---|
| ||
<bean id="sameSiteCookieFilter"
class="com.accipia.centerview.web.filter.SameSiteCookieFilter">
<property name="cookies">
<props>
<prop key="JSESSIONID">None</prop>
</props>
</property>
</bean> |
1.5. Enable SAML Beans
Edit the beans profile section section of phixflow-login.xml. Edit the 2 blocks that disable the options that are only required when PhixFlow is managing user authentication.
Find these lines:
Code Block |
---|
<!-- comment out to enable saml / single sign-on -->
<beans profile="saml"> |
Remove them or comment them out:
Code Block |
---|
<!-- comment out to enable saml / single sign-on -->
<!--
<beans profile="saml">
--> |
Find these lines, near the end of the file:
Code Block |
---|
<!-- comment out to enable saml -->
</beans> |
and remove them or comment them out:
Code Block |
---|
<!-- comment out to enable saml -->
<!--
</beans>
--> |
1.6. Configure the keyManager
Edit the keyManager
section of phixflow-login.xml to specify the keystore.
Tip |
---|
SAML integration requires one or more public/private keys. Keys are stored in a Java keystore file. For information about configuring a keystore, see Configure Tomcat For HTTPS. |
The minimum updates required are to set:
-
"file:/.../keystore.jks"
to your keystore "KeyStorePassword"
to your keystore password"keyPassword"
to your key password"keyAlias"
to an key entry name that exists in the keystore.-
"defaultKeyAlias"
to a key that exists. If the key does not exist PhixFlow will report an error when a user attempts to log in.
Example of a keyManager
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> |
Warning |
---|
For security reasons, access to phixflow-login.xml and to keystore.jks should be read-only to the Tomcat user or user account. It must be unreadable by all other users. |
1.7. 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 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.
Edit the Context Provider
section of phixflow-login.xml.
- Delete the original
contextProvider
- Uncomment the reverse proxy version
- Change the
serverName
,serverPort
andcontextPath
to match the public view.
Find these lines:
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" /> |
Example of Context Provider
configuration (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> |
1.8. Configure the Metadata Generator
SAML communication is via an exchange of metadata between:
- the SAML identity provider, such as Active Directory Federation Services (ADFS)
- and a SAML Service Provider, in this case PhixFlow
Each party generates metadata to describe how to connect to it. 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.
Edit the metadataGeneratorFilter
section of phixflow-login.xml and set:
entityId
to a value that globally identifies the PhixFlow instanceentityBaseURL
to a 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.
This is the metadataGeneratorFilter
section before configuration:
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> |
1.9. Configure the Identity-Provider Metadata Provider
The identity provider metadata provider defines how PhixFlow installs and handles the identity-provider's metadata. For example, PhixFlow can either enable or disable additional security checks.
- Save the identity provider's metadata file in a convenient folder. This example assumes it is in the metadata directory, which is alongside the phixflow-login.xml file. To put the metadata in an unrelated directory, you can specify a path using:
either classpath:dir1/file
This refers to a file in directory dir1 under the webapp's classpath. This is ambiguous as it can meanwebapp/WEB-INF/classes/dir1
andtomcat/lib/dir1
.- or
file:/dir1/file
This refers to the top-level directory/dir1. W
ithout the forward slash / it refers to dir1 under the current directory, which is normally the Tomcat home directory.
- Edit the
metadata provider
section of phixflow-login.xml. - Change
metadata/idp-metadata.xml
to the location of the identity provider's metadata file.
This is the metadata provider
section of phixflow-login.xml.
Code Block | ||
---|---|---|
| ||
<!-- file-base identity-provider (idp) metadata provider - this defines the metadata for a single identity provider -->
<bean id="idpFileMetadataProvider" class="org.springframework.security.saml.metadata.ExtendedMetadataDelegate">
<constructor-arg>
<bean class="org.opensaml.saml2.metadata.provider.FilesystemMetadataProvider">
<constructor-arg>
<value type="java.io.File">classpath:metadata/idp-metadata.xml</value>
</constructor-arg>
<property name="parserPool" ref="parserPool" />
</bean>
</constructor-arg>
<constructor-arg>
<bean class="org.springframework.security.saml.metadata.ExtendedMetadata">
<!-- add properties to extend the metadata -->
<!-- see https://docs.spring.io/spring-security-saml/docs/current/reference/html/configuration-metadata.html for values -->
<property name="local" value="false" />
</bean>
</constructor-arg>
<property name="metadataTrustCheck" value="true" />
</bean> |
Step 2 Generate Service Provider Metadata
When phixflow-login.xml is configured, you can generate metadata for the PhixFlow server.
2.1 Attempt to login using SAML / Single Sign-on.
The login attempt generates metadata. However the login itself will fail because you have not yet installed PhixFlow's metadata in the identity provider.
2.2 Login as a local user with administration rights.
You need to be logged in in order to download the metadata file.
2.3 Download the metadata file.
Browse to the directory phixflow/saml/metadata
, for example https://myhost.com/phixflow/saml/metadata
.
2.4 Save the resulting metadata file.
Step 3 Install the Service Provider Metadata in the Identity Provider
The method depends on your Identity Provider. For a Windows Server ADFS identity provider, use the following steps:
3.1 Log into the Windows ADFS Server.
3.2 Run the command mmc.exe
to open the windows server management console.
3.3 Go to File → Add/Remove Snap in and add ADFS.
3.4 In the tree view displayed on the left, open Relying Party Trusts.
3.5 In the menu on the right, click Add Relying Party Trust.
3.6 Select Claims aware.
3.7 Select import data about the relying party from a file.
3.8 Browse to the service provider metadata xml file created in the previous step and select it.
3.9 Name the new relying party.
3.10 Select 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.
Step 4 Configure Attribute Mapping on the Identity Provider
The method depends on your Identity Provider. For a Windows Server ADFS identity provider, use the following steps. You must complete these steps immediately after installing the service provider metadata in the identity provider.
4.1 Select the relying party trust that has been created.
4.2 In the menu on the right, click Edit Claim Issuance Policy to open an empty Issuance Transform Rules list.
4.3 Click on Add Rule.
4.4 For the claim rule template, select Send LDAP Attributes as Claims.
4.5 On the next screen, give the claim rule a name, and select Active Directory as the attribute store.
4.6 Map the LDAP Attributes to Outgoing Claim Types. This mapping determines which user fields are sent from the Active Directory server to PhixFlow.
- You must map the Name ID, which is the user name. Without this PhixFlow will reject the SAML login request.
- You must map Token-Groups - Unqualified Names to Role, as shown in the screenshot below. The mapping for user groups is mandatory for the SAML login request.
- Map any remaining LDAP attributes that you require. You may need to test different mappings, to identify what information is sent to the PhixFlow server.
When you map an LDAP Attribute to an Outgoing Claim Type, enter a Name ID. You can specify any name for an outgoing claim type. However, for clarity the name should be similar to the LDAP Attribute.
Tip |
---|
When you configure the attribute mapping on PhixFlow (the service provider) in Step 5, below, remember to match the domain to the service provider domain. |
Step 5 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.
5.1 Each of the Outgoing Claim Types has a unique URN, which can be found under ADFS → Service → Claim Descriptions. For example Name ID
has a URN claim type of http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
. Add this claim type to the attribute mapping in phixflow-login.xml.
Alternatively, look in the phixflow.log
file to see what attributes are being sent; see Server Log Files.
Info |
---|
Turn on debug logging in logback.xml for |
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 these:
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.
5.2 Back in phixflow-login.xml, find the attribute map section:
Code Block | ||
---|---|---|
| ||
<!-- map external user attribute names to saml response attribute names -->
<bean id="example1SamlAttributeMap" class="com.accipia.centerview.util.security.UserDetailsMapper" >
<!-- this will be used to mark external users in the database as from this login provider / domain -->
<property name="domain" value="mysaml.org" />
<property name="username" value="urn:oid:0.9.2342.19200300.100.1.1" />
<property name="firstname" value="urn:oid:2.5.4.42" />
<property name="lastname" value="urn:oid:2.5.4.4" />
<property name="phonenumber" value="urn:oid:2.5.4.20" />
<property name="company" value="urn:oid:2.5.4.10" />
<property name="department" value="urn:oid:2.5.4.11" />
<property name="email" value="urn:oid:0.9.2342.19200300.100.1.3" />
<property name="groups" value="1.2.840.113556.1.2.613" />
</bean> |
5.3 Create a new map by copying the example and changing its ID.
5.4 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).
5.5 Change the property values to match the attributes supplied by the identity provider.
5.6 You can optionally add property name
attributes to configure:
Anchor | ||||
---|---|---|---|---|
|
- mixed users
By default all users of this domain are external users, PhixFlow does not manage authentication or authorisation. If you want PhixFlow to manage the authorisation for users who have SAML authentication in this domain, add the line:<property name="authenticationOnly" value="true" />
- single (global) logout
By default, PhixFlow uses local logout. When a user logs out the PhixFlow session is terminated but
- the SAML identity provider is not notified
- the user is not logged out of their identity provider session.
Alternatively, single logout terminates the PhixFlow session and logs out of the identity provider. Depending on your identity provider configuration, this may include terminating sessions with other identity providers. To apply single logout to all users in this domain, add the line:
<property name="globalLogout" value="true" />
Step 6 Configure SAML User Details Service
The user details service is responsible for mapping the working out which attribute map to use, based on the identity provider's entity ID.
6.1 Find the following section:
Code Block | ||
---|---|---|
| ||
<bean id="samlUserDetailsService"
class="com.accipia.centerview.util.security.ResolvingSAMLUserDetailsService" >
<property name="externalUserLoader" ref="externalUserLoader" />
<property name="mappers">
<util:map>
<!-- the key is the identity provider's entity id: add an entry for each external identity-provider -->
<entry key="exampleEntityId">
<ref bean="example1SamlAttributeMap" />
</entry>
</util:map>
</property>
</bean> |
6.2 Change exampleEntityId to match the value of entityID sent by the identity provider. This should be in the metadata provided, but you can also see it by turning on logging as in the previous section.
6.3 Change example1SamlAttributeMap to reflect the id of the attribute map created in the previous section.
Step 7 Configure External Groups
Each PhixFlow user group defines a list of external group names which grant access rights (the rights to view, activate, change, delete objects) conferred by membership of those user groups. A user who logs in using SAML must be in at least one external group listed on one user group.
System Configuration also defines a list of external login groups. For a user to login, either the list must be empty or the user must be in at least one of the groups listed.
A user who successfully logs in using SAML / Single Sign-on is considered a member of each user group, and has the access rights of that user group, if the user is a member of any of the user group's External Login Groups.
External group names may contain references to the current instance name as '{instance}' e.g. 'ADMIN_{instance}'. This allow groups to be moved from one instance to another and for each instance to use it's own set of external group names.
See Configure Groups for External Login for how to configure External Login groups.
Troubleshooting
When troubleshooting the configuration, you can include additional diagnostics information in logs, by adding lines to logback.xml.
Option 1: more debug information
Code Block |
---|
<logger name="org.springframework.security" level="error" />
<logger name="com.accipia.centerview.util.security" level="debug" /> |
Option 2: full debug information
Code Block |
---|
#Log information about the SAML login framework
<logger name="org.springframework.security" level="error" />
<logger name="com.accipia.centerview.util.security" level="debug" />
<logger name="org.springframework.security.saml" level = "debug" />
<logger name="org.opensaml" level="debug" /> |
Tip |
---|
With additional debug information, PhixFlow will generate very large log files. Remember to remove these lines when your configuration is working and you no longer need the debug information. For information about accessing logs, see Server Log Files. |