-
Notifications
You must be signed in to change notification settings - Fork 17
Historical User Management
This section describes the user authentication strategy employed by the existing TNO application and the authentication requirements for the TNO rewrite. It also covers the authentication technologies available in Keycloak and how these could meet the contractual requirements.
The table below contains a list of common acronyms used in connection with Keycloak/SSO.
| Acronym | Description |
|---|---|
| OIDC IDP | OpenID Connect Identity Provider |
| OCP-SSO | Open Shift Container Platform Single SignOn |
| IDIM | Provincial Identity Information Management |
| CLP | Common Logon Page |
The Product Owner's requirements for the authentication system are outlined in the table below. These requirements were defined in the context of the existing TNO application. A departure from these constraints, under the current application, would cause a loss of functionality and/or ease of use for the product owner and/or users.
The design of the new TNO application can take most of these requirements into account by redefining how the system operates. It appears that many of these strategies were developed to work around the limitations of the existing application. With the advent of a completely redesigned solution, these issues can be accommodated or avoided. The following points relate to the use of either BCeID or IDIR based authentication (see Keycloak Authentication Strategy).
| Requirement | Status |
|---|---|
| Must allow for any type of email address | This requirement is met by the proposed authentication solution. |
| Authentication cannot be an obstacle for users | Because authentication may be performed using pre-existing accounts (BCeID or IDIR) the signup process could be more streamlined than it is at present. If a potential user lacks a BCeID or IDIR account, one must be created before registration. A user, who possesses one of these accounts, will be able to sign in to the new application by clicking on a "Register" button. This will create a TNO user account with the default privileges, giving them access to restricted functionality without the need for administrative oversight. A relevant role (or roles) can be assigned by an administrator at a later time. However, due to the fact that the BCeID and IDIR accounts are external to TNO, their administration is not under the control of the TNO staff. TNO administrators will have oversight of TNO user accounts, but not their associated BCeID or IDIR accounts. The administration of BCeID accounts is under the full control of the user, but support issues relating to IDIR accounts may cause some friction (see Product Owner Concerns). Keycloak setup with BCeID and/or IDIR is still very easy for users to login without issues. The benefit is that users have a good form of Single Sign On (SSO) with which they would generally be accustom to. The challenge is more in the administration of those accounts, specifically if a user has issues. They would need to resolve those through BCeID and IDIR instead of TNO. |
| Delete accounts and restore deleted accounts | Keycloak can disable or delete accounts. Outside of very specific business requirements, deleting accounts is not a good practice and probably isn't required anymore. |
| Control session duration | Keycloak can manage the length of a user session, however this is limited to the maximum length of SiteMinder's session configuration (which I believe is 1 hour). |
| Log users out of their accounts | This requirement is met by the proposed authentication solution. |
| Login as other user accounts | This is provided by Keycloak's "impersonate" feature. Impersonation allows one TNO user to masquerade as another user. Impersonation is not the same as logging in to the other user's account as an audit trail of activity will be recorded to ensure the feature is not being abused. This still requires development to fully implement. |
| Unlimited accounts with same email | Of the 532 user accounts in the existing application, 84 of them use the Product Owner's email address. These accounts are created by the Product Owner when a stand-alone auto report or analysis is defined. As the contents of these reports are affected by the user's preferences, the use of an existing account may skew the results. This is the sole reason for this requirement. The reporting and analysis components of the new application can be coded to avoid this limitation. |
| Change usernames and passwords | Individual users are responsible for managing their BCeID and IDIR passwords. This is also the case in the existing TNO application using a password change page and a "Forgot your password" link. These capabilities usually suffice for the user-directed profile management of online systems. The Product Owner rarely changes user names or passwords for actual users. However, sometimes a user will make changes to a profile associated with an auto report or analysis account and this will cause issues with the report. Changing the account usually remedies this situation. |
| Configure when an account will be deleted by schedule | Once a BCeID or IDIR account has been added to the new TNO application it could be programmatically deactivated based on a schedule. |
| Manage all users | The TNO application would be unable to manage BCeID and IDIR profiles, but could have complete control over the access of those profiles to the application. |
| Editors control who reports can be sent to and from | This requirement does not appear to relate to user profile management and can be built into the application. |
Our chosen platform (Open Shift) supports several authentication mechanisms. These include:
- BCeID
- IDIR
- BC Services Card
At this point, only options 1 and 2 are being considered for TNO authentication. Option 3 may come into play if it provides an answer to one or more business requirements that are not met using the other two options. Potential users of the TNO application who possess credentials under any of these systems may, with a little extra configuration to define their authorization parameters, obtain access without the need to go through an enrollment process. A role can be assigned at the time of their initial login that will give them access to a default set of actions.
The existing TNO application allows the Product Owner to create credentials on the fly with very little friction in the signup process. The need to enroll in one of these systems in order to access TNO would introduce some friction, but many potential users may already possess a BCeID or IDIR profile. In this case signing up for the application could be as simple as clicking on a "Register" button. Some credential-related issues are outlined below.
-
BCeID - This service provides two classes of users that are supported by Siteminder - Business and Basic. Business accounts maintain a one-to-many relationship between the business and its BCeID users. A user can obtain a BCeID account by contacting the profile manager for the business account. Basic accounts only take a couple of minutes to create and can be used to access various services immediately. The signup form for Basic BCeID is located here: https://www.bceid.ca/register/basic/account_details.aspx?type=regular&eServiceType=basic
-
IDIR - Enrollment in IDIR cannot be accomplished online and only Government employees or contractors can obtain an IDIR account. The creation of an account can only be requested by authorized personnel and, aside from basic profile changes, the administration of the account is outside the control of both the user and the party that requested its creation.
-
BCeID users are responsible for administering their account (deleting it, changing passwords, updating contact information, etc.). IDIR accounts are managed by the Government through the 77000 support line, so account administration must be performed over the phone. The changes that a user is authorized to make to their IDIR account depend on their relationship with the Government and the nature of the change. Some change requests may require authorization by a recognized Government contact.
Should a third-party authentication mechanism, such as IDIR or BCeID, be employed by the TNO application, it is necessary that some power of oversight be relinquished by the TNO administrators. However, there are many benefits to employing a standardized, government-wide, secure and highly flexible authentication mechanism. The list below summarizes the main drawbacks of using IDIR as perceived by the product owner:
- Can't give clients a clear and immediate explanation why their account is not working
- Don't have authority to resolve any and all client issues immediately without relying on anyone else to do anything
- Relied upon rules or regs are withdrawn or tightened over time and we are unable to cut IDIR out once it is in
After the user logs in to the TNO application, their behaviour is under the control of the application itself. After the user is signed in, the application knows who they are, a process known as authentication. Once a user is logged in the application is responsible for authorizing the user to undertake various actions or access various parts of the site, a process known as authorization. In the simplest case, the application will automatically create a user account with the default authorization settings. During initial development they may be given unrestricted access to all functionality but as security requirements are established a set of user roles will be defined.
Roles consist of a set of authorization claims that define what the user can and cannot do. These roles are defined under the Keycloak realm and fall within the control of the application. An administrator of the application can define which claims should be assigned to each role and which roles should be assigned to each user. The hierarchy of roles is also under the control of the application and can be customized to the product owner's requirements. For example, the product owner could be defined as the super-user of the application, giving them the ability to assign the administrator role to certain users. Administrators would have powerful capabilities over the application's functionality but would not be able to create other administrators. The way in which these relationships are defined is totally open for discussion.
The following roles are defined for the existing TNO authentication mechanism.
| Name | Role |
|---|---|
| User | Normal clients - they can only access TNO through website |
| Worker | Junior TNO editors - they can access TNO through the website and limited access through Kalel |
| Admin | Senior TNO editors - they can access TNO through website and complete access through Kalel |
A simple analysis of the current user base gives some context for discussing how these users can be migrated to the new application and how their unique needs might be met using existing Keycloak standards.
The table below lists the number of users associated with each email domain. The domains listed give a sense of the organizational scope of the user base and how many users of each organization have access to the application. There are currently 532 records in the user table:
| Domain | User Count | Organization |
|---|---|---|
| gov.bc.ca | 449 | Government of British Columbia |
| leg.bc.ca | 14 | BC Legislature |
| translink.ca | 11 | Translink |
| phsa.ca | 3 | Provincial Health Services Authority |
| bchousing.org | 2 | BC Housing |
| bcogc.ca | 2 | BC Oil and Gas Commission |
| fnha.ca | 2 | First Nations Health Authority |
| bchydro.com | 1 | BC Hydro |
| bclc.com | 1 | BC Lottery Commission |
| bctransit.com | 1 | BC Transit |
| opcc.bc.ca | 1 | Office of the Police Complaint Commissioner |
| ticorp.ca | 1 | Transportation Investment Corporation |
| sfu.ca | 1 | Simon Fraser University |
| bcldb.com | 1 | BC Liquor Distribution Branch |
| mac.com | 1 | ?? |
| victoriachamber.ca | 1 | Victoria Chamber of Commerce |
| gov.ab.ca | 1 | Government of Alberta |
| aglg.ca | 1 | Auditor General for Local Government |
| partnershipsbc.ca | 1 | Infrastructure BC |
| trustee.bc.ca | 1 | Public Guardian and Trustee of BC |
| rcybc.ca | 1 | Representative for Children and Youth |
| bcombudsperson.ca | 1 | Ombudsperson BC |
| oipc.bc.ca | 1 | BC Information and Privacy Commissioner |
| elections.bc.ca | 1 | Elections BC |
| infrastructurebc.com | 1 | Infrastructure BC |
| bcuc.com | 1 | BC Utilities Commission |
| interiorhealth.ca | 1 | Interior Health |
| northernhealth.ca | 1 | Northern Health |
| viha.ca | 1 | Vancouver Island Health Authority (now islandhealth.ca) |
| vca.ca | 1 | Victoria College of Art |
| fraserhealth.ca | 1 | Fraser Health |
Not listed above are the Product Owner, Aktiv Solutions employees, Quartech employess/contractors and duplicate users. Two things to note about these domains:
- A user can only have a gov.bc.ca email address if they are a government employee or contractor.
- Any user with a gov.bc.ca email address will have had an active idir account at the time they were enrolled.