Skip to Main Content
Feature Request FR-1762
Product Area Application Builder
Status ROADMAP

5 Voters

Allow for authentication by ldap groups or custom authentication schemes within the INTERNAL workspace

sdstuber Public · Aug 20 2021

Idea Summary
Allow the same level and type of authentication schemes within the internal workspace as within application Workspaces.

Use Case
When administration responsibilities for APEX fall to a group, one must manually add or remove users from each APEX installation.  It would be easier and more secure if the authentication could be based on LDAP group membership or custom rules to integrate with whatever enterprise authentication system the installer uses.

Preferred Solution (Optional)
Allow the same methods and APIs already in place for application workspaces to be used in INTERNAL ones.

This is currently on the roadmap for a future release of Oracle APEX.

Comments

Comments

  • vladislav.uvarov APEX Team OP 3.1 years ago

    APEX has supported custom authentication schemes for App Builder since APEX 5.0. See Configuring Authentication Schemes for an Instance in documentation. With this feature, you can outsource administrator and developer authentication to an external Identity Provider.

    However, developer authorization is currently still handled within APEX. Once the user is authenticated externally, which workspaces will this user have access to? And whether the user will have workspace administrator or workspace developer privileges in given workspace? To control this, you currently have to create a named account in the APEX Accounts Repository even for externally authenticated users. And if access to multiple workspaces is required, you have to create multiple accounts (one in each workspace). This is not practical for organizations with hundreds of developers.

    Perhaps this Idea is asking for a way to outsource developer authorization to the external Identity Provider as well. In addition to asserting developer's identity, the Identity Provider would also state - via roles/groups - which workspaces this user has access to and whether the user is an administrator or a developer. Roles/groups would also need to be tied to a particular APEX instance (since multiple instances can have workspaces with same names).