Logo Oracle Deutschland   Application Express Community
LDAP-Login am APEX Workspace - mit APEX 5.0
Erscheinungsmonat APEX-Version Datenbankversion Cloud oder on Premise
November 2015 5.0 11.2 und 12.1 on Premise

Eins der weniger bekannten neuen Features in APEX 5.0 ist die Möglichkeit, einen LDAP- oder Single Sign On Server zum Login am APEX Workspace zu nutzen. Für APEX-Anwendungen selbst ist dies schon immer möglich: man kann seine Anwendung mit einem beliebigen Authentifizierungsschema versehen, so dass keine eigene Passwortverwaltung mehr nötig ist. Genau dies ist jetzt auch für APEX-Workspaces möglich (Abbildung 1). Es gibt allerdings einige Dinge zu beachten - was, das beschreibt dieser Tipp.

Authentifizierungsverfahren für APEX-Workspaces in APEX 5.0

Abbildung 1: Authentifizierungsverfahren für APEX-Workspaces in APEX 5.0

Standardmäßig ist Application Express Accounts als Authentifierungsverfahren für die Anmeldung am APEX Workspace eingetragen - die Anmeldung erfolgt also, auch in APEX 5.0, zunächst mit den im Workspace selbst hinterlegten Usernamen und Passwörtern. Dies kann nun auf Database User, einen LDAP-Server, auf Oracle Single Sign On oder auf ein anderes Verfahren umgestellt werden. In diesem Tipp wird im folgenden davon ausgegangen, dass LDAP verwendet werden soll.

Beim späteren Arbeiten mit APEX hat eine zentrale Authentifizierung ganz entscheidende Vorteile - nicht nur dass die Entwickler mit ihren gewohnten Standardpasswörtern arbeiten können, auch das Hinzufügen eines neuen Entwicklers oder Administrators zu einem Workspace wird viel einfacher - das Versenden eines intialen Passworts und die obligatorische Änderung beim ersten Login fallen schlicht und einfach weg.

Wichtig zu wissen ist aber, dass diese Umstellung nur das Authentifizierungsverfahren selbst (also das Überprüfen des Passworts) betrifft. Damit APEX zwischen einem Workspace-Administrator, einem Entwickler oder End-User unterscheiden kann, müssen User nach wie vor in der APEX-Benutzerverwaltung angelegt werden.

Beim Anmelden am Workspace delegiert APEX die Authentifizierung an den konfigurierten "externen Dienst" (hier: LDAP) und bekommt von diesem einen Usernamen zurück. Oft ist das eine Mailadresse, das muss aber nicht zwingend so sein (LDAP-Usernamen sind von LDAP-Server zu LDAP-Server verschieden - mehr Details finden Sie weiter unten bei der Konfiguration der LDAP-Authentifizierung). Dann schaut APEX nach, ob der Username als Workspace-Administrator, Entwickler oder als End-User eingetragen ist, ob er nicht etwa gesperrt (locked) ist und baut die APEX Session entsprechend auf. Im folgenden wird davon ausgegangen, dass der LDAP-Username der Emailadresse entspricht.

Das gilt auch für den Workspace INTERNAL. Wenn der LDAP-Username des APEX-Administrators KARLHEINZ.ADMIN@MEINEFIRMA.DE ist, dann muss genau diese auch als Nutzerkonto für den Instanz-Administrator im Workspace INTERNAL eingetragen werden. Erledigen Sie dies auf jeden Fall zuerst, damit es nicht vergessen wird.

Instance-Administrator neu eintragen: Jetzt mit dem LDAP-Usernamen

Abbildung 2: Instance-Administrator neu eintragen: Jetzt mit dem LDAP-Usernamen

Diese Tatsache ist insbesondere wichtig, wenn der Workspace-Login einer bestehenden APEX-Instanz umgestellt werden soll. Oft folgen die in den APEX-Workspace bereits eingerichteten Admin- und Developer-User nicht den Standards des Unternehmens-LDAP oder Single-Sign-On-Servers (Username "ADMIN"). Besonders beim Workspace INTERNAL (APEX-Administration) ist normalerweise nur ein User namens ADMIN enthalten. Wird das Auhentifizierungsverfahren nun auf LDAP umgestellt, so ist der Login als "ADMIN" nicht mehr möglich, denn dazu müsste man sich als "ADMIN" am LDAP-Server anmelden - und das können nur die wenigsten. Auch der APEX-Administrator hat eine ganz normale Email-Adresse, die vom LDAP-Server als Username vergeben wird - genau die muss im Workspace INTERNAL als Userkonto eingetragen werden.

