Feature flags

[xgp]

We need a mechanism to tell the wizard that certain features are on/off, and have certain enums/modes set.

1. the backend will serve a json file with a feature:value hash. this will be on a per realm basis. /auth/realms//wizard/config.json
2. the frontend will fetch this file when it loads and make it available (as a hook?). the utility that loads it should have fallback values for each expected flag

Current flags:

• groupMapping: true/false. whether group mapping steps should be displayed in the wizards and the group mappers should be created when calling the api
• apiMode: cloud/onprem. which APIs to use
• enableLdap: true/false. allow LDAP wizards (this is related to apiMode, but might change in the future, so adding it separately)
• enableDashboard: true/false. whether or not to show the dashboard and link

[jeffpatzer]

Added in the enableDashboard flag checks. Added in the enableLdap flag checks.

Need to enable apiMode and groupMapping. Are those ready to swap out api endpoints yet? I can't recall.

[xgp]

For apiMode, this dictates the API endpoints that can be used (e.g. for creating IdPs and IdP mappers, etc.)

Note, for cloud, you will need to have an orgId for the requests. This will be available in the Keycloak ID and Access tokens as org_id claim.

request	onprem endpoint	cloud endpoint	notes
get all IdPs	GET /:realm/identity-provider/instances	GET /:realm/orgs/:orgId/idps
create IdP	POST /:realm/identity-provider/instances	POST /:realm/orgs/:orgId/idps
get IdP	GET /:realm/identity-provider/instances/:alias	GET /:realm/orgs/:orgId/idps/:alias
update IdP	PUT /:realm/identity-provider/instances/:alias	PUT /:realm/orgs/:orgId/idps/:alias
import config	POST /{realm}/identity-provider/import-config	POST /:realm/orgs/:orgId/idps/import-config
add mapper to IdP	POST /{realm}/identity-provider/instances/{alias}/mappers	POST /:realm/orgs/:orgId/idps/:alias/mappers

Some of the onprem endpoints are available through the KcAdmin client. You can continue to use those, or switch to the URL with the same payload. Might be useful to put all of these in some kind of utility class. If this were Java, I'd do an interface and two implementations (for cloud and onprem) and load the implementation based on mode.

Events (and thus counts of logins, etc.) are currently unavailable when in cloud mode. These sections should be removed from the dashboard in this mode.

[xgp]

@jeffpatzer this is in prod now. org_id and organizations claims in the token for cloud mode. In order to try this out, you will need to generate a "portal link" using this API method: http://localhost:3000/api/create-a-link-for-the-organizations-admin-portal That will create a link that automatically logs in the org admin user with the customized token.

[jeffpatzer]

Status update:

• Abstracted path generation into a utility class.
• Auth0 SAML currently has been cloud and onprem split. This should make it such that the cloud version will make calls to those paths.
• AWS also has the onprem split.

• 103 resolved in this issue and PR because I needed access to the Feature Flag options.

I figure we can review the Auth0 and AWS to make sure its setup "as expected".

Remaining ones are very quick to migrate once we're good on that setup. I assume OIDC also needs to be updated.