Okta Group Aliasing

When large numbers of Okta groups are associated with an Okta application, it can be difficult for users to decide which group they need to request access to. Okta Group Aliasing allows admins to configure the association and naming of Okta groups to be more easy for end users to understand without altering the groups in Okta.

To outline the problem described above, we will walk through an example case. Below you will find an example of a Figma application from Okta already imported into Opal.

In the administrator and product owner view, the list of groups in "Resources" are the list of groups that have access to the Okta application. Each of these groups might have access to applications other than Figma.

End users will see a different view, where Okta groups are represented as roles, and they see the list of groups with access to the Okta app to choose from, as a role.

Because the list and naming of the list of groups is imported directly from Okta, the naming and listing of groups might be unintuitive to an end user. This makes it difficult for an end user to choose the right group to request. In. this example, Engineering Birthright is a group just for engineers that won't make sense for users outside of that organization to see it as an option. Figma viewer is a correctly named and intuitive to understand group. Design Tooling could give edit access, but isn't named in a way that makes this clear.

There are three use cases covered by Okta aliasing:

Hiding groups that admins do not want end users to request on an Okta app page. For example, the engineering birthright group above. That particular engineering birthright group might be intended to include employees in the engineering organization to grant access to the wider set of engineering tools including Figma, but an administrator would not intend for other users to access it. You can use Okta aliasing to hide this group from end users so they do not request it. Hiding this group does not alter its display within Okta and it will still be visible to admins and product owners in the Inventory.
Renaming an Okta group for a particular Okta application so users know which group to request. For example, aliasing "Design Tooling" as "Figma Editor" to make it clear which groups users who want edit access should request.
Adding an additional Okta group that does not have an access relationship in Okta. Okta push groups for example may need to be requested by an end user but will not have access to an Okta app directly. Becuase they do not have access to an Okta app directly,