Hier erfahren Sie, wie eine Verbindung für den Connector für OData konfiguriert werden kann, um damit Daten aus einem OData-Service zur Verfügung zu stellen. Informationen zur Konfiguration einer SAP Gateway-Verbindung finden Sie hier.
Allgemeine Angaben
Im Modul "Integration" kann eine neue Verbindung über das Hauptmenü "OData / Neue Datenquelle" angelegt werden. Dazu muss der Connector für OData unter "Daten konsumieren" im linken Bereich markiert sein.
Die Konfiguration von SAP Gateway-Verbindungen verwendet den selben Dialog für die allgemeinen Angaben. Alle Informationen zur Konfiguration von SAP Gateway-Verbindungen finden Sie hier.
In den allgemeinen Angaben für eine OData-Verbindung können Sie für unser Beispiel folgende Einträge angeben:
-
Name: Termine
-
Authentifizierung: HTTP Basic
-
User/Passwort: Benutzername und Passwort eines Benutzers aus dem Portal, in dem der Dienst bereitgestellt wird. Dieser Benutzer benötigt Rechte an der Beispielapplikation "Kalender1", aus der die Daten im Beispiel-Service stammen.
Neben dem Namen und einer Beschreibung der Verbindung können in den allgemeinen Angaben grundsätzlich die folgenden Authentifizierungsmethoden konfiguriert werden:
Authentifizierung
Keine
Für den anonymen Zugriff.
HTTP Basic
Mit dieser Methode (HTTP Basic) werden die Login-Informationen abgefragt. Der hier einzutragende Benutzer wird lediglich für den Zugriff auf die Service-Metadaten im Portal Manager benötigt.
Wenn Sie die Authentifizierungsmethode "HTTP Basis" wählen, sollten Sie unbedingt beim späteren Erstellen des Dienstes das Kontrollkästchen "SSL verwenden" aktivieren. Gegebenenfalls muss das Zertifikat des OData-Servers im konsumierenden Portal in den Zertifikatsspeicher importiert werden.
Intrexx (Legacy)
Diese Methode bietet sich für Dienste an, die über den Intrexx-OData-Provider bereitgestellt werden. Dabei werden Anmeldeinformationen verschlüsselt übertragen. Für den Zugriff auf die Metadaten tragen Sie auch hier einen Intrexx-Benutzer mit Passwort ein.
Kerberos / Kerberos (HTTP Basic)
Mit diesen Methoden steht in Windows-Umgebungen die Windows-Integrierte-Authentifizierung für ein Single-Sign-On zur Verfügung. Mit Kerberos (HTTP Basic) können sich auch Clients authentifizieren, die das Kerberos-Protokoll nicht unterstützen. Bitte beachten Sie folgende Grundvoraussetzungen für eine erfolgreiche Authentifizierung mit Kerberos:
-
Das Intrexx-Portal muss mit integrierter Windows-Authentifizierung betrieben werden.
-
Die Benutzer aus Ihrem Active-Directory müssen entsprechend in das Portal importiert sein. Bitte stellen Sie sicher, dass mindestens ein Benutzer in der Administratoren-Benutzergruppe enthalten ist, damit das System weiterhin administriert werden kann.
-
Der Server, auf dem Intrexx installiert ist, benötigt die Gruppenrichtlinie "Delegierung".
-
Alle Clients und Server müssen Mitglieder der gleichen Domäne sein. Im Internet Explorer muss in den Sicherheitseinstellungen der verwendeten Zone bei Benutzerauthentifizierung "Automatische Anmeldung mit aktuellem Benutzernamen und Kennwort" eingestellt sein. Außerdem muss in den erweiterten Einstellungen die Einstellung "Integrierte Windows-Authentifizierung aktivieren" gesetzt sein.
Bei der Kerberos-Authentifizierung haben Sie ein echtes Single-Sign-On für den Zugriff Ihrer Benutzer auf den OData-Service und verwenden die integrierte Windows-Authentifizierung. Kann ein Benutzer nicht authentifiziert werden, wird bei der zweiten Option automatisch die Standard-Anmeldung aktiviert. Für die erfolgreiche Authentifizierung ist die Angabe eines sogenannten Service-Principal-Name (SPN) notwendig. Der SPN enthält die Informationen über den Dienst, für den ein Kerberos-Ticket erzeugt werden soll. Dieses Ticket wird für den Internet Information Server des Intrexx-Portalservers benötigt. Der SPN ist in der Regel wie folgt aufgebaut: http/<Rechner-DNS-Name>@<KERBEROS_REALM>. Dabei entspricht der Rechner-DNS-Name dem voll qualifizierten Host-Namen (z.B. meinrechner.meinefirma.de). Als KERBEROS_REALM wird in der Regel die Domäne in Großbuchstaben (z.B. MEINEFIRMA.DE) angegeben. Der SPN mit den Beipieldaten würde demnach wie folgt lauten: http/meinrechner.meinefirma.de@MEINEFIRMA.DE.
Kerberos (Intrexx Token Service)
Alle Informationen dazu finden Sie hier.
X.509
Mit dieser Methode kann ein Zertifikatsspeicher im PKCS12-Format hochgeladen werden. Jeder Anwender kann später im Browser seinen eigenen Zertifikatsspeicher
über ein Login-Formular hochladen. Für die Authentifizierung mit X.509-Zertifikation wird vorausgesetzt, dass das Root-Zertifikat der Authentifizierungsstelle,
die für die Ausstellung der Client-Zertifikate zuständig ist, zuvor in Intrexx importiert
wurde. Klicken Sie dazu auf 
"X.509 Zertifikatsspeicher hochladen".
Zertifikatsspeicher
Geben Sie den Dateinamen des Zertifikats und das Passwort ein. Ein Klick auf
"Suchen"
öffnet einen Dialog, in dem die Zertifikatsdatei (im Format PKCS12) ausgewählt werden kann.
Klicken Sie "Fertig stellen", um den Dialog wieder zu schließen.
Führen Sie nach dem Import einen Neustart des Portaldienstes durch.
OAuth2/OpenID
Diese Authentifizierungsmethode unterstützt Dienste, die eine OAuth2-Autorisierung des Benutzers benötigen. Sollte der Dienst ein Auto-Approval des Users unterstützen, kann hier die Anmeldung eines Benutzers für die Metadaten hinterlegt werden. Ist dies nicht möglich, so muss das Metadaten-Dokument zunächst manuell als lokale Datei gespeichert und im Portalverzeichnis internal/cfg/odata mit dem Dateinamen <SERVICE_GUID>.edmx hinterlegt werden. Die eigentliche Konfiguration der OAuth2-Autorisierung muss derzeit noch direkt in der XML-Konfigurationsdatei des OData-Konsumenten im Portalverzeichnis internal/cfg/odata mit dem Dateinamen <SERVICE_GUID>.xml vorgenommen werden. Relevant sind dabei die Propertys:
<property name="authenticationType" value="OAUTH2"/> // value has to be OAUTH2
<property name="oauth2.scope" value="<OAuth scopes>"/>
<property name="oauth2.authenticationScheme" value="<Schema>"/>
<property name="oauth2.clientId" value="<Client ID>"/>
<property name="oauth2.grantType" value="<Grant Type>"/>
<property name="oauth2.clientAuthenticationScheme" value="<Client Schema>"/>
<property name="oauth2.userAuthorizationUri value="<end point for the authentication>"/>
<property name="oauth2.clientSecret"value="<Client Secret>"/>
<property name="oauth2.redirectUri" value="<Redirect URL>"/>
<property name="oauth2.accessTokenUri" value="<end point for the request of a token>"/>
Im Folgenden werden Auszüge einiger Beispielkonfigurationen für oft genutzte OAuth2-Dienste aufgeführt. Einige dieser Dienste können nicht als OData-Service verwendet werden. Trotzdem kann die OAuth2-Authentifizierung für direkte HTTP-Zugriffe auf den Dienst in Groovy-Skripts genutzt werden.
Spring Security OAuth2 Identity Provider
<?xml version="1.0" encoding="UTF-8"?>
<odata xmlns="urn:schemas-unitedplanet-de:lucy:server:odata:consumer:cfg" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:schemas-unitedplanet-de:lucy:server:odata:consumer:cfg consumer.xsd">
<consumer description="" guid="30378A6DEDA601F69D525C7FCAFA7E12CEC114C8" name="SpringOAuth2">
<property name="authenticationType" value="OAUTH2"/>
<property name="additionalAuthenticationTypes" value=""/>
<property name="userName" value="user"/>
<property name="password" value="E54F94C0106981A41312FC14955B164C"/>
<property name="servicePrincipalName" value=""/>
<property name="isSapService" value="false"/>
<property name="sapUseDefaultClientId" value="false"/>
<property name="sapClientId" value=""/>
<property name="sapNetweaverGatewayHost" value=""/>
<property name="sapNetweaverGatewayPort" value=""/>
<property name="sapNetweaverGatewayUseSSL" value="false"/>
<property name="sapSolutionManagerRegistered" value="false"/>
<property name="authTypeSource" value=""/>
<property name="authLoginSource" value=""/>
<property name="authPasswordSource" value=""/>
<property name="authSapClientIdSource" value=""/>
<property name="oauth2.grantType" value="authorization_code"/>
<property name="oauth2.clientAuthenticationScheme" value="form"/>
<property name="oauth2.accessTokenUri" value="https://localhost:9999/uaa/oauth/token"/>
<property name="oauth2.userAuthorizationUri" value="https://localhost:9999/uaa/oauth/authorize"/>
<property name="oauth2.scope" value="openid"/>
<property name="oauth2.clientId" value="acme"/>
<property name="oauth2.clientSecret" value="acmesecret"/>
<property name="oauth2.redirectUri" value="https://localhost/devportal/oauth2"/>
<services>
<service guid="E2050082619BBD33EEDEA97BDCC9223B25244191" name="SpringOauth2" odataSpecVersion="V2" sapCsrfTokenRequired="false" serviceRootURI="https://localhost:8888/res/" useSSL="false"/>
</services>
<userMappings/>
</consumer>
</odata>
Kursiv gesetzte Werte müssen angepasst werden.
Microsoft Outlook Online (nur http, kein OData)
<property name="authenticationType" value="OAUTH2"/> // value has to be OAUTH2
<property name="oauth2.scope" value="https://outlook.office.com/mail.read"/>
<property name="oauth2.authenticationScheme" value="form"/>
<property name="oauth2.clientId" value="<Client ID>"/>
<property name="oauth2.grantType" value="authorization_code"/>
<property name="oauth2.clientAuthenticationScheme" value="form"/>
<property name="oauth2.userAuthorizationUri value="https://login.microsoftonline.com/common/oauth2/v2.0/authorize"/>
<property name="oauth2.clientSecret"value="<Client Secret>"/>
<property name="oauth2.redirectUri" value="https://localhost/devportal/oauth2"/>
<property name="oauth2.accessTokenUri" value= "https://login.microsoftonline.com/common/oauth2/v2.0/token"/>
<services>
<service guid="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" name="Outlook" odataSpecVersion="V2" sapCsrfTokenRequired="false" serviceRootURI="https://outlook.office.com/api/v2.0/me/messages" useSSL="true"/>
</services>
GoogleMail (nur http, kein OData)
<property name="authenticationType" value="OAUTH2"/> // value has to be OAUTH2
<property name="oauth2.scope" value="https://mail.google.com/"/>
<property name="oauth2.authenticationScheme" value="header"/>
<property name="oauth2.clientId" value="<Client ID>"/>
<property name="oauth2.grantType" value="authorization_code"/>
<property name="oauth2.clientAuthenticationScheme" value="header"/>
<property name="oauth2.userAuthorizationUri value="https://accounts.google.com/o/oauth2/auth"/>
<property name="oauth2.clientSecret"value="<Client Secret>"/>
<property name="oauth2.redirectUri" value="https://localhost/devportal/oauth2"/>
<property name="oauth2.accessTokenUri" value= "https://accounts.google.com/o/oauth2/token"/>
<services>
<service guid="XXXXXXXXXXXXXXXXXXXXXXXXXXXXX" name="GMail Inbox" odataSpecVersion="V2" sapCsrfTokenRequired="false" serviceRootURI="https://www.googleapis.com/gmail/v1/users/firstname.lastname@googlemail.com/messages/" useSSL="true"/>
</services>
Verbindungstimeout
Wenn hier die Einstellung "Aktiv" gesetzt wird, kann bei Bedarf das gewünschte Verbindungstimeout festgelegt werden.
Klicken Sie "Weiter".
OData Dienste
In diesem Dialog können Sie mit Klick auf 
"neuen Dienst erfassen" einen neuen
Service anlegen.
Dienst erfassen
Der selbe Dialog wird in der Konfiguration für SAP Gateway-Verbindungen verwendet. Alle Informationen dazu finden Sie hier.
Wenn Sie unser Beispiel für die OData-Verbindung verwenden wollen, geben Sie in diesem Dialog den Namen "Termine" und die Service-URL an. Die Endpunkt-URL finden Sie in selbst erstellten OData-Services in den allgemeinen Angaben. Sie kann übernommen und hier als Dienst-URL eingetragen werden.
SSL verwenden
Aktivieren Sie diese Einstellung, wenn der Dienst eine SSL-verschlüsselte Verbindung benötigt.
Etag verwenden
Aktivieren Sie diese Einstellung, wenn für die Manipulation von Daten sogenannte Etag-Header gesetzt werden müssen.
OData V4
Mit dieser Einstellung können OData V4-Dienste konsumiert werden. Dabei wird von Intrexx ein Subset der OData V4-Features unterstützt, das dem Funktionsumfang für OData V2 entspricht.
Klicken Sie auf "Fertigstellen".
Mit Klick auf 
"Dienst bearbeiten" können die Dienst-Einstellungen bearbeitet werden. 
"Dienst entfernen"
löscht den aktuell markierten Dienst. Dienste können nur gelöscht werden, wenn sie
nicht bereits in einer Applikation oder einem
Prozess verwendet werden.
Klicken Sie "Weiter".
Anmeldeinformationen
Benutzername / Passwort / SAP-Client ID
Aus Benutzerverwaltung
Mit dieser Option werden Anmeldename, Passwort und SAP-Client-ID aus der Benutzerverwaltung bezogen.
Aus Web-Eingabe
Hier werden die Logindaten beim Aufruf der Applikation, in der die Verbindung verwendet wird, abgefragt.
Klicken Sie "Weiter".
Zusätzliche Benutzer
Hier können zusätzliche Benutzer für den Dienst-Zugriff definiert werden, z.B. für Prozesse, bei denen Zugriffe auf den Dienst bzw. das System immer unter einem bestimmten Benutzer erfolgen sollen, unabhängig von dem aktuell in Intrexx angemeldeten Benutzer.
Spalte "Intrexx-Benutzer"
Zeigt den Namen des Benutzers mit dem Pfad aus der Benutzerstruktur an.
Spalte "Service-Login"
Zeigt das zugeordnete Service-Login an.
Zusätzlichen Benutzer hinzufügen / Zusätzlichen Benutzer bearbeiten
Öffnet einen Dialog, in dem ein zusätzlicher Benutzer ausgewählt bzw. bearbeitet werden kann.
Benutzerauswahl
Intrexx-Benutzer
Zeigt Pfad und Name eines ausgewählten Benutzers an.
Benutzer auswählen
Öffnet einen Dialog, in dem ein Benutzer aus dem Modul "Benutzer" ausgewählt werden kann.
Abhängig von der Authentifizierung kann im Folgenden eine Zertifikatsdatei, Service-Login und Passwort hinterlegt werden.
Dateiname
Zeigt Pfad und Name der Zertifikatsdatei an.
Datei auswählen
Öffnet einen Dialog, in dem die Zertifikats-Datei ausgewählt werden kann.
Service-Login
Tragen Sie hier das Service-Login ein.
Passwort
Tragen Sie hier das Passwort ein.
Klicken Sie "Fertig stellen", um Änderungen zu speichern und den Dialog wieder zu schließen.
Zusätzlichen Benutzer löschen
Trägt den aktuell markierten Benutzer aus der Liste aus.
Klicken Sie "Weiter".
Verbindungstest
Klicken Sie auf "Test", um die Verbindung zu testen. Entsprechende Meldungen finden Sie im Ausgabefeld. Die Konfiguration wird mit einem Klick auf "Fertig stellen" abgeschlossen.
Verbindung bearbeiten
Die Verbindung wird nun im rechten Bereich angezeigt. Über das Hauptmenü "OData" oder das Kontextmenü der Verbindung erreichen Sie alle Funktionen für die Bearbeitung, wenn die Verbindung ausgewählt ist.
Spalte "Datengruppen"
Hier wird die Anzahl der Datengruppen, die mit Fremddatengruppen in Applikationen eingebunden sind, angezeigt.
Kerberos (Intrexx Token Service)
Der Intrexx-Kerberos-Token-Provider ist ein Webservice, der ein Intrexx-Portal-Server-Kerberos-Token zur Single-Sign-On-Authentifizierung der Portalbenutzer mit externen Systemen anfordern kann. Dieser Dienst wird vor allem dann benötigt, wenn während der Verarbeitung einer Benutzeranfrage im Portal-Server mehrere Zugriffe auf ein externes System benötigt werden, wobei jeder einzelne Zugriff ein Kerberos-Ticket zur Authentifizierung benötigt. Dem Portal-Server selbst steht pro Web-Request nur ein Ticket pro externem System zur Verfügung. Mit diesem kann sich der Portal-Server am Intrexx-Kerberos-Token-Provider im Kontext des Portalbenutzers anmelden und erhält dann für das externe System mehrere Tokens für die Verarbeitung der jeweiligen Requests.
Systemvoraussetzungen
Die Integrierte Windows-Authentifizierung muss für das Intrexx-Portal und den Connector aktiviert sein. Außerdem wird Microsoft Windows Server ab Version 2008 unterstützt. Auf dem Intrexx-Portal-Server müssen der Internet Information Server und .Net 4.5 installiert sein.
Installation und Konfiguration
Die Webanwendung für den Kerberos Token Service befindet sich als ZIP-Datei "ixkrbtokenservice.zip" im Installationsverzeichnis "adapter/odata/kerberos". Entpacken Sie die Dateien in einem beliebigen Verzeichnis auf dem Server, z.B. in c:/inetpub/wwwroot/ixkrbtokenservice. Erstellen Sie nun eine neue Web-Anwendung im IIS mit folgenden Einstellungen:
Wählen Sie dabei als Anwendungspool einen Pool aus, der die .NET Framework Version 4.0 unterstützt.
Anschließend muss die Ansicht "Authentifizierung" für die Anwendung geöffnet werden. Deaktivieren Sie dort alle Methoden bis auf "Windows-Authentifizierung". Als Provider muss "Negotiate" eingestellt werden und die Kernel-Mode Authentication muss ebenfalls aktiviert sein. Nun kann der Service im Browser getestet werden. Rufen Sie dazu im Browser die URL https://localhost/ixkrbservice/api/Token auf. Zusätzlich kann über den Query-Parameter "spn" direkt der Service-Prinicpal-Name des Servers angegeben werden, um die Ticket-Anforderung für diesen zu testen. Es sollte im Browser eine Meldung wie unten erscheinen:
Je nach Browser kann die Darstellung des Ergebnisses als XML- oder JSON-Dokument erfolgen. Die Anzahl der zu erzeugenden Tickets kann in der web.config-Datei im Service-Verzeichnis über den Parameter "maxTokenCount" eingestellt werden. Standardmäßig werden pro Anfrage 5 Tickets erstellt.
Nächste Schritte
Um die Daten aus der Verbindung zu nutzen, binden Sie die Verbindung in nächsten Schritt in einer beliebigen Applikation ein. Alle Informationen dazu finden Sie hier.
Senden Sie uns eine E-Mail