Oracle Fusion Middleware Blog

Deutsche Informationen rund um Oracle Fusion Middleware

Archive for the ‘WebCenter’ Category

SAML SSO zwischen ADF Anwendungen und WebCenter Portal

leave a comment »

Hier werden die notwendigen Schritte zum Aufbau eines SAML basierten Single Sign Ons zwischen WebCenter Portal 11.1.1.8, auch als Spaces bekannt, und einer eigenen, beliebigen ADF Anwendung beschrieben. Mit anderen Worten, die abgesicherte ADF Anwendung kann seine Authentifizierung an WebCenter Portal weiter delegieren und dessen Benutzerkontext adaptieren.

Problembeschreibung

Wenn WebCenter beispielsweise um BPM Process Spaces erweitert wurde, ist in WeCcenter ein Aufgabenlisten TaskFlow verfügbar, der alle Aufgabe aus der BPM Suite anzeigt. Klickt man nun auf einen Eintrag in dieser Liste, so wird in einem Browser Pop-up Fenster die dazugehörige Task UI aufgerufen.

Picture1

Für dieses Szenario muss der Anmeldekontext von Webcenter an die ADF Anwendung übergeben werden, damit beispielsweise in der ADF Form ein Dokumentenupload als Prozessattachment in den Content Server vorgenommen werden kann. Dafür ist ein Web SSO zwischen Webcenter Portal und der ADF Anwendung nötig. Die empfohlene Vorgehensweise ist eine Einbeziehung beider Anwendungen in ein unternehmensweites SSO. Was macht man nun, wenn aber ein solches nicht vorhanden ist? Hier besteht die Möglichkeit, ein minimalistisches SSO auf der Basis von SAML aufzusetzen. Diese Lösung weist einige Einschränkungen auf (z.B. kein globales Single Sign Off), ist aber eine gültige Vorgehensweise und wird auch von WebCenter 11.1.1.8 weiterhin unterstützt. Der WebCenter Portal Admin Guide dokumentiert das Setup dazu im Kapitel 33 (siehe hier).

Lösung

Vorbemerkungen

Der hier beschriebene Lösungsweg berücksichtig SAML v1.1. aufgrund der durch WebCenter bereitgestellten Scripte. Nach jetzigem Stand wird SAML 2.0 mit WebCenter 12g unterstützt (unverbindlich). Wie bereits erwähnt, ist kein globales Single Sign Off in SAML v1.1. möglich. Das bedeutet, dass nach einer Abmeldung und Wiederanmeldung an WebCenter innerhalb der aktuellen Browsersession mit einem anderen Benutzernamen der vorherige Benutzerkontext für die ADF Anwendung beibehalten wird. Der Anwender muss also alle Browserfenster der Sitzung komplett beenden.

Es wird in der hier aufgezeigten Herangehensweise  keine SSL Verschlüsselung, wie im Normalfall bei Anmeldefenstern üblich, berücksichtigt, da nur der allgemeine Lösungsweg an einem einfachen Beispiel skizziert wird.

Als Voraussetzung muss natürlich WebCenter Portal korrekt installiert und konfiguriert sein. Der im Beispiel verwendete Weblogic Server für die eigene ADF Anwendung ist mit dem WebCenter Server in einer gemeinsamen Weblogic Domäne installiert. Eine BPM Suite Installation ist in diesem Fall nicht notwendig, da hier lediglich das Zusammenspiel zwischen der eigenen ADF Anwendung und WebCenter Portal im Fokus liegt. Die BPM Suite dient nur zur Veranschaulichung der Aufgabe.

Namenskonvention für das Beispiel

Hier sind die im Beispiel verwendeten Namen  und Pfade. Diese Werte müsssen natürlich für die eigene Umgebung angepasst werden.

  • Hostname = owc.vm.oracle.com
  • SAML Source Site = für die Anmeldung verantwortliche Anwendung = WebCenter Portal
  • SAML Destination Site = Zielanwendung, die die Authentifizierung von der Source Site übernehmen soll = eigene ADF Anwendung
  • SAMLAPP = Name der eigenen ADF Anwendung , Context root = /samlapp
  • Oracle Fusion Middleware Basisverzeichnis /oracle/fmw/
  • WLS Domäne
  • Name = dot8
  • Verzeichnis = /oracle/fmw/user_projects/domains/dot8
  • Weblogic Servernamen
  • WC_Spaces auf Port 8888 für WebCenter Portal
  • CustomApp auf Port 8100 für eigene ADF App (SAMLAPP)
  • Oracle HTTP Server wurde hier verwendet, ist aber nicht zwingend notwendig. WebCenter hört daher in diesem Falle auf Port 80
  • JDK installiert in /usr/java/jdk1.7.0_55
  • Domain Admin Account lautet weblogic/welcome1 (wird für wlst Anmeldung verwendet)

