ADFS / SAML 2.0 SSO | Communifire Documentation

Upon visiting your intranet, users will be redirected to your organization's login page.

Logging in with Axero credentials

You can allow users to log in using Axero credentials. Set System Properties > EnableAutoLoginViaSaml to false. When this property is set to false, users will see the Axero login page. Users can either log in with Axero 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 login. 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

After entering the site URL on the mobile app, users will be redirected to your organization's login page.

Logging in to the app with Axero credentials

You can allow users to log in to the app using Axero credentials. Set System Properties > EnableAutoLoginViaSaml to false. When this property is set to false, users will see the Axero login page after entering the site URL. Users can either log in with Axero credentials or click Active Directory Login to sign in using ADFS/SAML credentials.

Return to top

Axero creates a user when the user logs in for the first time. However, you can add users to Axero before they log in using the methods below.

Bulk import users

Pre-populate users with Bulk Import Users before ADFS/SAML setup or launch. The Axero usernames you create must match those in Active Directory.

Add users

You can add users in Control Panel > People > Manage People > Add User. The Axero 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 Axero administrator accounts are created before Active Directory is set up and the Axero usernames match Active Directory usernames, the administrator accounts will sync with the corresponding Active Directory accounts. If not, you must re-configure permissions for the admin Active Directory accounts and remove the previous Axero administrator accounts.

Return to top

Any data can be imported from Active Directory if there are corresponding User Profile Fields in Axero. Attribute mappings must be added to Control Panel > System > SAML Single Sign On > Mapping. Enter the outgoing claim type as the property name in Axero. See the table below for common fields to import.

Note: The department field in Axero is a Picklist Field. When departments are imported from ADFS, they are created as new options in the picklist field.

You can also use SQL or our REST API to import user data into Axero.

Return to top

User data, such as name, address, state, etc., is updated in Axero every time a user logs in. However, user data is not updated if the user checks "Remember Me" on the login page or if System Properties > EnableAutoLoginViaSaml is set to true.

Return to top

When a user is disabled in Active Directory, this information is not sent to Axero. You can Delete User and their content or re-assign their content to another user or the system anonymous user. You can also Ban User, which will prevent the user from logging in but retain their content.

Return to top

Note: The Service provider (your Axero site) and Identity provider (ADFS) must run on HTTPS.

1. Login to the ADFS Server and search for Server Manager.
   
   
   
   
2. Launch the AD FS Management window.
   
   
3. On the left-hand tree view, right-click Relying Party Trust and select Add Replying Party Trust...
   
   
   

    

4. On the Welcome page, choose Claims aware and click Start.
   
   Note: If you don't see the Claims Aware section, click Start directly.
   
   

5. Choose Enter data about the relying party manually and click Next.
   
   

   

6. Enter the Display Name of your Axero application. You can choose any name and provide the application description under Notes, then click Next.
   
   

   

7. Select AD FS 2.0 profile (this option may also appear as AD FS profile).
   
   Note: You may or may not see this page.
   
   

   

8. To proceed to the next step, you need the public certificate of your Axero application domain. If you have it handy, you can put it on your AD FS server or get it from your browser, as shown below.
   
   When the Axero site is open in your browser, click the lock icon from the search bar and select View certificates.
   
   Note: If you have a custom domain but need Axero to install your SSL certificate, submit it with your saml.config file in your private case here.
   
   
   Select the Details tab and click on Copy to File... button to export the certificate to your desktop.
   
   
9. Browse the public certificate (.cer) of your Axero application and then click Next.
   
   

   

10. Check Enable support for the SAML 2.0 WebSSO protocol.
11. In the Relying party SAML 2.0 SSO service URL textbox, enter the URL: https://cftesting.com/SAML/AssertionConsumerService.aspx. (Replace cftesting.com with your Axero domain.)
    

    

12. Click Next.
13. In the Relying party trust identifier textbox, enter a unique identifier for your provider. We suggest using the pattern urn:company:site for your identifier. Save this identifier as you will use it to configure Axero settings.
    

    

14. Click Add.
15. Click Next.
16. Select Permit all users to access this relying party.
    

    

17. Click Next.
    

    

18. Click Next.
    

    

