Application Express Community
Application Express Community
| 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.
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.
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.
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.
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.
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.
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.
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)
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).
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.
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.