Supporting Authorization Flow (App Model)

[ikethecoder]

Draft Design Notes:

A re-skin of the API Services Portal to support Application RBAC.

RBAC

RBAC: Role-based access control using the standard Client Roles

1. Change the labeling from API Services Portal" to "App Store"
2. When Oauth2 Authorization Code Flow is selected, it has to choose an Authorization Profile setup for this type of flow, and then the Plugin has to be updated to handle the authorization and reverse proxying. There will be a client id ("app-" + env.appId) and client secret that will support the OAuth and it will need to be generated for the Product Environment. This should be automatically created on update, once and displayed for copying. The Plugin Template will reflect that information - can do Role validation on Service/Routes if necessary. The Roles defined in the Authorization Profile will be used to create for the Client.
3. User requests access; update to not show Application as it is a user-based request; no credentials to collect - still need to click "Generate" for now
4. When an Access Manager goes to the Consumer, they will view/update the Roles based on the Product/Environment Client Roles
5. When a user logs in, they will be authenticated against the Client using the oidc plugin, and Consumer verification (TBD)?

No changes on the Authorization Profile is required, although the identity linking Client is created on the IdP.

UMA2

UMA2: Supporting UMA2 is a bit more involved - this is the case where the Resource Server has another set of Client credentials that are used to hold the Authorization resources and policies. This could be generated from the Authorization Profile. A "Portal" client is also created on the Realm as a Client to allow an Oauth2 flow, so that the Portal can get an access token to interact with the Resources owned by the Consumer (the Subject Token). The "Manage Resources" will first redirect to the IdP to authenticate and return with a code for retrieving an Access Token. The Access Token can be saved in the user session while interacting.

1. The "Manage Resources" will do a redirect to the IdP and handle the Callback to store the Subject Token in the Session; maintain list Brokered Identities for user
2. Validate Manage Resources still works

Will need to show how the Resource Server can be protected and how it can interact with the IdP using the "my-auth-profile-authz" to create/manage resources.

Additional Claims

Authorization Profile currently has an optional Audience as an additional claim. This is added to a Client Protocol Mapper, where in the case of a Client Credential, gets used as a hardcoded claim added to the Access Token.

In the case of an Application for SSO, these could be more sophisticated as they could provide different Mappers to include existing User Attributes. This could be further extended to allow these attributes to be administered for the Consumer via the Access Manager page.

Sub tasks:

• Design spike for backend
• Reference App (https://github.com/bcgov/aps-reference-app)
• UX updates
• Implement business rules
• Unit tests
• Implement UX updates

[ikethecoder]

Design spike changes:

• User Profile - Show/Delete Linked Accounts
• Authorization Profile - Authorization Code Flow generate Authz IdP broker
• Product Environment - Display/Re-gen Client ID / Client Secret for Application
• Request Access - Select / Link Identity, Skip Collect Credentials
• Approve Access - Show Brokered Identity vs Application
• My Access - Show Brokered Identity vs Application

[ikethecoder]

Feature branch testing: https://api-services-portal-feature-auth-code-flow.apps.silver.devops.gov.bc.ca/