Security Assertion Markup Language (SAML) is an XML standard that allows secure web domains to exchange user authentication and authorization data. Using SAML, an online service provider can contact a separate online identity provider to authenticate users who are trying to access secure content. SAML enables cross-domain single sign-on, allowing users to access other sites without the need for re-authentication. Communifire version 4.7 and above supports SAML 2.0.
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.
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 explains how to enable single sign-on with Communifire and Microsoft Active Directory Federation Services (ADFS).
Note: Both the Service provider (your Communifire site) and Identity provider must run on HTTPS.
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.
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.
"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 'firstname.lastname@example.org' 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.
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