This article explains:
Provisioning of a New User
De-Provisioning of an existing user
Role change in an organization
Mobile – user of personal / single user devices
Mobile - use of shared device
Setting Up SSO
Users are provisioned when they join an organization and require access to Coruson. Users can be provisioned by:
Added directly and manually to Coruson
Added to Coruson via an import or sync
Added to Coruson via SSO
It must be remembered that when a new user is added, they will automatically belong to a number of groups. It is from membership of these groups that any privileges are granted to view records and/or perform activities in Coruson. A new user will be added automatically to:
The All users group
Any groups that are associated with their organisational unit (a mandatory value when creating a user)
Any other group membership must be added manually. In scenario 1 the admin user would manually perform this task. In scenario 2 the import may define one or more additional groups for the imported user – but this is of course limited to the information in the import any omissions would need to be added manually. In scenario 3, the user cannot be added to any more groups automatically and so any omissions would need to be added manually.
Because of the limitations in scenario 3 clients often do not rely on SSO for new user provisioning and instead set up a sync with a staff roster system that imports / updates on a daily basis. This removes (most) of the manual overhead.
If a User is created within Coruson and then tries to login through their external provider Coruson will try and do a match based on their Username or Email.
Users are de-provisioned when they leave an organization and no longer require access to Coruson. Users can be de-provisioned by:
Archived directly and manually to Coruson
Archived via an import or sync
Archived via SSO (This is not automatic deprovisioning)
Coruson archives users, it does not delete them – they can be re-instated. Archived users remain members of Coruson groups to which they were assigned.
There can be a gap between a user being archived and the user actually becoming unable to authenticate in Coruson. This is related to whether they are logged in or not and when their session will expire.
If a user is logged in to the main web application they will still be able to use the system until either, they log out or their session expires (duration set in security management).
NB On a mobile device, if a user chooses to ‘remember their logon’ their session will only end if they manually log out or re-start their device.
When users change role this would normally result in their internal security clearances being altered, e.g. the groups in ADFS to which they belong being changed. This may imply that the groups to which they belong to in Coruson may also adjust to give access to a new document set for instance relevant to their new role.
So a role change may mean a group change in Coruson achieved by:
Manually editing group membership / associated organisational unit in Coruson
A change made to the organisational unit or groups via an automated sync
There is no way to alter group association in Coruson via SSO.
When mobile devices are used it is often the case that this is the users own personal device or one assigned by the organisation that is not shared with other members of staff.
In this situation the user will always have to sign in at least once using the Coruson user name and password when they have internet access. From that point on they do not have to sign in again unless they log out or re-start their device. As mentioned previously this can cause an issue with de-provisioning as the user will still be able to use the app until they log out / re-start the device. They will of course only be able to perform activities allowed by the app – report or perform an Audit
In some cases, e.g. electronic flight bag for an airplane, the mobile device is shared. In this case SSO doesn’t really work as such as the user should authenticate each time so Coruson knows who they are.
Unlike iOS and Android, signing into a Windows Mobile device allows a normal SSO process to occur as the user will be authenticated before opening the app