By logging in using Azure AD Sign-On (SSO), users no longer have to select and remember a local password - your users are logged in via your Azure AD credentials.
Paid add-on
Azure AD SSO is a paid add-on to your current Cinode plan.
Preparations
First off, you will need to contact Cinode support to make sure the add-on is enabled for your company. You will also need an Administrator permission level to set up the integration in-app.
Get started
Login into Cinode as usual.
Go to the link Administration in the sidebar and select Integrations:
2. On the Integrations page, select the tab Account types.
3. Click the button Activate new account type:
4. Select "Aad" as the account type in the dropdown menu and click Save.
5. Azure AD (Aad) will now be displayed as an added account type:
How to set up Azure AD SSO for your users
After you have enabled Azure AD SSO as a method of logging into Cinode, you will need enable SSO for each individual user. This is done by adding the unique user identifier (Object ID) from your Active Directory to each user account in Cinode.
Once you have retrieved the Object ID for all your user from your Azure Active Directory, you can proceed.
Go to the link Administration in the sidebar and select Users:
2. Click the options menu, indicated by the three vertical dots on a user:
3. Select Edit login type:
4. Finally, add the unique ObjectID that you retrieved from Azure AD related to the specific user in the "Object Identifier" field:
This process will need to be repeated for each individual user that is going to login via SSO.
Done!
Please note
A user cannot log in with both Azure AD SSO and the password account types. You will have to select one of them.
It is possible to have some users logging in via SSO and some via password. In that case, you will need both Aad and Password added as account types, but for those users who are meant to login via SSO you will also need to add an Object ID.
Configure Cinode to support provisioning with Azure AD
Preparations & PrerequisitesThe scenario outlined in this tutorial assumes that you already have the following prerequisites:
A user account in Azure AD with permission to configure provisioning (for example, Application Administrator, Cloud Application administrator, Application Owner, or Global Administrator).
A user account in Cinode with administrator rights.
Capabilities supported
✅ Create users in Cinode
✅ Remove users in Cinode when they do not require access anymore
✅ Keep user attributes synchronized between Azure AD and Cinode
✅ Provision groups and group memberships in Cinode
Step 1. Plan your provisioning deployment
Learn about how the provisioning service works.
Determine who will be in scope for provisioning.
Determine what data to map between Azure AD and Cinode.
Step 2. Configure Cinode to support provisioning with Azure AD
Sign in to Cinode with a user account that has Administrator rights. Navigate to Administration.
Navigate to Integrations -> Tokens
Choose “create a new SCIM token”
Enter an appropriate name and expiry date. For example one year ahead, note that when this date expires the integration will not work anymore so we recommend creating a reminder of this date.
Click Create token.
Copy the Tenant URL and the Token. These values will be entered in the Provisioning tab of your Cinode application in the Azure portal.
Step 3. Add Cinode from the Azure AD application gallery
Add Cinode from the Azure AD application gallery to start managing provisioning to Cinode. If you have previously setup Cinode for SSO, you can use the same application. However it is recommended that you create a separate app when testing out the integration initially. Learn more about adding an application from the gallery here.
Step 4. Define who will be in scope for provisioning
The Azure AD provisioning service allows you to scope who will be provisioned based on assignment to the application and or based on attributes of the user / group. If you choose to scope who will be provisioned to your app based on assignment, you can use the following steps to assign users and groups to the application. If you choose to scope who will be provisioned based solely on attributes of the user or group, you can use a scoping filter as described here.
When assigning users and groups to Cinode, you must select a role other than Default Access. Users with the Default Access role are excluded from provisioning and will be marked as not effectively entitled in the provisioning logs. If the only role available on the application is the default access role, you can update the application manifest to add additional roles.
Start small. Test with a small set of users and groups before rolling out to everyone. When scope for provisioning is set to assigned users and groups, you can control this by assigning one or two users or groups to the app. When scope is set to all users and groups, you can specify an attribute based scoping filter.
Step 5. Configure automatic user provisioning to Cinode
This section guides you through the steps to configure the Azure AD provisioning service to create, update, and disable users and/or groups in TestApp based on user and/or group assignments in Azure AD.
To configure automatic user provisioning for Cinode in Azure AD:
Sign in to the Azure portal. Select Enterprise Applications, then select All applications.
In the applications list, select Cinode.
Select the Provisioning tab.
Set the Provisioning Mode to Automatic.
Under the Admin Credentials section, input the SCIM 2.0 base URL and Authentication Token values retrieved earlier in Tenant URL and Secret Token fields respectively. Click Test Connection to ensure Azure AD can connect to Cinode. If the connection fails, ensure your Cinode account has Admin permissions and try again.
In the Notification Email field, enter the email address of a person or group who should receive the provisioning error notifications and select the Send an email notification when a failure occurs check box.
Select Save.
Under the Mappings section, select Synchronize Azure Active Directory Users to Cinode.
Review the user attributes that are synchronized from Azure AD to Cinode in the Attribute-Mapping section. The attributes selected as Matching properties are used to match the user accounts in Cinode for update operations. If you choose to change the matching target attribute, you will need to ensure that the Cinode API supports filtering users based on that attribute. Select the Save button to commit any changes.
Attribute | Type | Cinode name |
userName | String | username |
name.givenName | String | first name |
name.familyName | String | last name |
externalId | String | externalId |
active | Boolean | status |
title | String | title (admin setting) |
addresses[type eq "work"].locality | String | location |
phoneNumbers[type eq "work"].value | String | phone |
employeeNumber | String | employmentNumber |
employmentStartDate | String | employmentStartDate |
10. Under the Mappings section, select Synchronize Azure Active Directory Groups to Cinode.
11. Review the group attributes that are synchronized from Azure AD to Cinode in the Attribute-Mapping section. The attributes selected as Matching properties are used to match the groups in Cinode for update operations. Select the Save button to commit any changes.
Attribute | Type |
displayName | String |
externalId | String |
members | Reference |
12. To configure scoping filters, refer to the following instructions provided in the Scoping filter tutorial.
13. To enable the Azure AD provisioning service for Cinode, change the Provisioning Status to On in the Settings section.
14. Define the users and/or groups that you would like to provision to Cinode by choosing the desired values in Scope in the Settings section.
15. When you are ready to provision, click Save. Also make sure that Object ID has to be set to "always" when applying the mapping, you can do this under edit Attribute section. Pictured down below and found under Microsoft Entra ID.
This operation starts the initial synchronization cycle of all users and groups defined in Scope in the Settings section. The initial cycle takes longer to perform than subsequent cycles, which occur approximately every 40 minutes as long as the Azure AD provisioning service is running.