Aufsetzen des Managed Servers für ADF Anwendung

  1. Erstelle einen neuen WLS Server „CustomApp“ in der Domäne für Port 8100 über WLS Console
  2. Füge ADF Runtime über die EM Website hinzu
    • Wähle den neuen Managed Server in EM Website aus
    • Schalter “Apply JRF Template” wird sichtbar. Durch Anklicken werden alle notwendigen Bibliotheken dem Server zugewiesen

SAML 1.1 Konfiguration der Server

Zunächst sollte ein neuer Schlüssel im Standard Keystore DemoIdentity erstellt und anschließend in eine Zertifikatsdatei exportiert werden. Diese Zertifikatsdatei wird später in der Konfigurationsdatei wcsamlsso.properties referenziert

  1. Identifiziere in der WLS Konsole den Speicherort des Standard Keystores.
    Picture2
  2. Öffne eine SSH Shell und navigiere zu diesem Verzeichnis
    cd /oracle/fmw/wlserver_10.3/server/lib/
  3. Füge einen neuen Schlüssel zum DemoIdentity Keystore hinzu
    /usr/java/jdk1.7.0_55/bin/keytool -genkey -keypass testkeypass 
    -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase 
    -keyalg rsa -alias testalias
  4. Exportiere den Schlüssel in eine Datei
    /usr/java/jdk1.7.0_55/bin/keytool -export -keypass testkeypass 
    -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase 
    -alias testalias -file testalias.der
  5. Erstelle Credential Dateien zum automatisierten Domänenlogin in wlst
    cd /oracle/fmw/user_projects/domains/dot8/config/fmwconfig
    /oracle/fmw/Oraclew_WC1/common/bin/wlst.sh
    connect('weblogic','welcome1','localhost:7001')
    storeUserConfig('spacesconfig.secure', 'spaceskey.secure')
  6. Erstelle eine Verschlüsselung für das Schlüsselpasswort
    print encrypt(obj='testkeypass', domainDir='/oracle/fmw/user_projects/domains/dot8/')
    exit()
  7. Prüfe, ob in dem Verzeichnis die Dateien ordentlich angelegt wurden
  8. Navigiere zum WebCenter Home Verzeichnis und dort ins common/bin
    cd /oracle/fmw/Oracle_WC1/common/bin/
  9. Editiere die Datei wcsamlsso.properties. Die Sektion [spaces_config] sollte in etwa so aussehen
    [spaces_config]
     configFile = /oracle/fmw/user_projects/domains/dot8/spacesconfig.secure
     keyFile = /oracle/fmw/user_projects/domains/dot8/spaceskey.secure
     adminURL = localhost:7001
     usesSSL = false
     url = http://owc.vm.oracle.com/webcenter
     serverName = WC_Spaces
     certAlias = testalias
     certPassword = {AES}0ZvXfi7zJs89AkLXg5/tQzVIAKaV0ZeGIo+oNeM64VE=)
     certPath = /oracle/fmw/wlserver_10.3/server/lib/testalias.der

    Das Certpassword entsprich dem unter Punkt 6 erstellten Schlüssel

  10. Füge folgende Zeilen am Ende der Datei hinzu
    [custom_config]
     configFile = /oracle/fmw/user_projects/domains/dot8/spacesconfig.secure
     keyFile = /oracle/fmw/user_projects/domains/dot8/spaceskey.secure
     adminURL = localhost:7001
     usesSSL = false
     serverName = CustomApp
     certAlias = testalias
     certPath = /oracle/fmw/wlserver_10.3/server/lib/testalias.der
    [samlapp_config]
     url = http://owc.vm.oracle.com:8100/samlapp

    Beachte die Leerzeile nach jeder Sektion sowie am Ende der Datei. Ansonsten wird die Sektion nicht erkannt. Die komplette Beispieldatei liegt hier

  11. Navigiere zum Verzeichnis der SAML SSO Python Scripte, die durch die WebCenter Installation bereitgestellt werden
    cd /oracle/fmw/Oracle_WC1/webcenter/scripts/samlsso/
  12. Erstelle ein neues Script für die Sektion [custom_config]
    vi configureCustomApp.py
  13. Füge den Code aus dem Anhang hinzu und speichere die Datei ab
  14. Erstelle analog dazu eine neue Python Scriptdatei für die Sektion [samlapp_config]
    vi configureSAMLApp.py
  15. Füge den Code aus dem Anhang hinzu und speichere die Datei ab
  16. Navigiere zurück zu common/bin im WebCenter Home Verzeichnis
    cd /oracle/fmw/Oracle_WC1/common/bin/
  17. Starte wlst
    ./wlst.sh
  18. Prüfe, ob die Domain gestartet ist (AdminServer, WC_Spaces) und führe dann folgenden Befehl in der wlst Konsole im Offline Modus aus.
    execfile('/oracle/fmw/Oracle_WC1/webcenter/scripts/samlsso/configureSpaces.py')
  19. Prüfe Fehler und starte dann die Domäne durch (AdminServer, WC_Spaces, CustomApp)
  20. Nun werden relying party und asserting party angelegt. Starte dazu wlst nochmal
    ./wlst.sh
  21. Führe folgenden Befehl in der wlst Konsole im Offline Modus aus
    execfile('/oracle/fmw/Oracle_WC1/webcenter/scripts/samlsso/configureCustomApp.py')
  22. Starte wlst nochmal
    ./wlst.sh
  23. Führe folgenden Befehl in der wlst Konsole im Offline Modus aus
    execfile('/oracle/fmw/Oracle_WC1/webcenter/scripts/samlsso/configureSAMLApp.py')

