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.
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.
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 in Control Panel > People > Manage People > Add User . The Communifire username you create must match the username in Active Directory.
You can use our REST API to import users.
Adding Communifire 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
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 saml.config of Communifire application:
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:
<source name="ComponentSpace.SAML2" switchValue="Verbose">
<!-- Ensure IIS has create/write file permissions for the log folder. -->
<add name="TextWriter" type="System.Diagnostics.TextWriterTraceListener" initializeData="d:\logs\adfs-log.log"/>
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.
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:
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 'email@example.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 "ServiceProvider >> Name" field in saml.config should be same:ADFS setting screenshot:Saml config screenshot:
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.
"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 in saml.config and in ADFS management console match.
The identity provider doesn't allow the response to be signed.
Set WantSAMLResponseSigned to false in SAML config.
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. For ADFS, the saml.config file should look like this:
<?xml version="1.0" ?>
<!-- ADFS -->
6. 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.
7. Restart the app pool after making changes.
Hi Vivek, Just wondering if we have to purchase specific domain for communifire to work with ADFS SSO, also we got ADFS server in our side. how can I integrate with communifire.
If you are self-hosting, then ADFS SSO via SAML is not required, but if your community is hosted with us, you will need to use SAML and ADFS so that it connects with your AD store. It is recommended that you get a separate domain.
Thanks for the quick response, Vivek.
Hi Vivek, we are using domain as <company_name>.communifire.com. Is that right or we have to go for separate domain. Also for the certificate, do we require any certificate from your side to be imported on ADFS server or not.
You can use <company_name>.communifire.com, <subdomain>.<company_name>.com, or <company_name>.com. If you use .communifire.com you will need a certificate file from us. Submit a private case to request a custom domain and ssl info.
I've gotten communifier to authenication via SAML2 to Azure AD except after it authenticates and replies back to /SAML/AssertionConsumerService.aspx page, CF reports the following error. "Error creating your Active Directory account. Please contact your Site Administrator". I know the username passed back from Azure is the full email address. What can be done?
Can you look at the exception log and the windows event log? If there are any error messages related to SAML can you create a new support case with the error details? Regardless of the errors, can you create a new support case with screenshots of your dynamic properties SAML configuration and attach your saml.config file?
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