APEX has provided the ability to
authenticate your application users against an LDAP server for quite some time.
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 ACL
I 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 Security
First 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 Settings
The 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.
NOTE: 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 Users
Since 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 |
It's unlikely you will have an ADMIN account in your LDAP server, which is a good thing.
Rolling Back
If 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:
exec apex_instance_admin.set_parameter('APEX_BUILDER_AUTHENTICATION','APEX')
Workspace Logon Page
Don'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.
I've drafted a post where you can include JavaScript in the login message to make modifications to the login page, just like in
prior versions.