19. Click Close.
20. In Trust Relationships > Relying Party Trusts, select the trust you created.
21. In the Actions pane, click Edit Claim Issuance Policy.
    
    

    

22. Click Add Rule

    ...

23. In the Add Transform Claim Rule Wizard, select Send LDAP Attributes as Claims in the Claim rule template dropdown menu.
    

    

24. Click Next and complete the Add Rule process.
25. Click on the trust.
26. In the Actions pane, click Edit Claim Rules...
27. In Claim rule name, enter a name for your rule. In our example, we have entered "Active Directory Attributes".
28. In the Attribute Store dropdown menu, select
    
    
29. Under Mapping of LDAP attributes to outgoing claim types, enter the attributes and types as below.
    
    Basic properties:
    
    

    LDAP Attribute	Outgoing Claim Type
    User-Principal-Name	Name ID
    Department	Department
    E-Mail-Addresses	Email
    Given-Name	GivenName
    Surname	Surname
    title	Title
    Telephone-Number	TelephoneNumber
    thumbnailphoto	ThumbnailPhoto

    Note: The department field in Axero is a Picklist Field. When departments are imported from ADFS, they are created as new options in the picklist field.

    More properties:

    LDAP Attribute	Outgoing Claim Type
    Company	Company
    postalCode	PostalCode
    Street-Address	StreetAddress
    Location	Location
    City	City
    State-Or-Province-Name	State
    co	Country
    wwwhomepage	Website

30. Click Finish.
31. Click Add Rule...
32. Select Send Claims Using a Custom Rule.
    
33. Click Next.
34. For Claim name, enter "Set manager domain to claims list."
35. Enter the following in Custom rule:
    

    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);

    
    
36. Click OK.
37. Click Add Rule...
38. Select Send Claims Using a Custom Rule.
39. Click Next.
40. For Claim name, enter "Get manager SAM-Account-Name"
41. Enter the following in Custom rule:
    

    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);
    

    
42. Click OK.
43. Click Apply, then click OK.
    Your claim rules should now look like the image below.

    

44. In the Actions pane of the trust, click Properties.
45. Select the Signature tab.
    

    

46. Click Add.
47. Select the public SSL certificate of your Axero site.
48. Click the Advanced tab.
49. In the Signature hash algorithm dropdown menu, select SHA-256.
    

    

50. Select the Endpoints tab.
    

    

51. Click Add SAML
    
    
    
52. In the Endpoint type dropdown menu, select SAML Logout.
53. In the Binding dropdown menu, select Redirect.
54. In the URL textbox, enter the following URL: https://cftesting.com/SAML/SLOService.aspx. (Replace cftesting.com with your Axero domain).
    
    

    

55. Click OK, then click Apply.
    
    You will now see two endpoints in the Endpoints tab: one for login (Assertion Consumer) and one for logout.
    
    

    

In the ADFS management console:

1. Click Edit.
   

   

2. Check Forms Authentication in both the Extranet and Intranet sections. Leave the other check boxes unchecked.
   
   

   

3. Click OK.

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 the 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