Das wär’s für die SAML Konfiguration auf Serverseite. Aus Sicherheitsgründen sollten alle Dateien mit Anmeldeinformationen bereinigt werden, d.h. wcsamlsso.properties, und die Credential Dateien im Domänen Konfigurationsverzeichnis wieder gelöscht werden (spacesconfig.secure, spaceskey.secure)

Erstellen der ADF Anwendung

Für die SAML SSO Authentifizierung der ADF Anwendung sind zwei Hauptkriterien zuständig

  • Einschalten der ADF Security mit CLIENT-CERT Authentifizierung
  • Definition eines eindeutigen Cookie Pfades für die Anwendung. Dieser darf nicht mit anderen Cookie Pfaden kollidieren.

Erstellen wir nun eine einfache Beispielanwendung, die lediglich den Benutzernamen ausgeben soll.

  1. Starte JDev 11.1.1.7 und erstelle eine leere generische Anwendung
  2. Wähle ADF Faces als Projekt Technologiescope aus und beende den Assistenten
  3. Rechter Mausklick auf das Projekt und wähle „Project Properties
  4. Setze den JEE Anwendungskontext auf „SAMLAPP
    clip_image044
  5. Rechter Mausklick auf das Projekt und erstelle eine neue JSF Page (WebTier ->JSF). Nenne diese “start.jspx”.
  6. Rechter Mausklick auf “start. Jspx” und wähle “Go To Page Definition”. Klicke auf “YES” und die Page Definition Datei (“startPageDef.xml”) wird erstellt. Schließe die Datei.
  7. Platziere eine panelHeader Komponente auf die JSF Page sowie eine outputText Komponente
  8. Binde den outputText Value auf “Hello User : #{securityContext.userName}“. Die Seite sollte nun in etwa so aussehen.
    clip_image046
  9. Im JDev Hauptmenu rechter Mausklick auf Application -> Secure -> Configure ADF Security
    clip_image048
  10. Wähle “ADF Authentication and Authorization” -> klicke “Next” -> wähle “HTTPS Client Authentication” -> klicke “Next” -> Akzeptiere die Vorgabewerte “No Automatic grants” -> klicke “Next” -> markiere “Redirect Upon Successful Authentication” und wähle “start.jspx” als Welcome Page -> klicke “Next” -> “Finish
  11. Öffne im Application Resource Fenster die Datei “jazn-data.xml
  12. Klicke auf “Resource Grants” und wähle ”Web Page” als “Resource Type
  13. start.jspx” sollte schon ausgewählt sein. Füge eine “Application Role” hinzu.
    clip_image050
  14. Markiere “Authenticated Role” und klicke “OK
  15. Akzeptiere die “View” Rechte und speichere alles.
  16. Öffne im Projects Fenster die Datei “web.xml”, klicke auf “Source” Ansicht und scrolle nach unten ans Ende der XML Datei
    clip_image052
  17. Dort gibt es ein login-config Attribut. Ändere den Code zu
       CLIENT-CERT,BASIC
       jazn.com
    
  18. Speicher alles
  19. Öffne im Projects Fenster die Datei “weblogic.xml”
  20. Füge folgende Zeilen the oberhalb der letzen Zeile hinzu
       /samlapp
    
    
  21. Denke daran, dass der Cookie Pfad für diese Anwendung einzig sein muss. Nutz nicht /webcenter , da dies schon durch die WebCenter portal Anwendung in Gebrauch ist. Empfehlenswert ist die Angabe des URL Context Pfades, also /samlapp beispielsweise.
  22. Speicher alles.
  23. Erstelle ein WAR Deployment Profil für das Projekt
    (rechter Mausklick auf Project -> “Project Properties” -> “Deployment” -> “New” -> Wähle “WAR File” -> gib einen Namen an -> klicke “OK” 3 mal
  24. Erstelle ein Application Deployment Profil
    (JDev Hauptmenu -> “Application” -> “Application Properties” -> “Deployment” ->”New” -> Wähle “EAR” -> gib einen Namen an (z.B. SAMLAPP) -> klicke auf “OK” -> wähle “Application Assembly” -> markiere das WAR Deployment Profil -> klicke auf “OK” zwei mal
  25. Speicher alles.
  26. Deploye die Anwendung auf den “CustomApp” Server, der zuvor erstellt und konfiguriert wurde.
    (Jdev Hauptmenu -> “Application” -> “Deploy” -> “SAMLAPP” -> “Deploy to Application Server” -> klicke “Next” -> Wähle die Appserver Connection bzw. Erstelle eine neue für die WebCenter Domain -> wähle “Deploy to selected instance” -> wähle “CustomApp” als Zielserver -> klicke “Next” -> klicke “Finish

Das war‘s. Nun kann man die Anwendungs URL (http://owc.vm.oracle.com:8100/samlapp/faces/start.jspx ) in einem Webbrowser aufrufen und man müsste zur WebCenter Anmeldeseite weitergeleitet werden. Nach erfolgreichem Login erfolgt die Weiterleitung zurück zur Startseite der SAMLAPP und der aktuelle Benutzername sollte erscheinen.

<DM>

Anhang

Bitte alle Dateien ohne Endung xls abspeichern

configureCustomApp.py

configureSAMLApp.py

wcsamlsso.properties

Advertisements

Written by fmtechteam

30/04/2015 at 10:26

Veröffentlicht in ADF, Detlef Müller, WebCenter

WebCenter Content – WebDav als Laufwerk mappen

leave a comment »

Gelegentlich ist ein WebDav Zugang zum Content Server nötig, um aus Anwendungen heraus über das Filesystem des Clients Inhalte in den Content Server zu laden. Normalerweise würde man hier die Desktop Integration Suite nutzen, die eine Integration in den Windows Explorer sowie in MS Office bereitstellt.

image

Das Problem ist aber, dass nicht alle Anwendungen beim File Browsing, z.B. “Speichern unter”, auf die DIS zugreifen können. Als Beispiel sei hier mal der JDeveloper erwähnt – ohne Relevanz, ob es überhaupt Sinn macht aus dem JDeveloper in den Content Server zu speichern. Es gibt viele Anwendungen, die sich beim File Browsing wie JDeveloper verhalten.

image

In diesem Falle muss man erreichen, dass ein WebDAV Zugang als Netzlaufwerk mit Laufwerksbuchstaben ins Windows eingehängt wird. Das kann man entweder über alternative WebDav Clients oder nativ über den Windows Befehl  “net use” realisieren. Die Syntax der Befehlszeile für den Content Server lautet dann:

net use [Laufwerk]: „http://[CS Host]:[CS Port]/_dav/[CS Context]/idcplg/webdav/[Folder or Library Path]/“ /persistent:no /user: [Username Password]

Es gibt diverse Problemchen Seitens Windows im Umgang mit Basic Authentication. (Siehe KB2673544).  Bei alternativen WebDAV Clients muss man auf die korrekte WebDAV URL des Content Servers achten. Die Adresse in der DIS ist nicht die allgemeine WebDAV URL und daher etwas irreführend.

<DM>

Written by fmtechteam

08/07/2014 at 12:19

Veröffentlicht in Detlef Müller, WebCenter, WebCenter Content

Tagged with

BPM Process Spaces funktionieren nicht mehr bei eigenen Portal Erweiterungen

leave a comment »

Die Bereitstellung von eigenen TaskFlows im Webcenter Portal wird letztlich über ein fertiges JDeveloper Projekt vorgenommen, welches über die WebCenter Extensions verfügbar ist. In diesem Projekt ist ein Deplyoment Profile und ein Manifest hinterlegt, welches die Erweiterungen als Shared Library auf den Portal Server deployt.

image

Die Dokumentation hierzu ignoriert aber den möglichen Umstand, dass bereits weitere Bibliotheken in WebCenter referenziert werden, so zum Beispiel die BPM TaskFlows der Process Spaces Implementierung. Die Konsequenz daraus ist, das mit dem Erweitern des Portal um eigene TaskFows bereits bestehende Referenzen überschrieben werden und die Process Spaces nicht mehr funktionieren. In diesem Falle muss man die BPM Referenzen im Manifest zusätzlich eintragen. Das MANIFEST.MF des eigenen PortalSharedLibrary Projektes sollte dann so aussehen:

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: builder
Build-Jdk: 1.6.0_20
Extension-Name: extend.spaces.webapp
Implementation-Label: 11.1.1.8.0
Implementation-Title: extend.spaces.webapp
Implementation-Vendor: Oracle
Implementation-Version: 11.1.2
Specification-Title: extend.spaces.webapp
Specification-Vendor: Oracle
Specification-Version: 11.1.1
Extension-List: bpmSpaces
bpmSpaces-Extension-Name: oracle.bpm.spaces

Nun kann man wie gewohnt seine Portal Extension deployen und behält dabei die BPM Referenzen für die Process Spaces.

<DM>

Written by fmtechteam

11/06/2014 at 16:24

Veröffentlicht in BPM, Detlef Müller, WebCenter

Neu: Pre-built Virtual Machine für SOA Suite und BPM Suite 11.1.1.7.1

leave a comment »

Diese Appliance ist nur für Testzwecke und nicht für die Produktion bestimmt!

http://www.oracle.com/technetwork/middleware/soasuite/learnmore/vmsoa-172279.html

<Kersten Mebus>

Written by fmtechteam

14/05/2014 at 13:36

Veröffentlicht in BPM, Kersten Mebus, SOA, WebCenter

Performanceanalyse von WebCenter Portal

leave a comment »

Wer aus alten Zeiten das Oracle Portal noch gut kennt, der hat vielleicht noch den URL Parameter _debug (http://docs.oracle.com/cd/B14099_19/portal.1014/b19305/cg_app_c.htm#i643076) in Erinnerung und schätzen gelernt. Hierüber bekam man angezeigt, welche Zeit für welches Portalseitenelement bzw. für welche Phase des Renderns benötigt wurde. So konnte man mögliche Performance Bottlenecks des Portals genauer lokalisieren.

Mit dem WebCenter Portal 11.1.1.8 gibt es nun auch eine Möglichkeit, ein solches Performance Debugging einzuschalten und die einzelnen Services auf der Portalseite zu messen.

image

Im WebCenter Portal Admin Guide beschreibt das Kapitel G4: Troubleshooting Oracle WebCenter Portal Performance Issues das Vorgehen zur Performanceanalyse.

Zuerst muss der Performance Debug Modus auf dem Portal per WLST Kommando, wie in der Doku beschrieben, eingeschaltet werden. Dazu werden zuerst Portalkonfigurationen aus dem MDS gelesen und in eine webcenter-config.xml ins Filesystem extrahiert. Dann schaltet man in dieser Datei den Debug Modus ein und importiert sie schließlich über WLST wieder zurück ins MDS. Ein Neustart des Portals ist nicht notwendig.

Die Anzeige des Timings schaltet man dann auf der Portalseiten URL mit dem Parameter &perfDebug=on ein bzw. mit &perfDebug=off wieder aus. Es werden nun die einzelnen Taskflow Renderingzeiten ermittelt und farblich gekennzeichnet.

Farbe Zeit
grün <100ms
grün/gelb 100 – 500ms
gelb 500ms –1s
orange 1-3s
rot >3s

 

<DM>

Written by fmtechteam

24/10/2013 at 15:40

Änderung des Hostnamens einer FMW Domain inklusive WebTier

leave a comment »

Manchmal kommt es vor, dass eine Fusion Middleware Domain (SOA, BPM, WebCenter, …) umziehen muss und sich der Hostname dadurch ändert. Das kann zum Beispiel notwendig werden, wenn man eine virtuelle Umgebung vervielfältigt bzw. verschiebt, oder man im Rahmen einer Cloudlösung eine neue FMW Instanz auf Basis eines Templates anlegt und im zugrundeliegenden Template ein anderer Hostname konfiguriert wurde.

In der Fusion Middleware Dokumentation ist beschrieben, wie eine solche Änderung der Netzwerkkonfiguration vorgenommen wird. Das betrifft im Wesentlichen

  • ein Umzug der Datenbank mit dem FMW Repository
  • ein Umzug des Nodemanagers
  • ein Umzug der Managed Server
  • ein Umzug der WebTier

Darüber hinaus muss man auch die Registratur der WebTier Instanz im Fusion Middleware Control (EM Website) aktualisieren. Diese Registratur wird vom chgiphost Script nicht angefasst. Der EM spricht den OPMN der Instanz über den in der topology.xml eingetragenen Hostnamen an, was dazu führt, dass entweder ein Fehler beim Starten/Stoppen der Instanz über die EM Website geworfen wird oder im schlimmeren Fall, wenn der alte Hostname noch existiert, der OPMN der alten Instanz angesprochen wird. Man muss also die Registratur der WebTier Instanz auch noch korrigieren. Dazu geht man wie folgt vor.

  1. Aktualisierung <DOMAIN_HOME>/opmn/topology.xml mit dem richtigen Hostnamen
  2. Wechsel ins Verzeichnis <MW_HOME>/<WT_HOME>/instances/<INSTANCE>/bin/
  3. Instanz stopppen,
    ./opmnctl stopall
  4. Instanz aus der Domain deregistrieren (Domain mus gestartet sein),
    ./opmnctl unregisterinstance –instanceName <INSTANCE> –adminHost <DOMAINHOST> –adminPort <ADMIN PORT>
  5. Instanz neu registrieren,
    ./opmnctl registerinstance –adminHost <DOMAINHOST> –adminPort <ADMIN PORT>
  6. Instanz starten,
    ./opmnctl startall
  7. Instanz überprüfen,
    ./opmnctl status

In der EM Website müsste nun die aktualisierte WebTier verwaltet werden können.

Schießlich müssen auch noch, je nach Ausstattung der Domain, diverse Korrekturen in den installierten Anwendungen bzw. FMW Produkten  vorgenommen werden. Im Falle des Content Server sollte man das Setup aller outgoing providers überprüfen und ggf. korrigieren, zum Beispiel für den Inbound Refinery Server. Auch die Konfigurationsparameter HTTServerAddress in der config.cfg des Content Servers bzw. Inbound Refinery Servers muss aktualisiert werden (<DOMAIN_HOME>/ucm/cs/config/config.cfg, <DOMAIN_HOME>/ucm/ibr/config/config.cfg). Sollte WebCenter Portal (aka WebCenter Spaces) in der Domain vorhanden sein, so muss man auch die Registratur der WebCenter Services ggf. korrigieren (EM Website). Man sollte schließlich auch nicht vergessen, in die httpd.conf des OHS zu schauen und den Hostnamen dort ggf. aktualisieren.

Diese Thematik kann unter Umständen sehr komplex werden. Je komplexer die Domain aufgesetzt ist (Produkte, Clustering, Verteilung usw.), desto aufwendiger wird auch ein solcher Serverumzug.

<DM>

Written by fmtechteam

10/10/2013 at 17:40

Veröffentlicht in BPM, Detlef Müller, SOA, WebCenter, WebLogic

Integration BPM TaskList Portlet in Oracle Portal 11g

leave a comment »

Verweise und Dokumentationen

  1. Oracle® Fusion Middleware Developer’s Guide for Oracle SOA Suite -> ConfiguringTask List Portlet
  2. Oracle® Fusion Middleware Administrator’s Guide for Oracle WebCenter Portal -> Configuring WS-Security
  3. Oracle® Fusion Middleware Administrator’s Guide for Oracle Portal -> Securing Access to Web Services Remote Portlets

Vorbemerkungen

Die TaskList Portlet Anwendung ist eine Produktkomponente der BPM Suite und somit funktional vorgegeben. Jegliche Änderungen der Logik, der Inhalte und des Layouts sind ohne weiteres nicht möglich. Im Wesentlichen ist dieses Portlet eine Abbildung der Worklist App der BPM Suite. Folgende Bilder zeigen das TaskList Portlet in einer WebCenter Portalanwendung sowie im Oracle Portal.

clip_image002

clip_image002[4]

Eine Gesamtarchitektur des Setups sieht wie folgt aus

clip_image002[9]

Die Portletanwendung wird auf dem Managed Server der SOA Suite installiert. Dazu muss der Managed Server zuvor mit der Portletlaufzeit erweitert werden. Weiterhin muss der WSRP request über SAML abgesichert werden, damit die Identität des Portalusers zum Portlet propagiert werden kann. Dies setzt auch voraus, dass sowohl Portal als auf BPM Suite denselben Userstore verwenden.

Im Folgenden ist die Herangehensweise der Integration beschrieben.

Vorbereitungen

  • FMW Repository der SOA Domain über RCU mit <präfix>_Portlets erweitern
  • Laufzeitumgebung für Portlets bereitstellen
    • Domain komplett stoppen
    • Installieren der WebCenter Software ins Middleware Home auf dem SOA Server
    • SOA Domain mit Oracle Portlet Producer- 11.1.1.0 (Oracle_WC1) erweitern
      • DB Verbindung auf das eben erstellte PortletDS Schema setzen
      • Auf der Wizard Seite „Optionale Konfiguration“ Deployments und Services“ aktivieren

        clip_image002[11]

      • Bei den Deploymenteinstellungen bitte schauen, welche Bibliotheken und Anwendungen nur auf das Target WC_Portlet aktiviert ist. Diese bitte auch auf das Target soa_server1 setzen.
        Das müssten sein

        • oracle.portlet-producer.jpdk(11.1.1,11.1.1)
        • oracle.portlet-producer.wsrp(11.1.1,11.1.1)
        • oracle.webcenter.skin(11.1.1,11.1.1)
        • portalTools (11.1.1.4.0)
        • wc-producer-web-lib(11.1.1,11.1.1)
        • wlp-framework-common-web-lib(11.1.1,11.1.1)
        • wlp-light-core-web-lib(11.1.1,11.1.1)
        • wlp-producer-full-web-lib(11.1.1,11.1.1)
        • wlp-wsrp-producer-core-web-lib(11.1.1,11.1.1)
        • wsrp-tools (11.1.1.4.0)
        • Bitte auch die PortletDS Datasource auf das Target soa_server1 setzen
    • Domain starten (nur AdminServer und soa_server1, aber nicht WC_Portlet . Diesen kann man über die WLS Konsole entfernen) und testen, ob die WSRP Tools funktionieren (http://<soaserver>:<soaport>/wsrp-tools )
  • Deployen eines Testportlets in das Target soa_server1, um zu sehen, ob alles gut funktioniert.

clip_image002[13]

clip_image002[15]

Der rot gekennzeichntete Link gibt die WSRP URL an, die beim Registrieren des Producers im Portal verwendet wird. Es wird hier nur überprüft, ob die Anwendung als WebService ansprechbar ist, nicht aber, ob der Inhalt der Anwendung fehlerfrei ist. Um das zu sehen, kann man oben den Link run as servlet aufrufen.

TaskList Portlet Deployen

  • Aus der SOA Domain in WLS Konsole auswählen
    • Deployments
    • Install
    • Current Location auf <Oracle_Home>/<SOA_Home>/soa/applications setzen
    • TaskListPortlet.ear auswählen
  • Target auf soa_server1 setzen
  • Deployment finalisieren
  • Url testen http://<soaserver>:<soaport>/TaskListPortlet und auf WSRP v2 klicken
    Achtung: die Url in der Dokumentation (1) ist falsch. Diese hier ist richtig.

Security (SAML) konfigurieren

Damit der Consumer (Oracle Portal) den aktuellen Benutzerkontext an das Portlet verlässlich übermitteln kann, müssen beide Parteien eine Vertrauenswürdigkeit in Form eines Keystores und der darin enthaltenen Public / Private Keys ausgemacht haben. Daher wird jeweils ein Keystore für den Consumer (portal.jks) und für den Producer (portlet.jks) angelegt und darin die entsprechenden public bzw. private keys registriert. In der Dokumentation (2) gibt es weitere Hinweise für das Erstellen solcher Keystores. Wir beziehen uns hier auf eine Typical Topology, das heißt 2 verschiedene Domains.

Da noch kein Keystore existiert, wurden diese mit dem keytool aus dem JDK erstellt. Dieser Vorgang ist einmalig, d.h. die Keystores sind universell und können auch auf andere Maschinen übertragen (kopiert) und dort eingesetzt werden. Für das Erstellen eines neuen Keystores empfiehlt es sich, den Pfad auf das Keytool in die Umgebungsvariable PATH aufzunehmen , <jdk_home>/jre/bin . Man kann beide keystores in einer Arbeitssequenz erstellen und dann auf die jeweiligen Server kopieren.

Keystores erstellen

  • keytool -genkeypair -keyalg RSA -dname „cn=portal,dc=oracle,dc=com“ -alias portal -keypass welcome1 -keystore portal.jks -storepass welcome1 -validity 4000
  • keytool -exportcert -v -alias portal -keystore portal.jks -storepass welcome1 -rfc -file portal_public.cer
  • keytool -importcert -alias portal_ws -file portal_public.cer -keystore portlet.jks -storepass welcome1
  • keytool -genkeypair -keyalg RSA -dname „cn=portlet,dc=example,dc=com“ -alias portlet -keypass welcome1 -keystore portlet.jks -storepass welcome1 -validity 4000
  • keytool -exportcert -v -alias portlet -keystore portlet.jks -storepass welcome1 -rfc -file orakay.cer
  • keytool -importcert -alias orakey -file orakay.cer -keystore portal.jks -storepass welcome1

SAML Konfiguration für Portlet Server

  • Kopieren des Keystores portlet.jks auf den Portlet Server (SOA Suite) nach <domain_home>/config/fmwconfig
  • Registrieren des Keystores in FMW Control
    • Weblogic Domain -> <Domain auswählen> -> Security -> Security Provider Configuration

      clip_image002[17]

    • Keystore aufklappen und auf Configure klicken

      clip_image002[19]

    • Formular ausfüllen
      • Keystore Type: Java Key Store (JKS)
      • Keystore Path: ./portlet.jks
      • Password: welcome1 (s.o.)
      • Confirm password : welcome1 (s.o.)
      • Signature Key Alias: portlet
      • Signature Password : welcome1 (s.o.)
      • Confirm password : welcome1 (s.o.)
      • Encryption Key Alias: portlet
      • Crypt Password: welcome1 (s.o.)
      • Confirm password : welcome1 (s.o.)

        clip_image002[21]

    • OK Klicken
    • Domain komplett neu starten (AdminServer, soa_server1)

SAML Konfiguration für Portalserver

  • Kopieren des Keystores portal.jks auf den Portal Server nach <domain_home>/config/fmwconfig
  • Registrieren des Keystores in FMW Control analog wie auf dem Portlet Server nur mit
    • ./portal.jks
    • portal als Alias Namen für die Keys

      Anmerkung: Da auf dem Portalserver der OWSM nicht installiert ist, sollte eigentlich eine Registratur über FMW Control überflüssig sein. Dennoch ist es nicht verkehrt, hier den Keystore zu registrieren., Wichtig ist, das der Keystore auf den Portalserver kopiert wird. Er wird später im Oracle Portal nochmal extra registriert

WSRP Endpoint des TaskList PortletApp sichern

Jetzt muss dem WSRP Service noch eine SAML Policy angehängt werden

  • Auf dem Portlet Server (SOA Suite) FMW Control starten
  • Öffne im Navigationsbaum Application Deployments -> TaskListPortlet
  • Öffne Menü Application Deployment -> Web Services

    clip_image002[23]

  • Wähle WSRP v2 Markup Service
  • Wähle Tabreiter OWSM Policies und klicke auf Attach/Detach

    clip_image002[27]

  • Wähle die Poliy oracle/wss10_saml_token_service_policy aus und klicke auf Attach. Sollte eine andere Policy bereits attached worden sein, bitte diese auswählen und Detach klicken. Speichern mit OK

    clip_image002[29]

  • Bitte den Managed Server (soa_server1) neu starten

Registratur des TaskList Portlets im Oracle Portal

Registratur des Keystores im Portal

  • Anmelden am Portal als Portal Admin (orcladmin)
  • Wähle Administer -> Global Settings

    clip_image002[31]

  • Wähle Tabreiter Keystore
    • Store Path : <absoluter Pfad zum Keystore> /portal.jks
    • Store Password : welcome1
    • Store Type : JKS

      clip_image002[33]

  • Klicke auf OK. Server muss nicht neu gestartet werden

Registratur des Producers

clip_image002[35]

clip_image002[37]

Das war’s. Das Portlet liegt nun im Portlet Repository und muss nur noch auf die gewünschten Seiten platziert werden.

Einschränkungen und sonstige Hinweise

Man darf nicht außer Acht lassen, dass diese Portlet eine Verwendung in Oracle Portal nicht explizit berücksichtigt. WSRPv2 ist der kleinste gemeinsame Nenner und sorgt nur dafür, dass das Portlet grundsätzlich funktionieren sollte. Da WebCenter und Oracle Portal komplett unterschiedliche Basistechnologien verwenden, gibt es naturgemäß auch entsprechende Brüche und Reibungsverluste.

Portlet Parameter

Das TaskList Portlet besitzt diverse Initialisierungsparmeter, die beim Instanzieren eines Portlets optional gesetzt werden und die die Darstellung der Portletinnhalte steuern können (siehe Dokumentation 1 – 36.4 Passing Worklist Parameters) . Werden die Parameter nicht gefüllt, ziehen Default Werte. Im WebCenter Portal kann man die Parameter im Editiermodus des Portlets sehen und füllen. Diese Parameterliste sieht man aber im Oracle Portal nicht, genauer genommen kennt das Oracle Portal den Editiermodus des Portlets gar nicht. Will man dennoch das Verhalten des Portlets über die Portletparameter steuern, so müsste man vielleicht die Default Werte in der portlet.xml der Portlet App überschreiben. Das heißt,

  • TaskListPortlet.ear auspacken
  • WAR Archiv auspacken
  • portlet.xml im WEB-INF Ordner editieren
  • Archive wieder einpacken
  • TaskListPortlet.ear neu deployen

Diese Vorgehensweise ist zum einen nicht verifiziert und zum anderen werden dann die Parameter, die eigentlich nur für die entsprechende Portlet Instanz gelten sollen, für alle Portlet Instanzen gültig. Das kann also bestenfalls nur ein Workaround sein.

Layout / Skins

Da Oracle Portal nichts mit ADF Faces und dem Skinninng zu tun hat, ziehen die normalen Trinidad Skins. Will man ein spezielles Skinning erhalten, müsste man evtl. einen Portalservice bauen (meinetwegen eine Content Komponente), der die notwendigen CSS Definitionen in die HTML Seite legt, oder man muss das Portlet EAR auspacken und eigene, neue Skins hinzufügen, alles wieder einpacken und neu deployen. Auch das ist nicht verifizert und nur eine Lösungsidee.

Dokumentationsfehler

Die Dokumentation (1) weist Fehler auf. Beispielsweise weicht die angegebene Parameterliste von der Realität ab. Es gibt z.B. den Parameter soaURL gar nicht, der die Verbindung zur SOA Suite definieren soll. Das Problem wurde hier so gelöst, dass das Portlet auf dem SOA Server deployt wurde, so dass hier diverse JNDI Einträge und andere Artefakte sowohl für die SOA Suite als auch fürs Portlet gelten.

Es sind einige kleine Unstimmigkeiten, Ungenauigkeiten und Fehler vorhanden (ungenaue Syntax, falsche URL usw.), so dass diese Dokumentation nicht als How To angewendet werden kann, ohne zu verstehen, was der Hintergrund der jeweiligen Aktivität ist.

<DM>

Written by fmtechteam

15/07/2013 at 15:39

Veröffentlicht in Detlef Müller, Portlet, SOA, WebCenter