-
Notifications
You must be signed in to change notification settings - Fork 2
Home
The Natural Resource Sector (NRS) has relied extensively on WebADE for digital 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 assignments. 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 assignments 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 JSON 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.
- Environment Management
- Release Management
- Creating a Release
- Database Backups and Restores
- OIDC Client Testing
- FAM Onboarding Ops Guide
- Setup AWS CloudWatch
- Setup AWS EC2 instance to connect to RDS Postgres Database
- Technical Troubleshooting
- Managing Terraform State
- Enable Cloudwatch Logs for API Gateway
- Update AWS CloudFront Certificate
- Verify IDIM BCeID Client SOAP Web Service