Security Token Service Connector

Verwendung

Bei vielen Web Services ist es für den Service-Provider wichtig, die Nutzer der Dienstleistungen zu kennen, z.B. um die Nutzung abrechnen zu können oder um den unerlaubten Zugriff zu verhindern. Dazu können Service-Provider in der Interface-Beschreibung ihres Web Services, in der WSDL-Datei, festlegen, dass sich Service-Consumer gegenüber dem Service-Provider authentifizieren müssen.

Wenn eine größere Zahl von Web Services verwaltet werden soll, ist es sinnvoll, die Authentifizierung auszulagern und eine zentrale Authentifizierungsinstanz, einen so genannten Security Token Service, zu nutzen.

Ein STS Connector fungiert als zentrale Authentifizierungsinstanz für Web Services Consumer und sichert die Kommunikation zwischen Service-Consumer und -Provider zentral auf Nachrichten- und Transportebene.

Der Security Token Service Connector kann nur im Single-Modus verwendet werden.

Konnektortypen

Ein STS Connector wird immer als Input Listener eingesetzt. Er validiert eingehende Authentifizierungs-Requests und sendet bei positivem Validierungsergebnissen Tokens an den aufrufenden Web Service zurück.

Standards

Der STS Connector setzt folgende Web Service-Standards um:

Funktionsprinzip

module guide 1191 0

Die Absicherung der Kommunikation zwischen Service-Consumer und Provider über einen STS funktioniert folgendermaßen:

  1. Service-Provider bietet Web Service an und nutzt STS
    Der Service-Provider bietet eine Dienstleistung über einen Web Service an. Der Web Service ist über einen STS gesichert. Ein Web Service-Aufruf ist nur zulässig, wenn der Aufruf ein gültiges Token des STS enthält.

    Wenn der Provider eine Anfrage von einem Consumer erhält, dann wird zuerst die Gültigkeit des Tokens geprüft. Je nach Typ des Tokens prüft der Provider die Gültigkeit über Zertifikate.

  2. Service-Consumer möchte Service nutzen
    Um den Service aufrufen zu können, benötigt der Consumer dessen Interface-Beschreibung, die so genannte WSDL- Datei. Diese WSDL-Datei kann er direkt von dem Service-Provider oder von einem Verzeichnisdienst anfordern. In der WSDL-Datei sind die Sicherheitsanforderungen beschrieben, die der Consumer erfüllen muss, um den Dienst nutzen zu können. Unter anderem ist angegeben, gegenüber welchem STS sich der Consumer authentifizieren muss.

    Da der Consumer nun die Adresse des STS kennt, kann er diesen aufrufen und sich dort authentifizieren.

  3. STS-Provider prüft Anfrage des Service-Consumers
    Der STS-Provider prüft die Anfrage des Consumers an Hand der mitgelieferten Merkmale. Diese können Nutzername/ Passwort sein oder das Zertifikat, mit dem die Anfrage signiert ist. Wenn die Prüfung positiv verläuft, dann erzeugt der STS zwei Token:

    • Für das erste Token gilt:

      • Es enthält einen Session Key mit der Information, ob sich der Consumer erfolgreich authentifiziert hat.

      • Das Token ist mit dem öffentlichen Schlüssel des Service-Providers verschlüsselt. Damit ist sichergestellt, dass niemand, außer dem Service-Provider, den Session Key auslesen kann.

      • Das Token ist vom STS signiert, um zu versichern, dass der STS dieses Token ausgestellt hat.

    • Für das zweite Token, das Prüf-Token, gilt:

      • Das Prüf-Token enthält ebenfalls den Session Key. Dieser ist nötig, damit der Consumer seinen Web Service-Aufruf signieren kann.

      • Das Prüf-Token ist mit dem öffentlichen Schlüssel des Consumers verschlüsselt, damit auch der Consumer in den Besitz des Session Keys gelangen kann.
        Der STS sendet Token und Prüf-Token an den Consumer.

  4. Service-Consumer ruft Service-Provider auf
    Der Consumer empfängt die beiden Token und extrahiert den Session Key aus dem Prüf-Token. Er erstellt den Aufruf des Web Services und signiert den Aufruf mit dem Session Key. Dann sendet der Consumer den Aufruf und das eigentliche Token des STS an den Service-Provider.

  5. Service-Provider prüft die Signatur des Tokens
    Der Service-Provider prüft die Signatur des Tokens mit dem öffentlichen Schlüssel des STS, um zu verifizieren, dass das Token wirklich vom STS stammt. Anschließend entschlüsselt der Provider das Token mit seinem privaten Schlüssel und erhält damit den Session Key und die darin enthaltenen Aussagen über die Identität des Consumers.

    Anhand des Session Keys überprüft der Provider die Signatur des Web Service-Aufrufs. Da zu diesem Zeitpunkt nur der STS, der Consumer und der Service-Provider den Session Key kennen, kann der Service-Provider davon ausgehen, dass wirklich der Consumer, für den der STS das Token ausgestellt hat, die Service-Anfrage signiert hat. Nun muss der Service-Provider nur noch prüfen, ob der STS die benötigten Bescheinigungen in das Token integriert hat.

  6. Service-Provider sendet Service-Response oder Fehlermeldung
    Wenn die nötigen Bescheinigungen in das Token integriert sind, dann wird der Service-Request ausgeführt, die Service-Response verschlüsselt, signiert und an den Consumer gesendet.

    Wenn die Bescheinigungen fehlen, wird eine Fehlermeldung zurückgegeben.

