Home
The Natural Resource Sector (NRS) has relied extensively on WebADE for digital authentication and authorization for decades. The existing applications that are candidates for modernization under the Forest Service Applications Modernization Project (FSA) are almost all tightly coupled with the WebADE system. There is a complex operational data set, managed by a front-end application called ADAM, that is used to define authorization permissions, groups, and memberships. The modern applications being created under the FSA project will not be compatible with WebADE and will not be able to use ADAM for authorization management.
It is possible to define groups, roles, and user memberships using Keycloak, but there are a number of challenges with this approach.
- The Keycloak UX for managing authorization information is not very business-friendly. The people who currently have the responsibility to manage access for applications (using ADAM) would have difficulty with the Keycloak admin console.
- The Keycloak admin console does not have fine-grained security. Users that can log in for the purposes of authorization management can also make manual changes to anything in the Keycloak realm to which they have privileges.
- The authorizations data model in Keycloak does not support all the requirements.
- Keycloak is not necessarily an appropriate location for operational business data. It makes reporting difficult and it tightly couples authorization business logic to a product that might not be best-of-breed in the future.
The Forests Authorization Management product (FAM) will meet the needs of the sector to allow business users to define and assign groups and roles. FAM will integrate with an OIDC service so that authorization context will be securely and transparently included in the context of any authentication process.
- Digital products & services developed as part of the FSA project will use the Open ID Connect (OIDC) standard for security whenever possible. As part of the OIDC workflow, any authorization information necessary for the client application should be transmitted as part of the Javascript Web Token (JWT) that is digitally signed and provided by the OIDC server that is used for security context. By adhering to this standards-based approach, we avoid making the same mistake that was made with WebADE (tightly integrating everything into a custom solution that must be maintained).
- It must be possible to manage the authorization data for all the modernized digital products & services in an intuitive and business-friendly manner that is highly secure. The ADAM application currently fulfills this requirement for legacy applications, but it is tightly coupled with WebADE and needs to be replaced by something that integrates with OIDC. Additionally, the ADAM application itself is a candidate for re-development and significant UX and functional improvement.
- Authorization data will also be manageable using application programming interfaces (API) to support digital product teams that want to enable automation scenarios instead of relying on manual processes.
- Forest clients can manage their own staff access to FSA applications.
As a digital product development team, I want to consume the authorization context (lists of groups, roles) for an authenticated IDIR or BCeID user directly from the JWT provided by the OIDC service.
- Roles should be scoped appropriately. I don't need all the roles for this user across the entire org, nor do I want role assignments for my product exposed to other products (and potentially reused/misused).
- By validating the JWT, I will know that these roles come from the OIDC service and have not been maliciously injected by a user or another actor.
As a FAM administrator, I want to be able to create a new application so that I can assign an application administrator and that person can use the authorization capabilities of FAM to secure their application.
As an application administrator, I want to be able to create, update, and delete roles and groups for the application. I want to be able to manage which roles belong to which groups. I want to record and maintain the purpose of each role and group so that I can make sure that they are used correctly.
- Variation: Create a role or group that can only be assigned in the context of a specific forest client.
As an authorization grantor, I want to be able to assign an application role or application group to an end user so that the end user can make use of the application functionality afforded by membership of the applied role or group. * Variation: I want to grant a role or group membership temporarily (define a start time and end time).
- Variation: If I do not know their system identifier within IDIR or BCeID, I may also want to look them up in that system by name.
- Variation: Grant a role or group membership that is limited to the context of a specific forest client.
As an authorization grantor, I want to be able to disable a role or group membership so that I can remove access from a user temporarily without having to delete their authorization configuration and then set it up again later. I want to re-enable the role or group membership at a later time to restore their access afforded by that membership. * Variation: I want to disable or enable a role or group membership temporarily (define a start time and end time).
- Variation: I want to disable or enable a set of role or group memberships that meet a certain set of criteria.
As a FAM administrator, I want to be able to disable all authorization for a user so that I can remove all privileges from a user temporarily without having to delete their authorization configuration and then set it up again later. I want to re-enable the user's authorizations at a later time to restore their access afforded by their existing role and group memberships.
- Variation: I want to disable or enable a user temporarily (define a start time and end time).
As a FAM administrator, I want to be able to add a user to FAM without having to ask them to log into something first. I want to be able to look them up by IDIR or BCeID identifier, confirm that they are not already in the system, and have them added to the system so that they can be assigned roles and groups by authorization grantors.
- Variation: If I do not know their system identifier within IDIR or BCeID, I may also want to look them up in that system by name or by username.
As a FAM administrator, I want to be able to delete a user from FAM.
As a FAM administrator, I want to be able to grant or revoke the ability for a logged-on user to create, update, or delete roles and groups for an application, so that I can ensure that each application has its own application administrator(s) who assume responsibility for maintaining the roles and groups. Individuals without this privilege for a particular application should not be able to use FAM to make changes to the roles or groups for the application.
As an application administrator, I want to be able to specify who can act as an authorization grantor to grant or revoke application roles and application groups to users, so that I can ensure that the application has its own authorization grantor(s) who assume responsibility for maintaining user membership in application roles and application groups. Individuals without this privilege for a particular application should not be able to use FAM to add or remove users to roles or groups for the application.
- Variation: Specify authorization grantors that can act as an authorization grantor to grant or revoke specific application roles and application groups to users.
- Variation: Specify authorization grantors that can act as an authorization grantor to grant or revoke specific application roles and application groups to users, but only in the context of a specific forest client.
As a security analyst, I want to be able to review the history of authorization changes within FAM. I need to know the following information:
- The time of the change
- The person who made the change
- The organization for whom the change was made
- The purpose for the change Variation: I want to be able to export role and group memberships to excel so I can do data analysis.
As an access manager or operations specialist, I want to be able to search for a user in the system by ID, name, or email.
As an access manager or operations specialist, I want to be able to see a list of roles and groups that have been assigned to a specific user and understand what each of them is for. Variation: A user wants to see their own access profile.
As an access manager or operations specialist, I want to see a list of users that have a certain set of authorization roles or groups assigned so that I can understand the list of people that have certain privileges in an application.
As a DevOps practitioner, I want to be able to automate certain authorization configuration tasks so that I can have them completed in a timely and reliable fashion based on certain triggers in my application or CI/CD pipeline.
- Role specific to a forest client
- Group specific to a forest client
- Group that is across more than one application
- OIDC Client:
- Application:
- Role:
- Group:
- FAM Administrator
- Application Administrator
- Application Authorization Grantor
- Application User