Introduction
The govService Firmstep platform allows users to log in with a number of different identity providers, depending on the nature of the specific product. For example, users who need to register and use a 'Self account' to make service requests online need to use a different style of account to users who work in a Contact Centre, who need a CSA account to use our Service CRM Product, or internal back-office users who process service requests, who need a way to access the Dashboard via the Dash Portal.
The way that these different identity providers operate and interact can be confusing. This article aims to explain the way that different identity providers behave in Firmstep, including examples of best practice ways to handle situations such as user name changes and form design to retrieve user profile details.
All users have a profile in Dash and Self. The first time they log to the site, their profile is created. In Self we normally experience this as the profile update screen: it appears immediately when you log in for the first time so you can complete your newly created profile. (Note: when testing internally you should use dummy Self accounts that have non council email addresses)
In Dash, this only happens if profiles are enabled. Profiles are not enabled in Dash by default, but this doesn't mean you don't have one: you still have a profile, but you can't change it and it won't force you to fill out further details. Your profile usually finds your details via ADFS (ie. your FAM login). Therefore, if a user has the wrong name showing in Dash, and when you click on their name there is no dropdown option to Update Profile, they should update their details in ADFS, so the details can be updated next time they log in.
Note: creating a Dash account will set an api_key so that the user does not show in Service, which is by design, as staff using dash will not be customers of service.
Sometimes if a user logs in to Service before they have ever logged into Dash and Self their profile doesn't get generated. This leads to them being a user but not appearing in the Permission Manager. If this happens to a user, please contact Support.
The record of the user in the Permissions Manager is separate to the profile of the user. The records are not synced nor linked. Therefore changing a user's name in the PM will not change it in Service, Dash or anywhere else in the platform.
Glossary
Identity Provider - A tool which can be used to check your identity.
Identity - A representation of a person in data.
User Account - Another term for an identity.
User Profile - Attributes which are linked to an identity.
Login - An instance of an identity on a specific identity provider.
Login Credentials - The specific set of data that constitutes your identity within a specific identity provider. Eg. Username and Password.
Identity providers available in Firmstep
|
IP Name
|
Description
|
Recommended Products*
|
|
Self Service Login (SSAUTH)
|
A Drupal-based identity provider which manages authentication to public-facing portals. Being replaced by Granicus_Azure_SSAUTH.
|
Self
|
| Self Service Login (Granicus_Azure_SSAUTH) | Azure B2C acts as our SAML-based identity provider (IdP), authenticating users for public-facing portals with customizable authentication flows. | Self |
|
Web Login
|
The same style of IP as above, but able to be used for internal portals where a FAM Login is not suitable - for example, to provide access to Dash for external contractors or for workers who are not part of the internal network. Being replaced by Granicus_Azure_INTAUTH
|
Dash, Members Portal
|
External Access Login
/new Web Login
(Granicus_Azure_INTAUTH) | Extending Granicus_Azure_SSAUTH to provide access to Dash for external contractors or for workers who are not part of the internal network. | Dash, Members Portal |
|
FAM Login
|
An identity provider which integrates with Active Directory to authenticate users. Used to allow internal users logged on to an internal network to log in to Firmstep products without providing login credentials. (Sometimes called Office Login in the list of providers). Please note that a unique email address ‘noemail-randomstring@example.com’ will be assigned to FAM users with no email, where the random string is determined by the Active Directory. These email addresses are hashed so they are not exposed, and they ensure the user's permissions will not be affected due to not having an email address.
|
Dash, Members Portal, Service
|
| SAML Login | An identity provider that integrates with SAML-based system to authenticate users. Used to allow users to log in using the same credentials they use with other cloud-based systems. Firmstep support both ADFS and Azure AD identity providers. Similar other SAML based identity providers may also be supported but as yet untested. | Dash, Members Portal, Service |
|
Firmstep Google FAM
|
Now deprecated and replaced with Firmstep Google Admin below. This IP was used by Firmstep staff to authenticate to customer sites to debug support issues or conduct consultancy work.
|
All
|
|
Firmstep Google Admin
|
An IP used by Firmstep staff to authenticate to customer sites to debug support issues or conduct consultancy work. More information on the Firmstep Admin user.
|
All
|
|
Google Social Login
|
Allows users to authenticate using a Google account instead of creating a new Self Account. Currently in beta testing and not available on live sites.
|
Self
|
|
Facebook Social Login
|
Allows users to authenticate using a Facebook account instead of creating a new Self Account. Currently in beta testing and not available on live sites.
|
Self
|
|
MyGovScot
|
Allows users to authenticate using a MyGovScot account instead of creating a new Self Account. Only available for Scottish customers.
|
Self
|
*All Identity Providers are available on all products, and in some cases you will need to have a non-recommended provider available for Admin use - eg. a FAM Login on Self for users to access the Admin Console.
Enabling and managing identity providers
Currently, the set-up, configuration and management of identity providers on each customer product is done by Firmstep staff on a case-by-case basis. Usually, your identity provider set-up will be done for you when you join us as a customer, and if you require changes later these are handled via the Support system.
Hiding identity providers from the login page
Sometimes, you will want to have an identity provider enabled on a site but not visible to the main group of users who will be authenticating to that product. For example, you may need to allow people to authenticate to Self via a FAM Login to conduct Admin work on the portal, but you do not want citizens seeing the FAM Login option on the Self Login page.
In these instances, you will need to request for us to hide the identity provider on a secret login page which can be accessed by going to <domain>/login?support
This allows you to have a set of identity providers available on <domain>/login and extra ones available for those who go to <domain>/login?support
Please note that the configurations for an identity provider are platform-wide. This means that configuring the FAM Login to be hidden will apply to Self, Dash, Service, Forms and any other products you use. We are able to create separate instances of identity providers for special cases where this situation causes problems.
Identity providers and account creation
The table below explains how an account is created for each Identity Provider:
|
IP Name
|
Account Creation
|
Identifier
|
|
Self Service Login (SSAUTH)
|
User registers from <self-domain>/register. If email validation is enabled, the user's account is created but they cannot log in to it yet. The user receives a verification email containing a link which must be clicked on for the account to be validated, after which they can log in. If email verification is disabled, the users valid account is created immediately with the login credentials provided. Being replaced by Granicus_Azure_SSAUTH.
|
Email Address
|
| Self Service Login (Granicus_Azure_SSAUTH) |
User registers from <self-domain>/register.
The user is required to verify their email as part of the registration process.
| Email Address |
|
Web Login
|
Firmstep create a Super Admin who can then add the Admin users specified by you. These Admin users can then add the regular users from <intauth-domain>/users. You will be given the domain URL after its creation. Being replaced by Granicus_Azure_INTAUTH.
|
Email Address
|
External Access Login
/new Web Login
(Granicus_Azure_INTAUTH) | Any User with a Granicus_Azure_SSAUTH account can easily be made an External Access user via Permission Manager.
Adding Granicus_Azure_INTAUTH to their list of Auth Providers will make them an External Access user. Deselecting will reverse this and prevent them access. | Email Address |
|
FAM Login
|
Users are created in your AD/ADFS system. When the user authenticates to Firmstep using the FAM for the first time, a new account is created for them using the email address specified by the ... AD/ADFS attribute (Sometimes called Office Login in the list of providers)
|
Email Address
|
|
Firmstep Google FAM
|
N/A
|
N/A
|
|
Firmstep Google Admin
|
The Admin User is set up by following the steps in this guide. All Firmstep users will impersonate this one user when accessing your site.
|
Email Address
|
|
Google Social Login
|
User navigates to <self-domain>/register and selects Google. A new Self Service Login is then created for them with a cross-reference to their Google account.
|
Email Address
|
|
Facebook Social Login
|
User navigates to <self-domain>/register and selects Facebook. A new Self Service Login is then created for them with a cross-reference to their Facebook account.
|
Email Address
|
|
MyGovScot
|
User navigates to <self-domain>/register and selects MyGovScot. A new Self Service Login is then created for them with a cross-reference to their MyGovScot account.
|
Email Address
|
Profiles
A profile is a set of attributes which are linked to a user account, for example 'Name'. The way a profile is created, stored and updated is different for each identity provider in the Firmstep Platform as outlined below:
|
IP Name
|
Profile
|
|
Self Service Login (SSAUTH)
|
All SSAUTH accounts must have a profile. The profile must contain a UCRN as a minimum. Other attributes that can be stored in an SSAUTH profile are listed in this document. Customers can choose which attributes are stored against customer accounts by building their own custom profile update forms. Being replaced by Granicus_Azure_SSAUTH.
|
| Self Service Login (Granicus_Azure_SSAUTH) | Works as before. We will keep First name, last name and UPRN(if available) on the Azure B2C tenant. |
|
Web Login
|
A Web Login user has a profile which behaves the same was as an SSAUTH profile. Being replaced by Granicus_Azure_INTAUTH.
|
External Access Login
/new Web Login
(Granicus_Azure_INTAUTH) | Linked to their Granicus_Azure_SSAUTH and will update both. |
|
FAM Login
|
A FAM Login user's profile is dictated by the attributes passed to Firmstep from the AD/ADFS system. These attributes are loosely mapped to the SSAUTH profile attributes but we do not advise relying on these mappings, and instead advise that profile information is pulled directly from the FAM Account where needed.
|
|
Firmstep Google FAM
|
N/A
|
|
Firmstep Google Admin
|
The Firmstep Google Admin's profile is dictated by its Google Account whose attributes are passed to Firmstep from Google.
|
|
Google Social Login
|
A Google user's profile is dictated by the attributes passed to Firmstep from Google. These attributes are then mapped to SSAUTH profile attributes.
|
|
Facebook Social Login
|
A Facebook user's profile is dictated by the attributes passed to Firmstep from Facebook. These attributes are then mapped to SSAUTH profile attributes.
|
|
MyGovScot
|
A MyGovScot user's profile is dictated by the attributes passed to Firmstep from MyGovScot. These attributes are then mapped to SSAUTH profile attributes.
|
Viewing user details
There are two places in the platform where user accounts can be viewed after creation:
The Customer Index will show you:
The Permissions Manager will show you:
Updating user details
Firmstep separates updating the information stored as part of your account from updating the information stored as part of your profile.
|
IP Name
|
Updating Account Information
|
Updating Profile Information
|
|
Self Service Login (SSAUTH)
|
User can change their email using the 'Change Email' functionality. This changes the email used to log in to the account and the email against which tasks are assigned (old queue processor tasks only). Users can change their password using the 'Change Password' functionality. Being replaced by Granicus_Azure_SSAUTH.
|
All profile information can be updated by using the 'Update Profile' functionality. The 'Change Email' functionality will also update the email stored as part of the profile.
|
| Self Service Login (Granicus_Azure_SSAUTH) | User can change their email using the 'Change Email' functionality.
This changes the email used to log in to the account and the email against which tasks are assigned (old queue processor tasks only).
Users can change their password using the 'Change Password' functionality. | All profile information can be updated by using the 'Update Profile' functionality except emails. |
|
Web Login
|
Users can change details in the interface attached to the intauth domain where the Web Login users are managed. Being replaced by Granicus_Azure_INTAUTH.
|
Users can change profile information in the interface attached to the intauth domain where the Web Login users are managed.
|
External Access Login
/new Web Login
(Granicus_Azure_INTAUTH) | User can change their email using the 'Change Email' functionality.
As this is the same account as Granicus_Azure_SSAUTH then it will also change how you login to Self. | Same as Granicus_Azure_SSAUTH |
|
FAM Login
|
Users can change their email in their AD/ADFS system. A new account with this email will then be created in Firmstep. Read more about changing details for users using FAM Login below.
|
Users can change profile information in their AD/ADFS system. The profile change will be pulled into Firmstep next time the user logs in. Please note, if the user changes account and profile information in AD/ADFS, a new account will be created in Firmstep and changes will only apply to this account.
|
|
Firmstep Google FAM
|
N/A
|
N/A
|
|
Firmstep Google Admin
|
N/A
|
N/A
|
|
Google Social Login
|
Users can change their email in Google. A new account with this email will then be created in Firmstep.
|
Users can change their profile details in Google and these will change where the values are mapped to Self Profile values.
|
|
Facebook Social Login
|
Users can change their email in Facebook. A new account with this email will then be created in Firmstep.
|
Users can change their profile details in Facebook and these will change where the values are mapped to Self Profile values.
|
|
MyGovScot
|
Users can change their account information in MyGovScot.
|
Users can change their profile details in MyGovScot and these will change where the values are mapped to Self Profile values. This does not work in reverse.
|
Changing user account details: permissions and task assignment
There are two areas of the platform where changing user account details can cause issues.
Permissions
Permissions are assigned to the user identifier specified in the earlier section of this document. In most cases this is the email address. This means that when an email address is changed in an identity provider and a new account is created in Firmstep (eg. FAM Logins), permissions assigned to the old email address are not migrated.
If you use AD Groups to manage permissions and when changing the user's details the ADFS user_id doesn't change (only the email name is changed), permissions should be migrated using AD Groups.
There is a known issue that when changing email in Self using 'Change Email' functionality, user permissions are not migrated.
Task Assignment (Amending CSA Username/email address)
Tasks which were assigned using the Old Queue Processor will be assigned using email address. This means that when an email address is changed in an identity provider and a new account is created in Firmstep (eg. FAM Logins) any tasks assigned to the original account are not merged.
Best practice for changing a user's email address in this situation is to change their email in the AD/ADFS system, allow them to log in to Firmstep where a new account is created, ensure permissions on the new account are correct and then use the Merge Tool in Service to merge the cases from the old user to the new one:
-
Go to Index
-
Search for the original user account (Note: CSA accounts are generally hidden from the Service Search function - to locate a CSA you will need to search using the format ucrn:123123123)
-
Click on the user
-
Click 'Find Customer' in the sidebar
-
Search for the new CSA account (as above)
-
Merge the accounts
When merging user accounts, both old logins will work and be able to access the merged account
The permissions manager only tracks and manages a user's permissions. If a user's entry in the PM is deleted this doesn't prevent them from logging in, this just does not attribute them with any permissions within the platform. (So MyRequests will still work, etc).
Cases assigned to original user are transferred to the new merged user
Internal Users and External Users
It is important to understand the difference between an internal user (has a "council.gov.uk" email address) and an external user (a customer/citizen). Internal users are not customers, and therefore will not be listed when performing a customer search in Service. This is also why internal users should not have Self Accounts using their council.gov.uk email address.
- An internal user can use Dash (and Councillor portal) and/or Service subject to the relevant permissions and CSAs can raise cases for members of the public using Service. However, Dash/CSA/Councillor users will be flagged by the system as internal and hidden from Service, as this is your Customer database only.
- You will be able to locate the record, but only via UCRN. This is expected behaviour and will not be changed.
- Internal users who are not CSAs can use Dash to log cases for themselves, e.g. cases relating to ICT / HR etc..
- Whilst internal users may complete any forms that are enabled through Dash, they cannot assign to a customer: this functionality is only possible in Service.
- By definition, all CSAs will also use Dash: Dash is the internal portal.
If a member of staff also wishes to have a customer account ie as they use council services as a customer then they should use their personal email addresses for this (eg through Self or Service)
Troubleshooting common issues
Wrong Details Displaying in Dash Interface
If a user's details are showing incorrectly in the top right corner of Dash, it is because the mappings between a FAM user account and the Self profile details do not always align correctly. For example, a user with a name like John Van Smith would only show as John Smith in Dash.
Wrong Details Showing in Form Fields in Dash/Service
If a user's details are being pulled into form fields incorrectly, there could be two things wrong:
-
Your form is using the wrong datanames/tokens to retrieve the user's details. The form should use the FAM tokens if the user is logging in with a FAM account, or use the {user_} tokens. The form should not use Self profile datanames (eg. Email_Address) if it is intended for use in Dash.
-
Something is incorrect in the user's profile data. We recommend checking their data is correct in the FAM account first, and then ask you to get the user to log in and go to <dashURL>/authapi/isauthenticated?all and paste the result into your Support ticket.
User has forgotten their password
Should a user forget their web login, they will have to reset their password via Dash, as Service does not support that functionality.
Missing UCRN
If the UCRN is not mapped correctly, the error UCRN not set is displayed. We cannot provide the option to change the UCRN, as it can cause conflict with GDPR standards.
We advise you to merge users that have conflicting UCRNs. You can also contact Granicus support and we can route the UCRN manually.
Returning Email address in a process
- Email_Address should only be used for retrieving SELF profile information. Do not use this for retrieving internal user email addresses in Dash or Service. For this please use {user_email}.
Further useful reading:
top of page 
