Authentifizierung

Zukünftiges Mittel der Wahl scheint die Verwendung von Access Token zu sein.

HMAC Signature

• Für sich genommen komplex; aber die Komplexität lässt sich kapseln.
• Wird für Anforderung von Access Token sowieso gebraucht (vgl. Client Credentials Grant und Explicit Authorization Code).
• Es müssen keine sich während der Laufzeit ändernden Daten verwaltet werden.
• Kann durch Angabe der principalID auch für individualisierte Abfragen verwendet werden.

Access Token

• Verwendung - wenn vorhanden - simpel.
• Token müssen angefordert, über ihre Lebenszeit verwaltet sowie regelmäßig aktualisiert werden.

Access Token

Client Credentials Grant

HMAC-signierter einfacher Request zur Anforderung eines Access Token ohne implizierte Verknüpfung zu einer Nutzerkennung. Daher rein Applikationsseitig ohne Nutzerinteraktion durchführbar. Das hier erhaltene Token kann auch zusammen mit einer anderweitig ermittelten Benutzerkennung (principalID) verwendet werden und so für individualisierte Zugriffe Verwendung finden.
Das erhaltene Token ist offenbar 20 Minuten gültig; danach muss ein neues Token angefordert werden.
Theoretisch ist ein so erhaltenes Token für alle Zugriffe von IntrOX auf WMS-APIs - egal ob für anonyme oder authentifizierte Nutzer - ausreichend (sofern die Benutzerkennung für individualisierte Zugriffe auf einem anderen Weg ermittelt werden kann).

Explicit Authorization Code

Nutzer wird von IntrOX zu WMS Authentifizierungsserver geschickt, authentifiziert sich dort und kommt mit einem Validierungstoken zurück. Danach ruft IntrOX im Hintergrund noch einmal den WMS Authentifizierungsserver auf und tauscht das Validierungstoken gegen ein - schon mit der PrincipalID verknüpftes - Access Token ein.
Auch dieses Access Token ist nur eine gewisse Zeit (vermutl. 20 Minuten) gültig.

Beim Abruf des Access Tokens wird vom WMS Authentifizierungsserver auch die principalID (samt principalIDNS) zurückgeliefert, so dass diese Information für HMAC Signature-basierte zur Verfügung stünde.

Allerdings kann beim Login über den WMS Authentifizierungsserver auch ein zusätzliches Refresh Token angefordert werden; dieses ermöglicht es der Client-Applikation (IntrOX), im Rahmen seiner Gültigkeit (offenbar 1 Tag) ohne Interaktion des Benutzers neue Access Token anzufordern. Ohne Refresh Token müssen sich die Benutzer alle 20 Minuten (Ablauf des Access Tokens) neu authentifizieren.

Verwendung

Per zeitgesteuertem regelmäßigen Aufruf des Client Credentials Grant Workflows könnte ein einzelnes gültig Access Token permanent lokal vorgehalten und in allen WMS-Aufrufen verwendet werden, die keine Verknüpfung mit einer bestimmten Benutzerin erfordern.

Unklar ist, ob es andere Wege als die Authentifizierung über WMS gibt, um für eine Benutzerin, die sich bei IntrOX anmelden will, die WMS-interne Benutzerkennung (die sog. principalID) zu ermitteln: wird die principalID z. B. im geplanten Shibboleth IdP verwaltet und kann dort abgefragt werden? Andernfalls muss der Explicit Authorization Code Workflow zur Ermittlung dieser ID verwendet werden, da ohne sie Kontoanzeigen, Vormerkungen etc. nicht durchführbar sind.

Bei Verwendung des Explicit Authorization Code Workflows muss intern bei individualisierten Zugriffen jeweils die Gültigkeit des Nutzer-bezogenen Tokens geprüft und ggf. vor Durchführung der angeforderten Aktion ein neues Access Token geholt werden. Die interne Verwaltung der Token erhöht die Komplexität der WMS-Integration gegenüber den vorhandenen Integrationen von Aleph und Sunrise.

Sofern wir die WorldCat Discovery API nicht benötigen, könnten wir nach gegenwärtigem Verständnis zunächst auch nur die HMAC Signature Methode zur Autorisierung der IntrOX-Anfragen an WMS-APIs verwenden. Dies ersparte den Implementierungsaufwand für die Access Token Verwaltung. Die Nutzerauthentifizierung erfolgte auch in diesem Fall über den Explicit Authorization Code Workflow, der die principalID für anschließende individualisierte Abfragen zulieferte.

Aufwand

• Alle Login-Masken innerhalb der DigiBib müssen standort-spezifisch angepasst werden (keine Eingabefelder für Kennung / Passwort anzeigen, sondern Aufruf des WMS OAuth-Servers).
• Bei Aufruf der Redirect URL:
  • Eine Fehlermeldung anzeigen, wenn kein Validierungstoken vorliegt oder eine Fehlermeldung übergeben wurde.
  • Access Token mittels Validierungstoken abholen.
    • Bei Misserfolg Fehlermeldung anzeigen.
    • Bei Erfolg Login- bzw. Relogin-Mechanismus der IPS aufrufen.
• Insbesondere bei nachträglicher Anmeldung aus einer laufenden Sitzung heraus muss vor Aufruf des WMS OAuth Servers die aktuell angezeigte Seite in der IntrOX-Oberfläche - per Cookie oder Server-seitig in der Sitzung - gespeichert werden, damit die Nutzerin nach der Anmeldung wieder dorthin zurückgeleitet werden kann.
• Gleiches gilt im Fall von Direkt-Aufrufen (/jumpto?...), deren Workflow angepasst werden muss.
• Evtl. von Nutzern mit Anmeldedaten eingerichtete Browser-Suchmaschinenplugins sind nicht länger gültig und müssen abgefangen werden; eine Neu-Einrichtung mit Einbettung von Anmeldedaten muss für den Standort unterbunden werden.
• Bislang wird an diversen Stellen in der Oberfläche die Benutzerkennung angezeigt (z. B. im Logout-Button als "<Kennung> abmelden"); da die principalID für die Benutzer bedeutungslos und unbekannt ist, müssen diese Stellen standort-spezifisch angepasst werden.

Notizen

• Neue Nutzerkennungen bzw. Verwendung von principalID und Fernleihe: Funktioniert das? Alte Bestellungen werden nach Umstieg nicht angezeigt werden können, weil das ZFL-Benutzerkonto die alte Benutzer-ID benötigte.
• Gespeicherte Merklisten gehen verloren, weil diese unter der alten Sunrise-Kennung abgelegt sind.
• Unklar ist noch, wie sich der WMS OAuth Server bei Anmeldeversuchen gesperrter Nutzer verhält.

https://authn.sd00.worldcat.org/oauth2/authorizeCode?client_id=38bwyQGicLvFU8BA4ctrdO9lvjrlpiUpP73bHMofpnMPafSXROqOtoX1NckQzK9oFYljUMcOloWtLEKD&authenticatingInstitutionId=18464&redirect_uri=https://test.digibib.net/oauth/836&contextInstitutionId=18464&response_type=code&scope=WMS_NCIP

Anhänge