APEX 5 now provides us the ability to change how we log into the development builder itself, and it's surprisingly easy.
Recently I modified our APEX 5 sandpit to authenticate against LDAP, so we can use our Windows passwords logging into the APEX Development Builder - one less password to manage.
Database ACLI didn't need to apply an ACL to get this working in 11g APEX 4.2.1, but I did in 12c & 11g APEX 5 instances.
DECLARE l_acl VARCHAR2(100) := 'ldapacl.xml'; l_desc VARCHAR2(100) := 'LDAP Authentication for SAGE'; l_principal VARCHAR2(30) := 'APEX_050000'; -- upper case l_host VARCHAR2(100) := 'your-ldap-domain.com.au'; BEGIN -- Create the new ACL. -- Also, provide one starter privilege, granting the schema the privilege to connect. dbms_network_acl_admin.create_acl(l_acl, l_desc, l_principal, TRUE, 'connect'); -- Now grant privilege to resolve DNS names. dbms_network_acl_admin.add_privilege(l_acl, l_principal, TRUE, 'resolve'); -- Specify which hosts this ACL applies to. dbms_network_acl_admin.assign_acl(l_acl, l_host); COMMIT; END; /You can check what you have already with
select * from dba_network_acl_privileges where acl like '%ldap%'
Instance SecurityFirst log into the INTERNAL workspace and head to Instance Security settings. Under the authentication section you'll see a list of available schemes, all you need to do is change the 'current' scheme.
|Instance Security Settings|
Scheme SettingsThe declarative settings are just like those for your application. Getting the LDAP string correct for your environment can be tricky.
At our site I had one that worked for some of us, but not others. Then I found since we're using a Microsoft LDAP we can use the simple format of domain\%LDAP_USER%
|LDAP authentication attributes|
Note the message on the right hand side.
Even for external authentication schemes (e.g.HTTP Header Variable), you have to make sure that users exist as developers or administrators in the workspaces. Otherwise, Application Express will not be able to verify which workspace a user is allowed to work in.Now the login process authenticates against LDAP, but it still uses APEX user settings to determine authorisation.
ie - what type of user are they? administrator, developer etc.
Internal Workspace UsersSince level of access is still deferred to APEX accounts, don't forget to define workspace users specifically for the INTERNAL workspace that match the LDAP username.
|INTERNAL Workspace user list|
Rolling BackIf you leave your INTERNAL session logged in you can use another browser (or private session) to test authentication and revert the current scheme if necessary.
Alternatively, as described by the warning when applying the scheme change, you restore the authentication from SQL Developer using an API.
You'll need administration privileges:
Workspace Logon PageDon't forget to remind your developers what's going on, perhaps via a login message.
|APEX 5 login message|
The login message here is a running joke with our transient DBAs.