Single Sign On (SSO)-Umgebungen erlauben es dem Endanwender, sich einmal am SSO-Server anzumelden und dann transparent auf viele Applikationen zuzugreifen. Im Gegensatz zu "traditionellen" Methoden muss man sein Passwort nicht jedesmal neu eintippen - einmal am Tag reicht. Auch Application Express-Anwendungen können in solche SSO-Umgebungen integriert werden. Für den Single-Sign-On-Server der Oracle Fusion Middleware sind bereits vorkonfigurierte Authentifizierungsschemata vorhanden - dieses How To beschreibt, wie APEX-Applikationen mit dem IBM Tivoli Access Manager (TAM) SSO-Server integriert werden kann.

Voraussetzungen

Software Versionen:

• Oracle Application Express 3.x
• IBM Tivoli Access Manager for e-business 4.1

Konfiguration IBM Tivoli Access Manager for e-business

• Generiere im IBM TAM eine Junction-Konfiguration für den Oracle HTTP Server (Apache) und seinen Port (normalerweise 7777).
• Dabei ist es wichtig, die folgenden Parameter zu beachten:
  • Das Setzen des Parameters -c iv_user stellt sicher, dass die Benutzerkennung an den Oracle HTTP Server und damit an Application Express weitergereicht wird.
  • Stelle sicher, dass der Rechnername, der mit dem Parameter -h angegeben wird, der vollqualifizierte DNS Name des Oracle HTTP Servers ist; unter diesem Namen muss Application Express im Netzwerk erreichbar sein.
  • Wenn der HTTP Server nicht auf Port 80 hört, füge den Parameter -v [apex-servername.domain]:[port] hinzu.
  • Füge die Option -j hinzu, damit JavaScript korrekt gefiltert wird.
  • Stelle sicher, dass der Parameter script-filter in der Konfigurationsdatei webseald.conf auf yes gesetzt ist.

Konfiguration Oracle Application Express (und HTTP Server)

Die Grundlage des Zusammenspiels zwischen dem WebSEAL SSO Server und Oracle ist die CGI Umgebungsvariable HTTP_IV_USER, welche nach einer erfolgreichen SSO Anmeldung am WebSEAL-Server die Benutzerkennung speichert.

Führe folgende Schritte aus:

• Gewährleiste, dass APEX als Standalone-Anwendung korrekt funktioniert, bevor die Integration mit dem Tivoli Access Manager durchgeführt wird.
• Stelle sicher, dass die CGI Umgebungsvariable HTTP_IV_USER an das Apache Modul mod_plsql durchgereicht wird. Editiere dazu die Konfigurationsdatei dads.conf im Verzeichnis $OHS_HOME/.../modplsql/conf (Achtung: in machen Installationen heißt die relavante Datei marvel.conf). und füge beim entsprechenden DAD für APEX die folgende Direktive hinzu:

  <Location /pls/apex>
  :
  PlsqlCGIEnvironmentList	HTTP_IV_USER
  :
  </Location>
  

  Anschließend ist ein Neustart des Oracle HTTP Servers erforderlich.
