Communifire supports Microsoft Active Directory Federation Services (ADFS) / SAML 2.0 single-sign on (SSO). This page covers information about ADFS / SAML 2.0 SSO, walks you through how to configure ADFS / SAML 2.0 SSO on your intranet, and provides solutions to common issues. For more information or assistance from the Axero team, submit a private case.
On visiting your intranet, users will be re-directed to your organization log in page.
Logging in with Communifire credentials
You can allow users to log in using Communifire credentials. Set System Properties > EnableAutoLoginViaSaml to false. When this property is set to false, users will see the Communifire login page. Users can either log in with Communifire credentials or click Login via SAML to sign in using ADFS/SAML credentials.
Session expiration
By default, the session expires 30 days from the date of log in. You can control when the session expires using System Properties > FormsAuthPersistentCookieTimeOutInMinutes. By default this value is set to 43200, which is 30 days.When the property MakePermanentCookieForThirdPartyLogin is set to true, a cookie is generated for the user that expires based on the value found in FormsAuthPersistentCookieTimeOutInMinutes. If MakePermanentCookieForThirdPartyLogin is set to false, the user will be logged out when the browser is closed.
Return to top
On the mobile app, users will be re-directed to your organization log in page after entering the site URL.
Logging in to app with Communifire credentials
You can allow users to log in to the app using Communifire credentials. Set System Properties > EnableAutoLoginViaSaml to false. When this property is set to false, users will see the Communifire login page after entering the site URL. Users can either log in with Communifire credentials or click Active Directory Login to sign in using ADFS/SAML credentials.
A user is created in Communifire when the user logs in for the first time. You can add users to Communifire before they log in using the methods below.
Bulk import users
Pre-populate users before ADFS/SAML setup or launch with Bulk Import Users . The Communifire usernames you create must match the usernames in Active Directory.
Add users
Add users in Control Panel > People > Manage People > Add User . The Communifire username you create must match the username in Active Directory.
REST API
You can use our REST API to import users.
Adding administrator accounts
If Communifire administrator accounts are created before Active Directory is set up and the Communifire usernames match Active Directory usernames, the administrator accounts will sync with the corresponding Active Directory accounts. If not, you will need to re-configure permissions for the admin Active Directory accounts and remove the previous Communifire administrator accounts.
Any data can be imported from Active Directory, as long as there are corresponding User Profile Fields in Communifire. Attribute mappings must be added to Control Panel > System > SAML Single Sign On > Mapping. Enter the outgoing claim type as the property name in Communifire. See the table below for common fields to import.
Note: The department field in Communifire is a Picklist Field . When departments are imported from ADFS, the departments are created as new options in the picklist field.
You can also use SQL or our REST API to import user data into Communifire.
User data such as name, address, state, etc. is updated in Communifire every time a user logs in. User data is not updated if the user checks "Remember Me" on the log in page or if System Properties > EnableAutoLoginViaSaml is set to true.
When a user is disabled in Active Directory, this information is not sent to Communifire. You can Delete User and delete their content or re-assign their content to another user or to the system anonymous user. You can also Ban User , which will prevent the user from logging in, but will retain their content.
This guide walks you through how to enable ADFS single sign-on in Communifire. Client-side setup is estimated to take 2 hours and Axero team setup is estimated to take 1-2 hours. The time to set up SSO can vary based on how long it takes to set up internal systems and to provide the Axero team with required information. The total time for setting up SSO may take up to 1-2 business days.
Once you complete the guide, ADFS SSO will be active on your intranet. If you run into any issues, submit a case here for assistance.
Note: Both the Service provider (your Communifire site) and Identity provider (ADFS) must run on HTTPS.
On the Welcome page, choose Claims aware and click Start.Note: If you don't see Claims Aware section, click Start directly.
Click Add Rule
...
More properties:
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]=> add(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ManagerDN"), query = ";Manager;{0}", param = c.Value);
c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]&& c2:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ManagerDN"]=> issue(store = "Active Directory", types = ("Manager"), query = "(distinguishedName={1});samaccountname;{0}", param = c1.Value, param = c2.Value);
In ADFS management console:
In Power Shell:
Run the following command:
Set-ADFSRelyingPartyTrust -TargetName <RelyingPartyTrustName> -SamlResponseSignature MessageAndAssertion
Replace <RelyingPartyTrustName> with your Relying Party Trust name. You can find your Relying Party Trust name in the Relying Party Trusts section of the ADFS management console.
Identity Provider Configuration
If you have installed ADFS properly, the following URL should give you a valid response in XML format: https://win-chqnt9vspbj.adfs.test/FederationMetadata/2007-06/FederationMetadata.xml(Replace https://win-chqnt9vspbj.adfs.test with your Identify Provider.)
To get the URL of your identity provider, go to ADFS console and click Edit Federation Service Properties.
Now restart the server.
Next you need to collect the following three values from ADFS FederationMetadata xml https://<adfsdomain>/FederationMetadata/2007-06/FederationMetadata.xml
In the image below, the highlighted portion is the Partner IDP.
Following is the value for "SingleSignOnServiceUrl" and "SingleLogoutServiceUrl" from that xml:
Those three values need to be entered in Communifire in Control Panel > System > Single Sign On > SAML. (See the Configure Communifire section.)
Setup Confirmation
If your setup was done correctly, you will see the page below at https://WIN-CHQNT9VSPBJ.adfs.test/adfs/ls/. (Replace https://WIN-CHQNT9VSPBJ.adfs.test with your Identify Provider.)
If you don't see the page above, check your Windows Event Logs.
If you want to enable the SAML trace, add the following code in web.config:
<system.diagnostics> <trace autoflush="true"> <listeners> <add name="TextWriter"/> </listeners> </trace> <sources> <source name="ComponentSpace.SAML2" switchValue="Verbose"> <listeners> <add name="TextWriter"/> </listeners> </source> </sources> <sharedListeners> <!-- Ensure IIS has create/write file permissions for the log folder. --> <add name="TextWriter" type="System.Diagnostics.TextWriterTraceListener" initializeData="d:\logs\adfs-log.log"/> </sharedListeners> </system.diagnostics>
The above trace will help you to diagnose an error if it originates from the ADFS setup. initializeData is the path where logs will be written. Make sure that the path you specify has write access to your web application.
Check that the server where ADFS is installed has the time set correctly. Incorrect server time can cause ADFS to malfunction.
SAML SSO and auto login are now enabled.
How to disable SSO auto login
To disable SSO auto login, go to Control Panel > System > System Properties and set EnableAutoLoginViaSaml to false.
How to configure attribute mappings
In Control Panel > System > Single Sign On, click on the Data Mapping tab. Then select SAML in the Type menu. If you added more than the basic set of properties, you can add those here.
Advanced Configuration
When a user logs in using SAML, Communifire synchronizes user data with the Single Sign-On (SSO) system. This process is automatic by default. You have the flexibility to customize this integration by adjusting system properties:
This property determines if SAML should create a new user automatically when a matching one isn't found during login. If the property is set to true, the system will automatically create a new user. Setting the property to false ensures that user accounts are not automatically created during SAML logins, providing a controlled approach to user management.
This option determines whether Communifire will verify if the user logging in via SAML has a matching email address for the user with the same username. By setting the property to true, Communifire will enforce the verification step. This added layer of security helps in scenarios where precise user validation is crucial. When this property is set to false, this verification step will be skipped.
This property controls whether Communifire will automatically update user data from the SSO system. By default, this property is set to true, allowing for automatic updates, which ensures the user information is up-to-date. To prevent automatic updates, set the property to false.
You can sync user roles from ADFS to Communifire with the help of rules defined in ADFS.
Configure a custom rule
Another way to sync user roles is with Send Claims Using a Custom Rule as the rule template. This approach gives you the option to set a condition, and when it is true, it will issue a claim and return to the Relying party (Communifire).
Claim rule language is used to define the rule. See this guide for information about claim rule language.
Example claim rule:
Notes:
Assign Users to Spaces According to their Roles
Once roles are synced with Communifire, you can use User Space Assignment Rules to add users to specific spaces based to their roles.
"The SAML encryption isn't encrypted."
Please check that the encryption certificate is configured in the Relying Party Trust.
"No AssertionConsumerService is configured on the relying party trust 'urn:abc:xyz' that is a prefix match of the AssertionConsumerService URL 'http://yourwesbite/SAML/AssertionConsumerService.aspx' specified by the request."
Check urn and AssertionConsumerService in both ADFS management and Communifire.
On login: "Error creating your Active Directory account. Please contact your Site Administrator." In the exception log: "No attributes returned from Active directory. Please go to 'Active Directory Users and Computers' on ADFS Server, select the 'user@xyz.com' user, go to 'Account' tab and check the 'User logon name' information is present there."
The attributes could be empty in Active Directory for that user:
Error on ADFS login page:"Exception details: Microsoft.IdentityServer.Web.InvalidScopeException: MSIS7007: The requested relying party trust 'https://yourcommunity/' is unspecified or unsupported. If a relying party trust was specified, it is possible that you do not have permission to access the trust relying party. Contact your administrator for details."Solution: The name present in urn field in ADFS relying partner trust and in Communifire should match.ADFS setting screenshot:In Communifire, check Control Panel > System > Single Sign On > SAML > Relying Party Trust Identifier.
Users are able to login via ADFS/SAML using Chrome and Firefox, but not Internet Explorer.
Make sure that the SPN is configured properly for your ADFS service account. A service principal name (SPN) is a name that uniquely identifies an instance of a service. There should be an SPN registered for your ADFS service account. To verify this, refer to the following instructions:
"Microsoft.IdentityServer.RequestFailedException: MSIS7065: There are no registered protocol handlers on path /adfs/ls/ to process the incoming request.at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)"
Make sure the following two properties have https protocol which you added in ADFS configuration.
SingleSignOnServiceUrl="https://qaadfs.communifire.com/adfs/ls/"SingleLogoutServiceUrl="https://qaadfs.communifire.com/adfs/ls/"
"SAML authentication error: No attributes returned from Active directory."
Go to 'Active Directory Users and Computers' on ADFS Server, select the 'Administrator@adqa.communifire.com' user, go to 'Account' tab, and check the 'User logon name' information is present there.
Go AD controller and edit the user's logon name and enter a valid value.
"There is no SAML configuration."
Enable SAML trace log via adding diagnostic element (as described in the Configure ADFS section) then check the error in the logs. The certificate path may be wrong, or there may be duplicate certificate locations in both Partner and Service provider.
"There is no such relying partner."
Make sure the Relying Partner Trust Identifier in Communifire and in ADFS management console match.
The identity provider doesn't allow the response to be signed.
Set WantSAMLResponseSigned to false in SAML config.
Issue:
Solution:
We need to check multiple things here:
1. In IIS, Anonymous Authentication > Anonymous user identity should be set to Application pool identity.
2. Your site's application pool should have Read permission for the private keys of your site's certificate:
3. The certificates should be exported from the Certificate Manager tool (both PFX and CER):
4. In IIS, Process Model > Identity should be ApplicationPoolIdentity.
5. In Communifire > Control Panel > System > System Properties, the following System Properties should be set as follows:
There is no need to set the identity to localsystem.
6. Restart the app pool after making changes to system properties.
ADFS Logs: System.UriFormatException: Invalid URI: The format of the URI could not be determined.
Make sure the domain name is entered in "Relying Party Identifiers" instead of urn:domain.
No AssertionConsumerService is configured on the relying party trust 'microsoft:identityserver:xxxxxxxxxxxxxxxxxxxx' that is a prefix match of the AssertionConsumerService URL
Make sure that the relying party trust identifier has the "SAML Assertion Consumer" Endpoint as https://{domain}/SAML/AssertionConsumerService.aspx
Example: https://myintranet.communifire.com/SAML/AssertionConsumerService.aspx
is requesting access to a wiki that you have locked: https://my.axerosolutions.com/spaces/5/communifire-documentation/wiki/view/2207/adfs-saml-2-0-sso?locale=en-US%25252525252525252525252525252525252525252525252525252f1%25252525252525252525252525252525252525252525252525252f%25252525252525252525252525252525252525252525252525253fact%25252525252525252525252525252525252525252525252525253d1%25252525252525252525252525252525252525252525252525252f%25252525252525252525252525252525252525252525252525253fSpaceID%25252525252525252525252525252525252525252525252525253d5
Your session has expired. You are being logged out.