Nun wird verständlich, warum APEX bei Umstellung des Authentifizierungsverfahrens eine Warnung anzeigt und darin erklärt, wie man die Umstellung wieder rückgängig machen kann.

Workspace-Authentifizierung umstellen: APEX-Warnung

Abbildung 3: Workspace-Authentifizierung umstellen: APEX-Warnung

Zunächst muss also sichergestellt sein, dass jeder APEX-Workspace vor der Umstellung die korrekten Nutzernamen enthält. Für den Workspace INTERNAL macht man das am besten manuell. Für alle anderen Workspaces kann das ebenfalls manuell geschehen - und bei Instanzen mit nur wenigen Workspaces ist das auch sinnvoll. Enthält die APEX-Instanz dagegen sehr viele Workspaces, so muss man anders vorgehen.

Eine Möglichkeit ist sicherlich, alle Workspace-Eigentümer aufzufordern, die Anpassung selbst vorzunehmen. Damit wird der Aufwand einfach auf sehr viele Köpfe verteilt. Da APEX in der Datenbank läuft, kann man aber auch darüber nachdenken, den Vorgang größtenteils zu automatisieren. Voraussetzung ist allerdings, dass die APEX-Workspace-User sich eindeutig zu Emailadressen zuordnen lassen. Ob das möglich ist, hängt davon ab, welche Angaben beim Erstellen der Nutzerkonten gemacht wurden. Abbildung 4 zeigt einen günstigen und einen weniger günstigen Fall.

Hinterlegte Informationen zu einem APEX-User - 1 Hinterlegte Informationen zu einem APEX-User - 2

Abbildung 4: Hinterlegte Informationen zu einem APEX-User

Die folgende Query gibt eine Übersicht über die existierenden User. Wenn überall Email-Adressen vorhanden und diese gültig sind, so kann man das Erzeugen der neuen APEX-User mit PL/SQL erledigen.

select WORKSPACE_NAME, USER_NAME, IS_ADMIN, IS_APPLICATION_DEVELOPER, EMAIL 
from apex_workspace_apex_users 
order by 1,2;

WORKSPACE_NAME  USER_NAME    IS_ADMIN IS_APPLI EMAIL
--------------- ------------ -------- -------- -----------------------------------
CCZARSKI        ADMIN        Yes      Yes      carsten.czarski@meinefirma.de
CCZARSKI        MMUSTER      No       Yes      max.muster@meinefirma.de
DEV_PROJECTS    ADMIN        Yes      Yes      fritz.meier@meinefirma.de
FOKUSTHEMEN     ADMIN        Yes      Yes      john.doe@meinefirma.de
:               :            :        :        :

In diesem Beispiel müsste der Workspace CCZARSKI zusätzlich zu den Usernamen ADMIN und MMUSTER die Usernamen CARSTEN.CZARSKI@MEINEFIRMA.DE und MAX.MUSTER@MEINEFIRMA.DE enthalten. Mit dem PL/SQL-Paket APEX_UTIL und ein wenig Code im folgenden Skript lassen sich diese User automatisch anlegen. Für jeden APEX-User in allen APEX-Workspaces wird ein neuer User mit gleichen Einstellungen, aber mit der hinterlegten Mailadresse als Usernamen angelegt. Nach einem Commit sind alle User aktiv. Die alten User bleiben zumindest vorerst bestehen - so kann man die ganze Operation bei Bedarf einfach rückgängig machen. Außerdem mag es noch APEX-Anwendungen geben, an denen man sich mit diesen Konten anmeldet; die sollen ja noch weiterhin funktionieren. Die neuen Nutzerkonten erhalten auch ein Passwort - im Skript wird dazu ein String zufällig generiert. Damit können diese neuen Nutzerkonten nur für eine LDAP-Authentifizierung verwendet werden. Das Anmelden an einer Anwendung mit Authentifizierungsschema APEX Workspaces ist dann praktisch nicht möglich.

