Home

Problem Statement

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.

1. The 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.
2. 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.
3. The authorizations data model in Keycloak does not support all the requirements.
4. 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.

Goals

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.

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, 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.

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.

Requirements/Opportunities

Security Requirements

Include Appropriate Authorization Context as part of Authentication

As a digital product development team, I want to consume the authorization context (lists of groups, roles) for an authenticated 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.