Web Services Provider an STS Connector registrieren

Dieser Abschnitt erläutert, wie Sie beliebige Web Services Provider an einem STS Connector registrieren, um diese abzusichern.

Voraussetzungen

  • Die Web Services, die abgesichert werden sollen, sind bereits vorhanden, und die URL, über welche diese Web Services zu erreichen sind, sind bekannt.

  • Die Truststores mit den öffentlichen Schlüsseln aller Web Services, die von dem STS gesichert werden sollen, liegen vor.

So gehen Sie vor

  1. Erstellen Sie einen STS Connector oder öffnen Sie einen vorhandenen zum Bearbeiten.

  2. Klicken Sie im Dialog (siehe Dialog Security Token Service - WS-Trust) im Bereich Gesicherte Service-Provider auf Hinzufügen. Der folgende Dialog öffnet sich:

    module guide 1192 0

  3. Geben Sie im Feld URI des Provider-Endpoints die URL des Web Service Providers ein.

  4. Klicken Sie auf Truststore oder Zertifikat hinzufügen, um das Zertifikat des Web Services Providers mit dem öffentlichen Schlüssel hinzuzufügen.

  5. Schließen Sie den Dialog mit OK.

  6. Geben Sie in der WSDL den Alias für das Zertifikat des eben hinzugefügten Web Service Providers an. Ändern Sie das Element tc.CertAlias:

    Für jeden hinzugefügten Web Service Provider wird ein Element tc:ServiceProvider erstellt. Prüfen Sie den Wert des Attributs endpoint, damit Sie den Alias im richtigen Element ändern!

  7. Klicken Sie auf Fertig stellen, um die Konfiguration zu beenden.

  8. Wenn Ihr Web Service Provider in der INUBIT-Software erstellt wurde, müssen Sie noch dessen Kommunikation mit dem STS konfigurieren.

    Siehe:

Dialog Security Token Service - WS-Trust

In diesem Dialog konfigurieren Sie den Security Token Service, registrieren Service-Provider und konfigurieren deren Authentifizierung am STS.

Service-Name

Name, unter dem der STS seinen Dienst anbieten soll.
Standardmäßig wird der Name des Konnektors verwendet. Sie können diesen Wert ändern.

WSDL-Datei

WSDL-Datei mit der Schnittstellenbeschreibung des STS, den Pfaden zum Keystore des STS und zum Truststore der gesicherten Service Provider sowie den dazugehörigen Passwörtern und Aliasen.

Transport-Sicherheit

Zur Auswahl des Verschlüsselungsverfahrens:

  • XML-Encryption
    Die Daten innerhalb der zu übertragenden Nachrichten werden entsprechend dem Standard XML-Encryption verschlüsselt.
    Siehe https://www.w3.org/TR/xmlenc-core/

  • SSL
    Der Datentransport wird entsprechend dem SSL-Protokoll verschlüsselt.

STS-Authentifizierung

Zum Hinzufügen des Keystores:

  • Passwort
    Passwort des Keystores.

  • Keystore /Button Datei auswählen
    Zum Importieren des Keystores.
    Nach erfolgreichem Import wird die Gültigkeit des Schlüssels angezeigt.

Consumer-Authentifizierung

  • X.509
    Authentifizierung mit einem X.509-Zertifikat. Die Datei mit den Zertifikaten können Sie über den Truststore-Button importieren.

  • Benutzer/Passwort
    Authentifizierung über eine Benutzer/Passwort-Prüfung, die Anmeldungen gegen die folgenden Benutzerverwaltungen prüft.
    Wenn Sie beide Optionen markieren, dann werden beide Benutzerverwaltungen geprüft. Die Prüfung wird als erfolgreich gewertet, wenn die Prüfung in einer der beiden Benutzerverwaltungen erfolgreich ist.

  • Interne Benutzerverwaltung:
    Die Authentifizierung ist nur für Consumer möglich, die als Process-Engine‑Benutzer vorhanden sind.

  • Authentifizierung durch Workflow
    Die Authentifizierung der Consumer erfolgt durch einen Workflow gegen ein Backendsystem, wie z.B. ein LDAP-Verzeichnis.
    Den Workflow müssen Sie selbst entsprechend erstellen. Wenn ein Workflow definiert ist, dann erzeugt das letzte Modul des Workflows eine Ausgangsnachricht mit einer SAMLAssertion-Workflowvariable. Diese Variable enthält Authorisierungsdaten. Die Daten werden dem Service Provider übergeben und können für rechteabhängige Implementierungen genutzt werden.

Gesicherte Service-Provider

Zum Registrieren der Web Services:

  • URI des Provider-Endpoints
    URL des registrierten Web Service.

  • Öffentlicher Schlüssel ist gültig bis:
    Die Information über die Gültigkeit des öffentlichen Schlüssels ist im X.509-Zertifikat gespeichert, welches beim Registrieren eines Service-Providers hinzugefügt wird.

  • Schlüssel-Informationen
    Listet alle zusätzlichen Informationen, die neben der Gültigkeit im Zertifikat enthalten sind.

Press Esc to exit full screen
Modal image placeholder
Press Esc to exit full screen