• Überprüfe, ob der Parameter ServerName (der Name des Rechners auf welchem der Oracle HTTP Server läuft) in der Apache-Konfigurationsdatei httpd.conf korrekt und in Kleinschreibung (speziell auf Windows 2000 Systemen) gesetzt ist. Eventuelle Änderungen wirken sich erst nach einem Neustart des HTTP Servers aus.
• Erstelle für das in APEX zu konfigurierende Authentifizierungsschema die Seiten-Sentry-Funktion CUSTOM_PAGE_SENTRY (s.u.) im Datenbankschema ein und vergebe EXECUTE-Privilegien an PUBLIC. Nutze dazu entweder den SQL Developer, SQL*Plus oder den SQL Workshop:

  CREATE OR REPLACE FUNCTION custom_page_sentry RETURN BOOLEAN
  AS
  --
  -- Page sentry using built-in session verification logic 
  -- and CGI Environment variable as the holder of the username. 
      l_current_sid number;
      l_tam_userid  varchar2(255) := upper(owa_util.get_cgi_env('HTTP_IV_USER'));
  BEGIN
      l_current_sid := wwv_flow_custom_auth_std.get_session_id_from_cookie;
  
      if wwv_flow_custom_auth_std.is_session_valid then
          wwv_flow.g_instance := l_current_sid;
          if l_tam_userid = wwv_flow_custom_auth_std.get_username then
  
              wwv_flow_custom_auth.define_user_session(
                  p_user=>l_tam_userid,
                  p_session_id=>l_current_sid);
              return true;
          else 
            -- username mismatch. 
            -- Unset the session cookie and 
            -- redirect back here to take other branch
              wwv_flow_custom_auth_std.logout(
                  p_this_flow=>v('APP_ID'),
                  p_next_flow_page_sess=>v('APP_ID')||':'||
                    nvl(v('APP_PAGE_ID'),0)||':'||l_current_sid);
              wwv_flow.g_unrecoverable_error := true; -- tell apex engine to quit
              return false;
          end if;
      else -- application session cookie not valid; we need a new apex session
          wwv_flow_custom_auth.define_user_session(
              p_user=>l_tam_userid,
              p_session_id=>wwv_flow_custom_auth.get_next_session_id);
          wwv_flow.g_unrecoverable_error := true; -- tell apex engine to quit
          --
          if owa_util.get_cgi_env('REQUEST_METHOD') = 'GET' then
              wwv_flow_custom_auth.remember_deep_link(
            p_url=>'f?'||wwv_flow_utilities.url_decode2(
              owa_util.get_cgi_env('QUERY_STRING')));
          else
              wwv_flow_custom_auth.remember_deep_link(p_url=>'f?p='||
                  to_char(wwv_flow.g_flow_id)||':'||
                  to_char(nvl(wwv_flow.g_flow_step_id,0))||':'||
                  to_char(wwv_flow.g_instance));
          end if;
          --
          -- register session in apex sessions table, set cookie, 
          -- redirect back
          wwv_flow_custom_auth_std.post_login( 
              p_uname     => l_tam_userid,
              p_flow_page => wwv_flow.g_flow_id||':'||
                nvl(wwv_flow.g_flow_step_id,0));
          return false;
      end if;
  END custom_page_sentry;
  /
  
  grant execute on custom_page_sentry to public
  /
  
  create public synonym custom_page_sentry for user.custom_page_sentry
  /
  

  Diese Funktion, die bei jedem Seitenaufruf ausgewertet wird, führt das Session-Handling in APEX durch. Der Zweck dieser Funktion ist es sicherzustellen, dass der Benutzer bereits an dem zuständigen WebSEAL SSO Server angemeldet ist, nur dann wird TRUE zurückgeliefert und der Durchgriff auf die damit konfigurierte APEX-Anwendung erlaubt.
• Definiere eine neues Authentifzierungsschema namens IBM Webseal SSO. Dabei sind folgende Einstellungen wichtig; für alle anderen können die Defaults übernommen werden (also nichts eintragen).

  "Seiten-Sentry-Funktion":	return custom_page_sentry
  "Ungültiges Session-Ziel: URL":	http://[sso-servername.domain]/[junction-name]/pls/apex/f?p=&APP_ID.:1
  "Berechtigungsprüfungsfunktion":	Keine ID-Daten verifizieren
  "Abmelde-URL":	http://[sso-servername.domain]/pkmslogout

• Neues Authentifizierungsschema als aktuelles Schema festlegen

SSO testen

Rufe eine APEX-Anwendung über folgende URL auf, um die Konfiguration zu testen:

• http://[sso-servername.domain]/[junction-name]/pls/apex/f?p=[apex-appid ]
  
  z.B. http://sso.server.de/apex10/pls/apex/f?p=109

Auch wenn die Anwendung unter der bisherigen APEX-URL http://server.de:7777/pls/apex/f?p=109 aufgerufen wird, wird automatisch auf obigen Zugang über den WebSEAL SSO Server umgeleitet.

Zurück zur Community-Seite