declare
  cursor cur is 
    select
      SECURITY_GROUP_ID,
      USER_ID,
      USER_NAME,
      FIRST_NAME,
      LAST_NAME,
      START_DATE,dbms_random.string('X',10)
      END_DATE,
      DESCRIPTION,
      EMPLOYEE_ID,
      PERSON_TYPE,
      EMAIL_ADDRESS,
      DEFAULT_SCHEMA,
      ALLOW_ACCESS_TO_SCHEMAS,
      ACCOUNT_LOCKED,
      ACCOUNT_EXPIRY,
      FIRST_PASSWORD_USE_OCCURRED,
      CHANGE_PASSWORD_ON_FIRST_USE,
      apex_util.get_GROUPS_USER_BELONGS_TO(user_name) GROUP_IDS,
      apex_util.get_user_roles(user_name) ROLES,
      ATTRIBUTE_01,
      ATTRIBUTE_02,
      ATTRIBUTE_03,
      ATTRIBUTE_04,
      ATTRIBUTE_05,
      ATTRIBUTE_06,
      ATTRIBUTE_07,
      ATTRIBUTE_08,
      ATTRIBUTE_09,
      ATTRIBUTE_10
    from wwv_flow_users;
   
 type cur_tab is table of cur%rowtype index by binary_integer;

 l_usertab cur_tab;
 l_userrow cur%rowtype;
begin
  for w in (
    select workspace, workspace_id from apex_workspaces where workspace_id not in (10,11,12)
  ) loop
    wwv_flow_api.set_security_group_id(p_security_group_id=>w.workspace_id);
  
    open cur;
    fetch cur bulk collect into l_usertab;
    close cur;
  
    for i in l_usertab.first..l_usertab.last loop
      apex_util.create_user(
        P_USER_NAME =>                    upper(l_usertab(i).email_address),
        P_FIRST_NAME =>                   l_usertab(i).first_name,
        P_LAST_NAME  =>                   l_usertab(i).last_name,
        P_DESCRIPTION =>                  l_usertab(i).description,
        P_EMAIL_ADDRESS =>                l_usertab(i).email_address,
        P_WEB_PASSWORD =>                 Im folgenden wird davon ausgegangen,
               dass der Username der Emailadresse entspricht.dbms_random.string('X', 15),
        P_GROUP_IDS =>                    l_usertab(i).group_ids,
        P_DEVELOPER_PRIVS =>              l_usertab(i).roles,
        P_DEFAULT_SCHEMA =>               l_usertab(i).default_schema,
        P_ALLOW_ACCESS_TO_SCHEMAS =>      l_usertab(i).allow_access_to_schemas,
        P_ACCOUNT_EXPIRY =>               l_usertab(i).account_expiry,
        P_ACCOUNT_LOCKED =>               l_usertab(i).account_locked,
        P_CHANGE_PASSWORD_ON_FIRST_USE => 'N',
        P_ATTRIBUTE_01 =>                 l_usertab(i).ATTRIBUTE_01,
        P_ATTRIBUTE_02 =>                 l_usertab(i).ATTRIBUTE_02,
        P_ATTRIBUTE_03 =>                 l_usertab(i).ATTRIBUTE_03,
        P_ATTRIBUTE_04 =>                 l_usertab(i).ATTRIBUTE_04,
        P_ATTRIBUTE_05 =>                 l_usertab(i).ATTRIBUTE_05,
        P_ATTRIBUTE_06 =>                 l_usertab(i).ATTRIBUTE_06,
        P_ATTRIBUTE_07 =>                 l_usertab(i).ATTRIBUTE_07,
        P_ATTRIBUTE_08 =>                 l_usertab(i).ATTRIBUTE_08,
        P_ATTRIBUTE_09 =>                 l_usertab(i).ATTRIBUTE_09,
        P_ATTRIBUTE_10 =>                 l_usertab(i).ATTRIBUTE_10
      );
    end loop;
  end loop;
end;

Natürlich kann dieses Skript noch erweitert werden; so können Sie alle User mit ungültiger Emailadresse ausgeben oder in eine separate Tabelle schreiben, damit diese nachträglich, manuell bearbeitet werden können. Wenn Sie sicher sind, dass jeder Workspace wenigstens einen Admin-User hat, dessen Username dem richtigen LDAP-Konto entspricht, können Sie das Workspace-Authentifizierungsverfahren umstellen. Navigieren Sie wiederum zum Workspace INTERNAL, dort zu den Instance Settings und dort zu Security. Am Abschnitt Authentication Control editieren Sie das Schema LDAP, indem Sie auf den Bleistift klicken.

LDAP-Authentifizierung für APEX-Workspaces auswählen

Abbildung 5: LDAP-Authentifizierung für APEX-Workspaces auswählen

Nehmen Sie die Einstellungen so vor, als ob Sie die LDAP-Authentifizierung für eine APEX-Anwendung einrichten würden (Abbildung 4). Wenn Sie fertig sind, klicken Sie zuerst auf Apply Changes und dann auf Make Current Scheme. Im folgenden sind die Einstellungen kurz beschrieben - je nach verwendetem LDAP Server können diese aber stark abweichen.