• Partner IDP
• SingleSignOnServiceUrl
• SingleLogoutServiceUrl

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 must be entered in Axero in Control Panel > System > Single Sign On > SAML. (See the Configure Axero 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. Ensure 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.

Return to top

1. Go to Control Panel > System > Single Sign On.
2. Select SAML.
3. Click Save.
4. Enter the following information with the information from the Configure ADFS section:
   
   • Partner Identity Provider URL: Enter the Partner IDP.
   • Single Sign On Service URL: Enter the SingleSignOnServiceUrl.
   • Relying Party Trust Identifier: Enter your intranet URL.
   • Single Logout Service URL: Enter the SingleLogoutServiceUrl.
   • Partner Identity Certificate (CER): Upload the CER certificate file.
5. Click Update.
6. Click System > Advanced System Utilities.
7. Click Restart Site.

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, Axero 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:

• SAMLAutoUserCreation

  This property determines if SAML should create a new user automatically when a matching one isn't found during login. If the property is 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.

• SAMLUserEmailMatch

  This option determines whether Axero 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, Axero will enforce the verification step. This added layer of security helps in scenarios where precise user validation is crucial. This verification step will be skipped when this property is set to false.

• SAMLAutoUserUpdate

  This property controls whether Axero will automatically update user data from the SSO system. By default, it is set to true, allowing automatic updates, which ensures the user information is up-to-date. To prevent automatic updates, set the property to false.

Return to top

You can sync user roles from ADFS to Axero with the help of rules defined in ADFS.

1. Login to the ADFS Server and search for Server Manager.
   
2. Launch the AD FS Management window.
   
3. On the left-hand pane, click on Relying Party Trust
4. Select the trust in the main pane
5. In the Actions pane, click Edit Claim Issuance Policy
   
6. Click Add Rule...
   
7. Select Send Group Membership as a Claim as the rule template
   You can also select Send Claims Using a Custom Rule. See Configure a custom rule.
   
8. Click Next
9. Configure the rule:
   • Claim rule name: Enter a name for the rule (any)
   • User's group: Select the role that you would like to sync with Axero
   • Outing claim type: Select Role
   • Outgoing claim value: Enter the value to send to Axero
     
10. Click Finish
    You'll see the new rule in Issuance Transform Rules

Configure a custom rule

Another way to sync user roles is with Send Claims Using a Custom Rule as the rule template. This approach allows you to set a condition, and when it is true, it will issue a claim and return to the Relying party (Axero).

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 Axero, you can use User Space Assignment Rules to add users to specific spaces based on their roles.

1. Select the space to assign the users to.
2. Select the role the users will have in that space.
3. Enter an email domain.
   • Do not include the www or the at-symbol (@).
   • Enter * for all email domains.
4. Select a role to limit the rule to a group of users.
   • Select All if you do not want to limit by role.
5. Click Save.

Return to top

Admins can enable tracking for SSO login and logout activities using the SAMLTrackingHours system property. 

1. Navigate to Control Panel > System > System Properties.

2. Set the SAMLTrackingHours property to a value above 0 to enable SSO tracking. This value specifies the number of hours that login and logout activities will be logged. The property automatically resets to 0 after the specified number of hours.

   • Temporary Trace Activation: Admins or authorized users can activate a SAML Trace for a specified time frame (limited to minutes if needed), during which all SAML requests (login, logout, etc.) will be securely stored in the system.
   • Secure Access and Review: Site admins can securely access and review SAML trace logs directly within the system without needing local downloads.
   • Logged Details: While active, this property logs all SAML request types (Login, Logout, etc.) with detailed information for monitoring and troubleshooting. 

   • Archiving: SSO log data can be managed through Log Archive Settings to ensure efficient storage

Return to top

"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 Axero.

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 that 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 in the urn field in ADFS relying on partner trust and Axero should match.

ADFS setting screenshot:


In Axero, check Control Panel > System > Single Sign On > SAML > Relying Party Trust Identifier.

Users can log in 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. An SPN should be registered for your ADFS service account. To verify this, refer to the following instructions:

1. On the domain controller server, click Start.
2. Click Run.
3. Enter adsiedit.msc to launch the ADSIEdit MMC console.
4. If necessary, connect to the site server's domain.
5. In the console pane, expand the site server's domain.
6. Expand DC=<server distinguished name>.
7. Expand CN=Users.
8. Right-click CN=<Service Account User>.
   The service account user is usually the administrator account.
9. On the context menu, click Properties.
10. In the CN=<Service Account User> Properties dialog box, review the servicePrincipalName value to ensure a valid SPN has been created. If not, add the value in this format: HTTP/FQDNADFS & Axero Guide.

"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)"

Ensure the following two properties have the https protocol you added in the 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 the 'Account' tab, and the heck, the 'User logon name' information is present there.

Go to the AD controller, edit the user's login name, and enter a valid value.

"There is no SAML configuration."

Enable the SAML trace log by adding a diagnostic element (as described in the Configure ADFS section), and then check the error in the logs. The certificate path may be wrong or there may be duplicate certificate locations in both the Partner and Service provider.

"There is no such relying partner."

Ensure the Relying Partner Trust Identifier in Axero and ADFS management console match.

The identity provider doesn't allow the response to be signed.

Set WantSAMLResponseSigned to false in SAML config.

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.axero.com/SAML/AssertionConsumerService.aspx

Return to top