LDAP-Authentifizierung für APEX-Workspaces konfigurieren

Abbildung 6: LDAP-Authentifizierung für APEX-Workspaces konfigurieren

Bevor "es passiert", zeigt APEX Ihnen nochmals die Warnung an - sie sollten sich einigermaßen sicher sein, dass in allen Workspaces korrekte User vorhanden sind, mit denen sich die Entwickler einloggen können. Das Warnfenster zeigt Ihnen auch, was Sie tun müssen, wenn das Einloggen nicht mehr funktioniert. Loggen Sie sich in diesem Fall als SYS an der Datenbank an und setzen Sie folgenden Call ab, um das Authentifizierungsverfahren wieder auf APEX-Workspace-User zurückzusetzen.

APEX-Warnung vor dem Umstellen des Authentifizierungsschemas

Abbildung 7: APEX-Warnung vor dem Umstellen des Authentifizierungsschemas

begin
  apex_instance_admin.set_parameter('APEX_BUILDER_AUTHENTICATION', 'APEX');
end;
/

commit
/

Nach erfolgreichem LDAP-Setup sieht die APEX-Anmeldemaske genauso aus, wie zuvor; allerdings muss man zu Anmeldung nun die LDAP-Nutzernamen verwenden (Abbildung 8)

Anmeldung am APEX-Workspace mit LDAP-Nutzerdaten

Abbildung 8: Anmeldung am APEX-Workspace mit LDAP-Nutzerdaten

Verwendet man dagegen einen externen Single-Sign-On-Server, so sieht das Bild nochmals etwas anders aus. Denn dann gibt man Usernamen und Passwort nicht mehr in eine APEX-Anmeldeseite, sondern in die Login-Page des SSO-Servers ein. Demnach fragt APEX nach erfolgreichem Login nicht mehr nach Workspace, Usernamen und Passwort, sondern es stellt eine Auswahlliste der verfügbaren Workspaces bereit. Die Liste enthält alle Workspaces, mit denen der Nutzer (der sich ja erfolgreich über den SSO-Server angemeldet hat) arbeiten kann (Abbildung 9).

APEX-Login nach SSO-Anmeldung: Workspace-Auswahl

Abbildung 9: APEX-Login nach SSO-Anmeldung: Workspace-Auswahl

Auch die in vielen Unternehmen eingesetzte Windows-Authentifizierung lässt sich für den Workspace-Login nutzen. Für den Setup von APEX-Anwendungen steht seit einiger Zeit ein Dokument von Niels de Bruijn von der MT AG bereit (öffnen Sie den Menüpunkt Single Sign On). Dieser Ansatz lässt sich analog auch zur Workspace-Authentifizierung nutzen. Wenn Sie den kompletten Setup anhand des Dokumentes durchgeführt haben, stellen Sie HTTP Header Variable als Workspace-Authentifizierungsverfahren ein und legen Sie SSO_USER als Variable fest.

Windows-Login: HTTP Header Variable als Authentifizierungsverfahren wählen

Abbildung 10: Windows-Login: HTTP Header Variable als Authentifizierungsverfahren wählen

Damit haben Sie Ihren APEX-Server erfolgreich auf einen unternehmensweiten Login umgestellt. Wenn alle APEX-Anwendungen ebenfalls LDAP oder Single Sign On verwenden, so muss APEX selbst keine Passwörter mehr verwalten.

Was jetzt noch zu tun ist, obliegt den Entwicklern der einzelnen APEX-Anwendungen. Überall dort, wo die alten Workspace User noch verwendet werden, muss der Entwickler die Anwendung an die neue Situation anpassen. So findet man immer wieder Anwendungen, die in ihren Autorisierungsschemas schlicht den Usernamen auf ADMIN prüfen. Nachdem sich die Entwickler nun auch per LDAP-Konto am Workspace anmelden, wird diese Bedingung nicht mehr erfüllt werden; man muss diese Stellen also ändern.

Das Hinzufügen eines neuen Users zu einem Workspace wird einfacher als zuvor. Wo vorher noch ein Initialpasswort vergeben, versendet und beim ersten Login geändert werden musste, wird nun nur noch ein User angelegt, dessen Namen dem LDAP-Konto entspricht. Der Entwickler kann sich sofort mit seinem Standardpasswort anmelden. APEX passt sich noch besser in die Unternehmensstandards ein.

Zurück zur Community-Seite