Konzept Security
Diese Seite ist ein Teil der IsyFact-Standards.
Alle Inhalte der Seite, insbesondere Texte und Grafiken, sind urheberrechtlich geschützt.
Alle urheberrechtlichen Nutzungs- und Verwertungsrechte liegen beim Bundesverwaltungsamt.
Die Nutzung ist unter den Lizenzbedingungen der Creative Commons Namensnennung 4.0 International gestattet.
Java Bibliothek / IT-System
| Name | Art | Version |
|---|---|---|
|
Bibliothek |
v3.2.x |
1. Einleitung
Sicherheit ist ein zentrales Thema einer jeder Geschäftsanwendung. Bei der Umsetzung von Geschäftsanwendungen in IT-Systeme wird ein Großteil der Anforderungen an die Sicherheit durch Maßnahmen der IT-Sicherheit abgedeckt. Die IsyFact richtet sich beim Thema Sicherheit nach behördlichen Standards sowie De-Facto-Standards aus der Industrie:
Dieses Dokument konzentriert sich auf die konzeptionellen Aspekte der Authentifizierung und Autorisierung. Es sorgt dafür, dass Authentifizierung und Autorisierung in allen IT-Systemen gleichartig umgesetzt wird und grundlegende Anforderungen an die IT-Sicherheit eingehalten werden. Es richtet sich vor allem an Software-Architekten, die eine Geschäftsanwendung gemäß den Vorgaben der IsyFact absichern müssen und beschreibt, wie und in welchen Teilen eines IT-Systems die Authentifizierung und Autorisierung stattfindet.
Das Kapitel Prinzipien der Sicherheitsarchitektur erläutert zunächst, wie sich die Sicherheitsarchitektur auf Ebene der Systemlandschaft und auf Ebene eines einzelnen IT-Systems darstellt.
Danach beleuchtet das Kapitel Sicherheitsarchitektur eines IT-Systems die Einbettung des Bausteins Security in ein konkretes IT-System. Hierbei werden im Abschnitt Schnittstelle des Bausteins Security die zur Verfügung gestellten Schnittstellen aufgeführt und der Abschnitt Aufruf von Nachbarsystemen befasst sich mit Vorgaben und Konventionen beim Einbinden von Nachbarsystemen.
Im Kapitel OAuth2.0 und OpenIDConnect ist das Verfahren zur Authentifizierung und Autorisierung mit OAuth2 und Spring Security beschrieben. Die Begrifflichkeiten zum Verständnis von OAuth2.0 werden im Abschnitt OAuth2.0 zur Autorisierung erläutert und im Abschnitt Authentifizierung und Autorisierung wird die Authentifizierung und Autorisierung für Web-Oberflächen, Service-Gateways sowie Batches und Tasks beschrieben. Im Abschnitt Access-Token wird der Aufbau und die Verwendung von Access-Tokens erklärt.
Das Kapitel Rollen und Rechte beschreibt dann abschließend, wie Rollen und Rechte für eine neue Geschäftsanwendung spezifiziert werden.
2. Prinzipien der Sicherheitsarchitektur
Die IsyFact-Referenzarchitektur beinhaltet auf der technischen Ebene Vorgaben für die Sicherheitsarchitektur und für die Prinzipien, nach denen sie aufgebaut ist.
Eine davon ist die Forderung, dass IsyFact-konforme IT-Systeme gegen unberechtigte Nutzung zu schützen sind.
Konkret wird das im Baustein Security durch ein Rollen-, Rechte- und Berechtigungsmanagement realisiert:
-
Authentifizierungsinformationen, wie Benutzername und Passwort, werden nicht über IT-Systeme hinweg weitergegeben. Nur der Eigentümer der Authentifizierungsinformationen und der IAM-Service besitzen Kenntnis über diese Informationen.
-
Eine Zweifaktor-Authentifizierung ist durch das Behördenkennzeichen (BHKNZ) als zusätzliches Authentifizierungsmerkmal konzipiert, allerdings setzt dies im IAM-Service voraus, dass dieses Merkmal dort auch ausgewertet werden kann.
-
Die Authentifizierung und grobgranulare Autorisierung (mittels dem Nutzer zugeordneten Rollen) erfolgt an den Außenschnittstellen der Systemlandschaft (Portal, Authentication-Gateway bzw. Service-Gateway).
-
Liegt kein Aufruf über eine Außenschnittstelle vor (z.B. bei einem Batch- oder Task-Aufruf), so geschieht die Authentifizierung und grobgranulare Autorisierung innerhalb der Nutzungsschicht (Batch / Task) des aufrufenden IT-Systems über den IsyFact-Baustein Security.
-
Die feingranulare Autorisierung geschieht in der Nutzungsschicht und im Anwendungskern des aufgerufenen IT-Systems über den IsyFact-Baustein Security, indem die Nutzerrollen auf anwendungsspezifische Rechte abgebildet werden und diese Rechte bei jedem Serviceaufruf geprüft werden.
Existiert keine Systemlandschaft (d.h. IT-Systeme stehen für sich allein), gilt grundsätzlich, dass die Authentifizierung und grobgranulare Autorisierung in der Nutzungsschicht (GUI, Service oder Batch) des IT-Systems geschehen muss.
Darüber hinaus finden Authentifizierung und Autorisierung nach den Vorgaben des Berechtigungskonzepts statt.
Dieses Dokument beschreibt wesentliche Aspekte der Sicherheitsarchitektur für eine konkrete Anwendungslandschaft. Da das Berechtigungskonzept individuell für jede Anwendungslandschaft erstellt wird und sich im Einzelnen stark von Inhalt und Umfang her unterscheidet, ist es kein Bestandteil des Bausteins Security oder der IsyFact.
2.1. Authentifizierung
| Authentifikation: Verifikation der Identität eines natürlichen Nutzers (menschlicher Anwender) oder eines technischen Nutzers (technische Anwendung) als Zugangskontrolle zu einem geschützten System. Dabei ist es erforderlich eindeutige Eigenschaften (z.B. biometrische Daten) oder geheime Daten (z.B. Passwort) zur Überprüfung zu übergeben. |
In der Regel erfolgt die Authentifizierung von Benutzern über eine zentrale Komponente der Systemlandschaft, in welche das IT-System eingebettet ist. Die Authentifizierung darf auch lokal, d.h. vom IT-System selbst, durchgeführt werden, falls es beispielsweise nicht in eine Systemlandschaft eingebettet ist.
Für die zentrale Authentifizierung wird in der IsyFact ein OAuth 2.0 konformes IAM-System verwendet.
| IAM steht für Identity and Access Management. |
Das IAM-System verwaltet Benutzer (menschliche Anwender und technische Systeme) und ihre Rollen zentral für alle Komponenten der Anwendungs- und Systemlandschaft.
Die Authentifizierung und grobgranulare Autorisierung erfolgt, gemäß der Prinzipien der Sicherheitsarchitektur, an den Außenschnittstellen der Systemlandschaft.
Hierbei übermittelt der Benutzer seine Authentifizierungsmerkmale (z.B. Login-Name u. Passwort) und für eine Zwei-Faktor-Authentifizierung das Behördenkennzeichen (BHKNZ) an den IAM-Service, der sie gegen die bei ihm gespeicherten Merkmale verifiziert.
Falls der IAM-Service die Auswertung des BHKNZ nicht unterstützt, wird dieses Authentifizierungsmerkmal als optional gewertet.
Nach erfolgreicher Authentifizierung gibt der IAM-Service das Authentifizierungsergebnis zusammen mit den bei ihm hinterlegten Rollen des Anwenders an das aufrufende Anwendungssystem zurück.
Die Rollen allein sind jedoch noch nicht ausreichend, um den Benutzer in der Anwendung vollständig zu autorisieren.
2.2. Autorisierung
| Autorisierung: Zustimmung oder Erlaubnis, spezieller die Einräumung von Rechten gegenüber interessierten Rechtssubjekten, gegebenenfalls als Nutzungsrecht gegenüber Dritten. |
Die Autorisierung geschieht in jedem Fall im jeweiligen IT-System. Nach der erfolgreichen Authentifizierung eines Benutzers leitet das IAM-System die Anfrage an das IT-System weiter bzw. gibt dem Aufrufer das Ergebnis der Authentifizierung zurück - angereichert mit weiteren Informationen über den Benutzer (speziell: zugeordnete Rollen). Im aufgerufenen IT-System wird die Anfrage – je nach Schutzbedarf und Funktionalität – autorisiert. Dazu weist das IT-System einem Benutzer anhand seiner Rollen anwendungsspezifische Rechte zu und prüft diese gegen die für die Nutzung des angefragten Service benötigten Rechte. Wie genau Rollen und Rechte spezifiziert werden, beschreibt das Kapitel Rollen und Rechte.
3. Sicherheitsarchitektur eines IT-Systems
Der Baustein Security bildet eine Komponente des Querschnitts der IsyFact Referenzarchitektur IT-Systeme. Er ist von jedem IT-System zur Autorisierung von Zugriffen und Vorgängen zu verwenden.
Die Mechanismen zur Absicherung IsyFact-konformer IT-Systeme haben zum Ziel, die Autorisierung von Zugriffen systematisch, einheitlich und einfach umzusetzen.
Die Systematik und Vollständigkeit der Berechtigungsprüfungen wird dadurch erreicht, dass Berechtigungsprüfungen in den IT-Systemen an definierten Stellen und auf identische Weise stattfinden.
Die Einheitlichkeit wird durch Bereitstellung der Bibliothek isy-security und Nutzungsvorgaben gewährleistet, die von allen IT-Systemen zu verwenden sind.
Berechtigungsprüfungen erfolgen innerhalb eines IT-Systems immer über die Bibliothek isy-security.
Die Einfachheit der Nutzung der Bibliothek isy-security wird durch weitgehende Transparenz bei der Initialisierung, kompakte Schnittstellen und deklarative (z.B. per Annotation) statt programmatischer Implementierung erreicht.
3.1. Prämissen
Aus den Prinzipien der Sicherheitsarchitektur leiten sich die folgenden Randbedingungen für die Umsetzung der Berechtigungsprüfung innerhalb eines IT-Systems ab:
-
Anfragen, die am Dialog (Web-App) eines IT-Systems eingehen, sind immer vorher über die mitgegebenen Authentifizierungsdaten durch das IAM-System bzw. die lokale Authentifizierung erfolgreich authentifiziert. Durch die Authentifizierung des IAM-Systems enthält der HTTP-Header der Anfrage die Identifikation des Anwenders und dessen Rollen (in Form eines JWT Zugriffstoken).
-
Anfragen, die an einer Service-Schnittstelle (von außen über ein Service-Gateway (SGW) oder von anderen IT-Systemen innerhalb der IT-Systemlandschaft) eines IT-Systems eingehen, sind ebenso bereits authentifiziert.
-
Prozesse, die unabhängig von eingehenden Anfragen (über Dialog und Service) durch ein IT-System gestartet werden (z.B. Batch/Task), müssen zunächst einen (technischen) Nutzer gegen das IAM-System bzw. die lokale Authentifizierung erfolgreich authentifizieren, um ein JWT Access-Token zu erhalten. Mit diesem können sie dann Services anderer IT-Systeme innerhalb derselben Anwendungslandschaft verwenden.
-
Das aufgerufene IT-System prüft das Vorhandensein eines (gültigen) Access-Tokens und übernimmt dieses mit den darin enthaltenen Anwenderinformationen in den
SecurityContext, wobei es die Rollen des Anwenders auf systemspezifische Rechte abbildet. Vor Ausführung des Service prüft das IT-System, ob der Anwender die dafür benötigten Rechte besitzt. -
Innerhalb der Anwendungslandschaft eines IT-Systems wird das
JWT Access-Tokenweitergegeben. Zur Stärkung der Vertrauenswürdigkeit wird jedesJWT Access-Tokenbeim Eintritt in ein IT-System auf Gültigkeit und Authentizität geprüft.
Die Services eines IT-Systems können also nur mit einer gültigen Legitimation aufgerufen werden und sind so vor unberechtigter Nutzung geschützt. Umgekehrt können die Module und Verarbeitungsprozesse innerhalb des IT-Systems sich darauf verlassen, dass ihr Aufruf legitim ist und die ihnen übergebenen Daten vertrauenswürdig sind.
3.2. Software-Architektur
Die folgende Abbildung zeigt den logischen Aufbau für die Authentifizierung und für die Bereitstellung von Berechtigungsinformationen an die Komponenten eines IT-Systems.
Im Folgenden werden die Aufgaben und grobe Funktionsweise der Komponenten für die Autorisierung von Anfragen in einer Geschäftsanwendung erläutert.
Der Baustein isy-security basiert auf dem Framework Spring Security und bietet querschnittliche Funktionalität zur Authentifizierung und Autorisierung von Anfragen, die von internen oder externen Anwendungen an eine IsyFact-Anwendung gestellt werden (M2M-Kommunikation).
Die Authentifizierung und Autorisierung von Anfragen, die von menschlichen Nutzern über eine Benutzeroberfläche (Browser) gestellt werden, findet im Zuge der Einführung von Single-Page-Applications (SPAs) nicht mehr über das Backend oder den Baustein isy-security statt, sondern innerhalb des Portal-Webservers.
Ausserdem sichert der Baustein isy-security die Service-Schnittstellen der IsyFact-Anwendungen ab, indem er Funktionalität zur Berechtigungsprüfung anbietet. Hier wird geprüft, ob die gewährte Autorisierung auch das Recht zur Nutzung der angefragten Service-Schnittstelle beinhaltet.
Um IsyFact-spezifische Anforderungen, wie z.B. die Nutzung des Behördenkennzeichens, zu erfüllen, existiert eine Zugriffsschicht, die eben diese Funktionalität bereitstellt und den Zugriff auf Spring Security (und das IAM-System) kapselt. Die einheitliche Zugriffsschicht für Authentifizierung und Autorisierung erleichtert zudem, durch die teilweise Übernahme bestehender Schnittstellen, die Migration von einer älteren IsyFact Version.
Der Zugriff auf den Baustein erfolgt über das Interface Security, das Methoden zum Erhalt von Instanzen folgender Manager bereitstellt:
-
Authentifizierungsmanager -
Berechtigungsmanager
Zusätzlich bietet das Security-Interface eine Zugriffsmöglichkeit auf eine Liste von allen im System hinterlegten Rollen an.
Der Authentifizierungsmanager ist für die Kommunikation mit dem IAM-Service über den OAuth2AuthorizedClientProvider zuständig.
Die Authentifizierung (Anmeldung) von internen oder externen Anwendungen verläuft über Servicemethoden, die dieser Manager anbietet.
Das Ergebnis einer erfolgreichen Authentifizierung ist die Autorisierung durch ein Access-Token, das die dem Benutzer zugeordneten Rollen enthält.
Dieses Access-Token legt die aufrufende Anwendung (bzw. das SGW als Mittelsmann) anschließend im SecurityContext ab und präsentiert es der aufgerufenen Service-Schnittstelle der IsyFact-Anwendung.
Über den Berechtigungsmanager kann die Anwendung die Rollen und anwendungsspezifischen Rechte des angemeldeten Benutzers abfragen.
Der RolePrivilegeGrantedAuthoritiesConverter ist für die Konvertierung der vom IAM-Service im Access-Token übermittelten Rollen des Benutzers in die anwendungsspezifischen Rechte zuständig.
Die Absicherung der Service-Schnittstellen von IsyFact-Anwendungen erfolgt über folgende AOP-Annotationen:
-
Mit der von Spring Security bereitgestellten Annotation
@Securedwerden angebotene Services der Anwendung abgesichert. Dieser Annotation muss noch der Name eines anwendungsspezifischen Rechts mitgegeben werden, das für die Verwendung dieses Service benötigt wird. Im InterceptorSecuredInterceptorwird sichergestellt, dass nur dann der Zugriff gewährt wird, wenn der angemeldete Nutzer über seine Rollen auch dieses anwendungsspezifische Recht besitzt.
Hinweis: Die Annotation @Secured löst die Annotation @Gesichert ab und ist analog dazu verwenden.
Eine Absicherung von Services auf Ebene des Ressourcenbesitzers (Resource Owner), also eines technischen Nutzers bzw. OAuth-2-Client bietet die IsyFact-Annotation @Authenticate.
Dieser Annotation muss noch die oauth2ClientRegistrationId mitgegeben werden, unter der der Ressourcenbesitzer in der betrieblichen Konfiguration registriert ist.
Im Interceptor AuthenticateInterceptor erfolgt eine Authentifizierung über die Methode authentifiziere(oauth2ClientRegistrationId) im Authentifizierungsmanager.
Der Service wird dann im Namen und mit den Rechten des Ressourcenbesitzers ausgeführt.
Hinweis: Die Annotation @Authenticate löst die Annotation @Nutzerauthentifizierung ab und erweitert sie um die Funktion, auch hinterlegte OAuth-2-Clients authentifizieren zu können.
3.3. Schnittstelle des Bausteins Security
Im Folgenden wird die Schnittstelle des Bausteins isy-security beschrieben.
Das Interface Security ist der zentrale Einstiegspunkt in den Baustein isy-security.
Bei seiner Instanziierung wird die anwendungsspezifische Rollen-Rechte-Datei eingelesen und damit der Authentifizierungsmanager sowie der Berechtigungsmanager erzeugt.
Das Interface Security stellt der Geschäftsanwendung die im Weiteren beschriebenen Authentifizierungsmanager und Berechtigungsmanager zur Verfügung.
Außerdem kann die Geschäftsanwendung über die Methode getAlleRollen eine Liste von allen im System hinterlegten Rollen erhalten.
Der Authentifizierungsmanager übernimmt die programmatische Authentifizierung und Autorisierung interner und externer Anwendungen durch das IAM für den Zugang zu IsyFact-Nachbaranwendungen:
Interne Anwendungen sind als Confidential Client eingestuft und verwahren ihre Authentifizierungsdaten (entweder Client-ID u. Client-Secret oder Nutzername u. Passwort) in ihrer Konfiguration (mit einer oauth2ClientRegistrationId als Schlüssel).
Die Methode authentifiziere(oauth2ClientRegistrationId) im Authentifizierungsmanager liest diese Authentifizierungsdaten aus der betrieblichen Konfiguration und führt damit eine OAuth2.0-konforme Authentifizierung und Autorisierung der Anwendung gegenüber dem IAM-System durch.
Dabei wird anhand des Typs der Authentifizierungsdaten der passende Authentication-Flow mit den konfigurierten Authentifizierungsdaten verwendet.
Externe Anwendungen übermitteln ihre Authentifizierungsdaten (entweder Client-ID u. Client-Secret oder Nutzername u. Passwort) mit im Header der HTTP-Anfrage an das Service-Gateway bzw. Authentication-Gateway. Das Gateway führt damit eine OAuth2.0-konforme Authentifizierung und Autorisierung der Anwendung gegenüber dem IAM-System durch. Dabei wird anhand des Typs der Authentifizierungsdaten der passende Authentication-Flow verwendet:
-
Für den Credential-Typ bzw. Credential-Flow Client-Credential Flow ist die Methode
authentifiziereClientzu verwenden mit der issuerLocation als URI des IAM sowie clientId, clientSecret und optional das BHKNZ der externen Anwendung als Parameter. Hierbei ist zu beachten, dass aktuell keine Auswertung bzw. Weiterleitung des BHKNZ an das IAM stattfindet. -
Für den Credential-Typ bzw. Credential-Flow Resource-Owner-Password-Credential Flow die Methode
authentifiziereSystemmit den Parametern issuerLocation als URI des IAM, clientId und clientSecret des Gateways als vermittelnden confidential client sowie username, password und optional das BHKNZ der externen Anwendung.
Der Berechtigungsmanager gibt Auskunft über die Rollen und Rechte des Anwenders.
Die in der Benutzeradministration dem Anwender zugewiesenen Rollen werden mithilfe einer anwendungsspezifischen Rollen-Rechte-Datei in konkrete Rechte des Anwenders für diese Anwendung umgewandelt.
Die aktuellen Rollen und Rechte des Anwenders können mit den Methoden des Berechtigungsmanager erfragt werden und es kann geprüft werden, ob der Anwender ein bestimmtes Recht hat.
Die Methoden getRechte und getRollen liefern die aktuell dem Anwender zugeordneten Rechte bzw. Rollen.
Mit der Methode hatRecht kann die Anwendung feststellen, ob der Anwender aktuell ein bestimmtes Recht besitzt, während mit pruefeRecht der nachfolgende Code mit dem angegebenen Recht abgesichert wird: falls der Anwender das Recht nicht hat, wird eine AutorisierungFehlgeschlagenException geworfen.
Mit diesen Berechtigungsabfragen kann die Geschäftsanwendung z.B. feingranular bestimmen, ob und wie der Anwender bestimmte Daten sehen oder bearbeiten kann bzw. ob und wie er bestimmte Funktionen der Anwendung benutzen kann.
Ein beliebiges Attribut, das im Access-Token des Security Contexts abgelegt ist, kann mit der Methode getTokenAttribute gelesen werden. Mit dem Namen (String) des Attributes als Parameter liefert es den Wert des Attributes (Object).
3.4. Aufruf von Nachbarsystemen
Ein Anwendungssystem erwartet bei einem Aufruf, dass alle notwendigen Authentifizierungs- und Autorisierungsdaten in valider und gültiger Form übergeben werden.
Folglich muss ein Anwendungssystem, das ein Nachbarsystem aufruft, diesem Aufruf ebenfalls gültige und valide Authentifzierungs- und Autorisierungsdaten mitgeben.
Im Regelfall werden diese Daten der originären Anfrage als SecurityContext übergeben, der mit den Daten aus dem AccessToken zuvor initialisiert, wurde.
Dies geschieht durch die Validierung des Access-Token über den Sicherheitsbaustein isy-security des Anwendungssystems.
Für eine fachliche und prozessbezogene Aufrufkette wird dieses Access-Token in allen weiteren Aufrufen wiederverwendet und unverändert weitergeleitet.
Es erfolgt an der jeweiligen Schnittstelle des Nachbarsystems eine entsprechende Transformation der Daten des Access-Tokens in einen SecurityContext.
Gemäß Referenzarchitektur ist HTTP als das Übertragungsprotokoll der Servicekommunikation definiert.
Dazu sind an den Schnittstellen meist dedizierte Consumer-Provider-Bibliotheken vorgesehen, die bereits die Logik zur Transformation und Weiterleitung des Access-Tokens übernehmen.
Gibt es diese Bibliotheken nicht an den Schnittstellen, dann muss das Nachbarsystem direkt aufgerufen werden.
Hierbei muss das aufrufende Anwendungssystem stets das Access-Token manuell in den Header der ausgehenden Nachricht schreiben.
Weitere Details hierzu sind im Kapitel Authentifizierung & Autorisierung beschrieben.
4. OAuth2.0 und OpenIDConnect
OAuth 2.0 ist ein offenes Autorisierungsprotokoll, das eine standardisierte, sichere API-Autorisierung für Desktop-, Web- und Mobile-Anwendungen erlaubt. Ein (menschlicher) Endbenutzer kann mithilfe eines Autorisierungsservers (IAM-Service) einer Anwendung den Zugriff auf seine (geschützten) Daten erlauben (Autorisierung), die von einem anderen Service bereitgestellt werden, ohne geheime Details seiner Zugangsberechtigung (Authentifizierung) der Anwendung preiszugeben. Der Endbenutzer kann so der Anwendung gestatten, in seinem Namen einen Service zu benutzen. Dazu wird der Endbenutzer auf eine Login-Seite des Autorisierungsservers (IAM-Service) umgeleitet und nach erfolgreicher Authentifizierung zurück in die Anwendung. Dabei wird die Übermittlung von vertraulichen Daten wie z.B. Passwörtern an die Anwendung vermieden. Bei M2M-Kommunikation (Machine to Machine) enthält die Konfiguration der Anwendung die zur Authentifizierung notwendigen Daten des dafür verwendeten technischen Nutzers (Client), die direkt an den IAM-Service geschickt werden. Bei erfolgreicher Authentifizierung erhält die Anwendung ein Access-Token (Zugriffstoken), eine Art 'Freibrief' für die Anwendung, mit dem der IAM-Service das Zugangsrecht bestätigt.
OpenID Connect (OIDC) ist ein offenes Identitätsprotokoll, das die Autorisierungs- und Authentifizierungsmechanismen von OAuth 2.0 nutzt und als Schicht oberhalb des OAuth-Frameworks Anwendungen ermöglicht, zusätzlich zur oben beschriebenen Autorisierung auch grundlegende Profilinformationen des Benutzers auf interoperable Weise zu erhalten. Die Implementierung von OpenID Connect basiert auf der Ausstellung von ID-Tokens, auf einer REST-Schnittstelle und auf dem Datenformat JSON.
4.1. OAuth2.0 zur Autorisierung
OAuth 2.0 ist ein Autorisierungsprotokoll und kein Authentifizierungsprotokoll.
Als Solches ist es in erster Linie dafür vorgesehen, den Zugriff auf bestimmte Ressourcen zu ermöglichen, beispielsweise externe APIs oder Nutzerdaten.
OAuth 2.0 nutzt Access-Tokens.
Access-Tokens sind Daten, die die Autorisierung zum Zugriff auf Ressourcen für den Endnutzer darstellen.
OAuth 2.0 definiert kein spezielles Format für Zugriffstokens, in der Regel wird jedoch das „JSON Web Token (JWT)“-Format genutzt.
Dieses ermöglicht es dem Aussteller der Access-Tokens, weitere Daten in das Access-Token selbst aufzunehmen.
Aus Sicherheitsgründen sollten Access-Tokens außerdem ein Ablaufdatum besitzen.
In OAuth 2.0 gibt es folgende vier Rollen bzw. beteiligte Parteien:
Ressourcenbesitzer (Resource Owner)
Eine Person oder ein System, das berechtigt ist, auf eine geschützte Ressource zuzugreifen.
Beispiel: Anwender, technischer Nutzer.
Wir übernehmen für die IsyFact die konkrete Ausprägung "Anwender", "Technischer Nutzer", "Client".
Ressourcen-Server bzw. Anwendungssystem (Resource Server)
Der Server, in dem die geschützte Ressource liegt und der in der Lage ist, auf Anfragen an diese geschützte Ressource zu reagieren, wenn sie ein Access-Token enthalten.
Beispiel: Geschäftsanwendung
Wir übernehmen für die IsyFact die IsyFact-spezifische Bezeichnung "Anwendungssystem".
Anwendung (Client)
Eine vom Ressourcenbesitzer gesteuerte Anwendung, die in seinem Namen eine geschützte Ressource verwenden möchte.
Der Begriff 'Client' impliziert hier nicht bestimmte Implementierungscharakteristiken, sondern den Teil der Anwendung, mit der der Ressourcenbesitzer interagiert.
Beispiel: Batch.
Handelt es sich bei der Anwendung um eine Backend-Anwendung, so wird diese als "Confidential Client" bezeichnet.
Wir übernehmen für die IsyFact die englische Bezeichnung "Client".
IAM-Service (Authorization Server)
Der Service, der nach erfolgreicher Authentifizierung und Autorisierung des Ressourcenbesitzers, Access-Tokens ausstellt.
Bei erhöhtem Sicherheitsbedarf kann der Ressourcen-Server eine Prüfung der Gültigkeit des Access-Tokens durch den IAM-Service veranlassen.
So können auch z.B. zurückgezogene (Revoked) Tokens erkannt und abgelehnt werden.
Beispiel: Keycloak (Produkt).
Wir übernehmen für die IsyFact die IsyFact-spezifische Bezeichnung "IAM-Service".
Weitere wichtige Begriffe sind:
Ressource (Resource)
Daten oder andere Betriebsmittel, die durch ein Nutzungsrecht vor unbefugtem Zugang geschützt sind.
Wir übernehmen für die IsyFact die deutsche Bezeichnung "Ressource".
Access-Token
Berechtigungsnachweis für den Zugang zu einer geschützten Ressource.
Der Inhalt ist für den Client meist nicht lesbar, er gibt es einfach weiter an den Ressourcen-Server.
Er gilt für einen spezifischen Bereich und nur für eine bestimmte Zeit.
Refresh-Token
'Meta'-Berechtigungsnachweis: Ermöglicht dem Client, ein neues Access-Token vom IAM-Service zu erhalten, ohne dass der Ressourcenbesitzer sich erneut ausweisen muss.
Dieses neue Access-Token kann z.B. ein späteres Ablaufdatum (autom. Nutzungsverlängerung) oder andere Rechte (innerhalb aller an den Ressourcenbesitzer vergebenen Rechte) aufweisen.
Wir übernehmen für die IsyFact die englische Bezeichnung "Refresh-Token".
4.2. OpenIDConnect zur Authentifizierung
OpenID Connect ist eine Identitätsschicht über dem OAuth 2.0-Protokoll und ist eine Erweiterung und nicht Teil des OAuth2.0-Protokolls. Es ermöglicht Clients, die Identität des Endbenutzers basierend auf der von einem Autorisierungsserver durchgeführten Authentifizierung zu überprüfen und grundlegende Profilinformationen über den Endbenutzer auf interoperable und REST-ähnliche Weise zu erhalten.
OpenID Connect ermöglicht es Clients aller Art, einschließlich webbasierter, mobiler und JavaScript-Clients, Informationen über authentifizierte Sitzungen und Endbenutzer anzufordern und zu erhalten.
Der Baustein Security bietet keine direkte OpenID Connect Unterstützung.
Für den Transport von Benutzerinformationen, wie z.B. BHKNZ, wird das Access-Token verwendet.
OpenID Connect Abfragen zur Identität eines Benutzers, OpenID-Token oder Custom-Token müssen in der Anwendung implementiert werden.
4.3. Authentifizierung & Autorisierung
4.3.1. Aufruf Web-Oberfläche/Portal
Damit ein Anwender eine geschützte Anwendung über deren Web-Oberfläche (im Web-Browser) aufrufen kann, muss er über den IAM-Service authentifiziert und dazu autorisiert sein. Die IsyFact folgt der Empfehlung des OAuth 2.0 Frameworks und definiert den Authorization Code Flow als Authentifizierungsweg. Dieser Ablauf stellt sicher, dass zum einen nur der IAM-Service die Authentifizierungsdaten des Nutzers erfährt und zum anderen, dass die Web-Oberfläche (Web-Client) keinen Zugriff auf das Access-Token bekommt.
Als Voraussetzung für diesen Flow ist die Bereitstellung eines Vermittlers ('Relying Party') notwendig, der die Kommunikation zwischen Web-Oberfläche und Autorisierungsserver verwaltet.
Dieser Vermittler muss ein OAuth2.0 Confidential Client sein, also ein serverseitiges System.
Dies kann ein als Reverse Proxy konfigurierter Webserver sein (z.B. Apache http-Server mit mod_auth_openidc Modul), der zwischen Web-Client (Web-Browser) und Web-Anwendung geschaltet ist.
Das Webserver-Modul mod_auth_openidc koordiniert den Ablauf des Authorization Code Flow mit Confidential Client zwischen Nutzer und dem IAM-Service und verwaltet das Access-Token - der Baustein Security wird hierfür nicht verwendet.
Die folgende Abbildung zeigt die System-Architektur mit dem Webserver in der Informations- u. Dienstezone vor der Anwendung und dem IAM-Service in der Logik- u. Verarbeitungszone.
Ein menschlicher Nutzer, der eine Anwendung über deren Web-Oberfläche (im Web-Browser) bedienen möchte, ist im Besitz von Authentifizierungsdaten (Nutzername u. Passwort), mit denen er sich gegenüber dem IAM-System ausweisen kann.
Wenn für einen Anwender (noch) keine gültige Session vorhanden ist, leitet der Webserver auf die Login-Seite des IAM-Systems um.
Die hier eingegebenen Authentifizierungsdaten gelangen ausschließlich zum IAM-Service, wo sie geprüft werden.
Bei positiver Authentifizierung stellt der IAM-Service erstmal einen kurzlebigen Authorization Code aus.
Das ist eine schwer erratbare zufällige Zeichenkette und hat nur einen Zweck:
Tausch gegen das Access-Token (u. Refresh-Token) im nächsten Teil des Authorization Code Flow.
Das ist notwendig, um sicherzustellen, dass das Access-Token an den ursprünglichen Initiator des Aufrufs ausgeliefert wird und nicht z.B. eine Redirection URI Manipulation stattgefunden hat.
Mit dem Erhalt des Access-Tokens (u. Refresh-Token) ist die Autorisierung durch das IAM-System erfolgreich abgeschlossen.
Das mod_auth_openidc Modul speichert das Access-Token (u. Refresh-Token) in der User-Session und leitet es bei jeder Interaktion mit der Anwendung an die Web-Anwendung weiter - bis die Session beendet wird.
Das nachfolgende Sequenzdiagramm zeigt noch einmal schematisch den logischen und zeitlichen Ablauf sowie das Zusammenspiel der System-Komponenten im Authorization Code Flow mit Confidential Client:
4.3.2. Aufruf Service-Gateway
Anfragen von externen Anwendungssystemen an ein IsyFact-Anwendungssystem, müssen über den IAM-Service authentifiziert und zur Nutzung des aufgerufenen IsyFact-Service autorisiert werden. Um das zu gewährleisten, ist in der Informations- und Dienstezone ein Service-Gateway (SGW) zwischen der externen Anwendung und dem internen IsyFact-Service geschaltet. Das Service-Gateway nimmt diese fachliche Anfrage von außen entgegen, leitet diese zur Authentifizierung an den IAM-Service und bei Erfolg wird die fachliche Anfrage inklusive der Rollen und Rechte an den internen IsyFact-Service weitergeleitet, der dann die noch ausstehende Autorisierung auf Basis der Rollen und Rechte selbst initiiert, bevor er mit der eigentlichen fachlichen Bearbeitung beginnen kann.
4.3.2.1. Authentifizierung über das SGW am IAM-Service
Die nachfolgende Abbildung zeigt die aktuell verwendete System-Architektur, in der das Service-Gateway mithilfe des IAM-Service die hier notwendige Authentifizierung durchführt.
Zu sehen sind die folgenden Ablaufschritte:
-
Eine externe Anwendung sendet eine fachliche Anfrage zusammen mit ihren Authentifizierungsdaten an das Service-Gateway.
-
Im Service-Gateway werden die Authentifizierungsdaten aus der Anfrage herausgelöst und an den IAM-Service weitergeleitet. Im IAM-Service erfolgt dann die eigentliche Authentifizierung.
-
Mit validen Authentifizierungsdaten und erfolgreicher Authentifizierung liefert der IAM-Service ein valides, neu erstelltes Access-Token an das Service-Gateway zurück.
-
Mit Erhalt eines gültigen Access-Tokens leitet das Service-Gateway die fachliche Anfrage zusammen mit dem Token an das eigentliche Anwendungssystem weiter. In der Anwendung kann anschließend die Ausführungsberechtigung des Benutzers verifiziert werden.
Dabei muss die Authentifizierung der externen Anwendung noch nicht gemäß SpringSecurity (OAuth2.0) auf einen OAuth2.0 Client (mit Client-ID u. Client-Secret) migriert worden sein, sondern es kann nach wie vor ein technischer Nutzer (mit Username u. Passwort) zur Authentifizierung verwendet werden.
Zu beachten ist, dass die externe Anwendung die Authentifizierungsdaten bei jeder fachlichen Anfrage an das Service-Gateway sendet.
Das Service-Gateway initiiert die Authentifizierung über den Baustein isy-security, erhält ein gültiges Access-Token vom IAM-Service und leitet dieses dann in Verbindung mit der fachlichen Anfrage an die Geschäftsanwendung weiter.
Das Access-Token wird dabei nicht an die externe Anwendung ausgeliefert, daher muss jede fachliche Anfrage der externen Anwendung erneut authentifiziert werden, obwohl das vorherige Access-Token noch gültig wäre.
Im nachfolgenden Sequenzdiagramm sieht man den logischen Ablauf von Authentifizierung und Autorisierung im Zusammenspiel der System-Komponenten mit dem Service-Gateway aber ohne Authentication-Gateway noch einmal verdeutlicht:
Die Authentifizierung über das SGW (Service Gateway) stellt einen wichtigen Schritt in der Sicherung von Anwendungen dar.
Um diesen Prozess effektiv umzusetzen, empfiehlt sich die Verwendung der Methode authentifiziereClient des neu entwickelten Authentifizierungsmanagers.
Mit dessen Hilfe ist es möglich, den Client zu authentifizieren und sicherzustellen, dass nur autorisierte Clients Zugriff auf die Ressourcen erhalten.
Durch die Nutzung dieses speziellen Authentifizierungsmechanismus wird eine robuste und zuverlässige Sicherheitsschicht implementiert, um unautorisierten Zugriff und potenzielle Sicherheitslücken zu verhindern.
Weitere Informationen und detaillierte Anleitungen zur Verwendung der authentifiziereClient-Methode können in der entsprechenden Dokumentation des Authentifizierungsmanagers
oder in den Nutzungsvorgaben gefunden werden.
In einer zukünftigen Version von IsyFact wird in einer neu eingeführten aber separierten Komponente der Anwendungslandschaft (Authentication-Gateway) eine neue Authentifizierungslogik (Direkte Authentifizierung am IAM-Service) für die Authentifizierung von Anwendungen eingeführt.
Die Authentifizierung wird von der eigentlichen fachlichen Anfrage getrennt, so dass sie nur einmal durchgeführt werden muss und das erhaltene Access-Token (innerhalb seiner Gültigkeit) auch für die weiteren fachlichen Anfragen verwendet werden kann.
4.3.2.2. Direkte Authentifizierung am IAM-Service
Damit eine externe Anwendung auf die Ressourcen eines aufgerufenen Anwendungsystems zugreifen kann, benötigt sie ein gültiges Access-Token. Dieses Token muss sich die externe Anwendung zuerst beschaffen, indem sie sich beim IdentityAccessManagement-Service (IAM-Service) authentifiziert.
Die folgende Abbildung zeigt die zukünftig intendierte System-Architektur, die hier zum Einsatz kommen soll. Zukünfig sollen die Aufrufe des IAM-Service direkt aus der externen Anwendung über ein Authentication-Gateway erfolgen.
In der Abbildung sind die folgenden Ablaufschritte dargestellt:
-
Für die Authentifizierung einer externen Anwendung existiert ein eigener Servicepunkt, das Authentication-Gateway. An diesen Servicepunkt werden von der extenen Anwendung die Authentifizierungsdaten übergeben.
-
Das Authentication-Gateway leitet die Authentifizierungsdaten an den IAM-Service weiter.
-
Der IAM-Service prüft die Authentifizierungsdaten und liefert dem Authentication-Gateway ein Access-Token zurück.
-
Das Authentication-Gateway übergibt das Access-Token der externen Anwendung.
-
Die externe Anwendung kann dieses Access-Token speichern und es anschließend für mehrere fachliche Anfragen an das Anwendungssystem (über das Service-Gateway) verwenden.
-
Das Service-Gateway leitet die fachliche Anfrage zusammen mit dem Access-Token an das aufzurufende Anwendungssystem weiter. Im aufgerufenen Anwendungssystem wird anschließend das jeweils mitgelieferte Access-Token validiert. Hierzu werden aus dem Access-Token dessen Signatur, dessen Ablaufdatum und die dort hinterlegten Berechtigungen entnommen und überprüft.
Die neue System-Architektur hat den Vorteil, dass in der externen Anwendung eine Wiederverwendung des Access-Tokens ermöglicht, was zu einer starken Verringerung der Authentifizierungs-Anfragen an das IAM führt.
Dabei wird (wie in der bisherigen Systemarchitektur) neben der neuen Authentifizierungslogik des Client-Credential-Flows auch die bisherige Authentifizierungslogik des Resource-Owner-Password-Credentials-Flows unterstützt. Der Client-Credential-Flow dient dabei der Authentifizierung eines technischen Clients, und über den Resource-Owner-Password-Credentials-Flow erfolgt die Authentifizierung eines technischen Nutzers.
Das nachfolgende Sequenzdiagramm zeigt noch einmal schematisch den logischen Ablauf der Authentifizierung und Autorisierung im Zusammenspiel der System-Komponenten und dem Authentication-Gateway:
4.3.3. Ausführung Batch & Task
4.3.3.1. Absicherung eines Batches
Gemäß der IsyFact-Systemlandschaft - siehe Grobe Architektur des Batchrahmens - ist ein Batch teil eines Anwendungssystems und setzt sich - siehe Fachliche Architektur eines Batch in der Anwendungslandschaft - aus den Komponenten (1) Batch-Logik und -Steuerung sowie den dabei eingesetzten (2) Fachkomponenten zusammen. Da die Absicherung zur Ausführung eines Batches immer ohne User-Interaktionen stattfindet, ist dieser als Confidential Client einzustufen, weil er in der Lage sein muss, die notwendige Vertraulichkeit zur Wahrung seiner Anmeldeinformationen sicherzustellen.
Ein Batch wird über ein Batch-Client oder Startprogramm – meist ein Shellscript, UC4, JobNetz, CronJob, o.ä. – initialisiert und gestartet. Diese Batch-Clients sind systemseitig dazu berechtigt, den dedizierten Batch auszuführen und damit zu starten. Somit ruft der Batch-Client die Komponente Batch-Logik in der Nutzungsschicht der Anwendung auf, die die notwendigen Initialisierungen vornimmt. Genau hier erfolgt frühzeitig die Unterscheidung welcher Credential-Flow (Resource-Owner-Password-Credential Flow oder Client-Credential Flow) zur Authentifizierung und Autorisierung des Batch verwendet werden soll.
Die Abbildung Absicherung eines Batch stellt den logischen Ablauf zur Absicherung eines Batches skizzenhaft dar.
Über die Batch-Konfiguration wird gesteuert, ob der Batch mit einem Technischen Nutzer und den zugehörigen Authentifizierungsdaten Benutzer und Passwort über den Resource-Owner-Password-Credential Flow authentifiziert und autorisiert wird oder mit einem Client und den zugehörigen Authentifizierungsdaten Client-ID und Client-Secret über den Client-Credential Flow.
Je nach verwendetem Credential-Flow erfolgt mit den jeweiligen erhaltenen Authentifizierungsdaten des Batch-Nutzers dann die eigentliche Authentifizierung durch den IAM-Service der Plattform.
Dazu werden die im Baustein isy-security bereitgestellten Schnittstellen genutzt.
Im IAM-Service wird zu den übergebenen Authentifizierungsdaten der dort verwaltete Benutzer ermittelt und validiert. Bei erfolgreicher Authentifizierung wird aus den Benutzerdaten ein Access-Token generiert. Dieses Token beinhaltet alle notwendigen Informationen - siehe Inhalte der Access-Token, um eine Authentifizierung und Autorisierung an den nachfolgenden Aufrufen von Fachkomponenten durchführen zu können. Das IAM-System liefert das so generierte Access-Token an die aufrufende Komponente zurück.
Im Sicherheitsbaustein isy-security wird zur weiteren Verwendung aus dem Access-Token ein SecurityContext initialisiert und aufbereitet, der somit alle notwendigen Informationen wie das Access-Token, dem Nutzer zugeordnete Rollen, etc. enthält.
Für die weiteren Prozessschritte im Batch wird dieses Access-Token immer weitergereicht, sodass dieser bei der Ausführung seiner Fachanwendungen sich entsprechend diesen gegenüber authentifizieren und autorisieren kann.
Um sicherzustellen, dass ein Batch über seine gesamte Laufzeit ein gültiges Access-Token besitzt und sich jederzeit an den Fachanwendungen authentifizieren und autorisieren kann, sollte der Batch die Gültigkeitsdauer des Access-Tokens prüfen. Sollte die Gültigkeitsdauer des Access-Tokens kleiner sein als die vorgegebene bzw. konfigurierbare Mindestgültigkeitsdauer, dann muss der Batch das Access-Token durch eine erneute Authentifizierung erneuern. Das so erneuerte Access-Token kann nun wieder für ein oder mehrere Verarbeitungszyklen verwendet werden, ohne dass es in den eventuell kaskadierend aufgerufenen Fachanwendungen zu einem Fehler mangels gültigem Access-Tokens kommen kann.
4.3.3.2. Absicherung von Aufgaben (Tasks)
Die in diesem Kapitel beschriebene Absicherung von Aufgaben unterscheidet sich gegenüber eigenständigen Batch-Anwendungen dahingehend, dass Aufgaben als integrierter Anteil einer eigentlichen Anwendung definiert sind. Sie besitzen in der Regel einen kleineren Umfang als Batches und werden nicht manuell von außen gesteuert. Stattdessen werden sie durch die Anwendung selbst konfiguriert, zeitlich geplant und selbstständig ausgeführt. Daher müssen Aufgaben, als Teil einer Komponente des Anwendungskerns, über andere Mechanismen abgesichert werden.
Mit Einführung des Bausteins isy-security werden auch für die Absicherung von Aufgaben beide Credential-Flows Client-Credential Flow und Resource-Owner-Password-Credential Flow unterstützt.
Das bedeutet, dass die für die Aufgaben-Authentifizierung verwendete Parametrisierung per Konfiguration in isy_task einerseits wie bisher als NatürlicherNutzer zu Benutzer und Passwort und neu als TechnischerNutzer (Client) zu Client-ID und Client-Secret aufgelöst werden kann.
Mit IsyFact-3 soll bevorzugt der Client-Credential Flow und den Properties Client-ID und Client-Secret verwendet werden.
Zur Unterstützung einer weichen Migration wird mit IsyFact-3 der Resource-Owner-Password-Credential Flow mit Benutzer und Passwort weiterhin möglich sein.
Für jede Aufgabe wird per Task-ID die Definition der Authentifizierungsdaten in der Betriebskonfiguration erstellt.
In Abbildung Absicherung von Aufgaben (Tasks) wird der logische Ablauf zur Absicherung einer Aufgabe mit dem neuen Security-Baustein isy-security im Zusammenspiel mit der Bibliothek isy-task skizziert.
Sobald eine Anwendungskomponente einen fachlichen Ablauf als abgekoppelten Hintergrundprozess und somit als Aufgabe ausführen möchte, startet diese eine Initialisierung der Aufgabe mit der TaskID als Parameter.
In isy-task wird die übergebene TaskID verwendet, um in der Betriebskonfiguration gemäß den Task-Konfigurations-Konventionen nach den entsprechenden Konfigurationswerten aufzulösen.
Der gestartete Aufgaben-Prozess von isy-task ermittelt dann anhand der übergebenen TaskID den Credential-Flow-Typ und entscheidet durch diese die entsprechende Authentifizierungsmethode in isy-security aufzurufen.
Der Baustein isy-security gibt die Authentifizierungsdaten an das IAM-System weiter und erhält von diesem bei erfolgreicher Authentifizierung ein gültiges Access-Token zurück.
Dieses erhaltene Access-Token wird interpretiert und zur weiteren Verwendung ein SecurityContext initialisiert und aufbereitet.
Der Aufgaben-Prozess erhält dann den initialisierten SecurityContext zurück.
4.3.4. Autorisierungsverfahren
Mit SpringSecurity (OAuth2.0) werden die vier Berechtigungszuteilungsverfahren (Credential Flows) Authorization-Code-Credentials, Implicit-Credentials, Resource-Owner-Password-Credentials und Client-Credentials spezifiziert. Innerhalb der IsyFact werden bei der Autorisierung von Anwendungsaufrufen (von intern oder extern) die beiden Verfahren Resource-Owner-Password-Credential und Client-Credential angewendet, da es sich hierbei ausschließlich um die Berechtigungszuteilung für Confidential-Clients dreht.
4.3.4.1. Resource-Owner-Password-Credential Flow
Der Resource-Owner-Password-Credential-Flow, der als Authentifizierungsdaten die Attribute Username und Passwort verwendet, sollte nur eingesetzt werden, wenn die involvierte Client-Anwendung ein hohes Vertrauen zur Wahrung der Authentifizierungsdaten sicherstellt oder wenn keine andere Art der Berechtigungszuteilung verfügbar ist, da hierbei die Authentifizierungsdaten des Benutzers durch die Client-Anwendung gehen bzw. direkt in ihr gespeichert sind.
In IsyFact wird dieses Verfahren eingesetzt, um eine selbständig laufende Anwendung (z.B. Batch, Task) als technischen Benutzer zu authentifizieren, der mit seinen ihm zugeteilten Rollen im an das IAM-System angeschlossene Benutzerverzeichnis verwaltet wird.
So wird die Authentifizierung für einen techn. Benutzer über diesen Authorization-Flow abgebildet.
Im vorherigen Bild wird der logische Ablauf des Resource-Owner-Password-Credential-Flows dargestellt. Hierbei wird die Konfiguration des techn. Benutzers als der Resource-Owner dargestellt.
Einem Confidential Client wird die Konfiguration (1.) eines techn. Benutzers mit den Authentifizierungsdaten Username und Passwort zugeordnet.
Dieser techn. Benutzer muss mit seinen Rollen im Benutzerverzeichnis vorhanden und gepflegt sein.
Zusätzlich verlangt der Resource-Owner-Password-Credential-Flow eine Authentifizierung des Confidential Client selbst.
Die dafür verwendeten Authentifizierungsdaten Client-ID und Client-Secret müssen vor der Nutzung für die Client-Anwendung definiert und mit dem IAM-System abgestimmt sein.
Die so konfigurierte (Confidential-Client)-Anwendung schickt (2.) dann im Access Token Request diese beiden Authentifizierungsdaten an den IAM-Service. Im IAM erfolgt mit den so übergebenen Authentifizierungsdaten die Authentifizierung sowohl des Confidential Client, als auch des techn. Benutzers als Resource-Owner, die im Ergebnis ein gültiges Access-Token mit den Rollen des techn. Benutzers als Antwort (3.) zurückgeliefert.
Die Client-Anwendung kann dann, mit dem so erhaltenen Access-Token und in den Rollen des techn. Benutzers, ihre Fachanwendungen aufrufen. Das Access-Token enthält alle notwendigen Daten, um zu verifizieren, ob die aufrufende Anwendung ordnungsgemäß authentifiziert und autorisiert ist.
4.3.4.2. Client-Credential Flow
Der Client-Credential-Flow wird und darf nur zur Berechtigungszuteilung eingesetzt werden, wenn die Client-Anwendung selbst auch der Besitzer der Authentifizierungsdaten und damit als Confidential-Client-Anwendung eingestuft ist.
Dieser Credential-Flow ist nach SpringSecurity OAuth2.0 auch die einzige Möglichkeit einen technischen Nutzer (Client) zu authentifizieren.
Es erfolgt hierbei keine Interaktion durch einen Benutzer, der sein Passwort eingeben müsste, sondern die Schritte zur Authentifizierung und Autorisierung der Client-Anwendung laufen selbständig als Hintergrundprozess analog einer Batch-Anwendung ab.
Die dabei verwendeten Authentifizierungsdaten Client-ID und Client-Secret müssen vor der Nutzung für die Client-Anwendung definiert und mit dem IAM-System abgestimmt sein.
Die Verwaltung des Clients mit dem ihm zugeordneten Rollen erfolgt im IAM-System.
Im vorherigen Bild wird der logische Ablauf des Client-Credential-Flows dargestellt. Hierbei kann die Client-Anwendung nach einem Access-Token beim IAM anfragen (1.), indem sie dabei ihre eigenen Client-Authentifizierungsdaten oder anderweitig unterstützte Authentifizierungskriterien verwendet. Die Authentifizierung mit diesen so übermittelten Authentifizierungsdaten erfolgt dann im IAM-Service. Bei erfolgreicher Authentifizierung wird (2.) ein gültiges Access-Token mit den Rollen des Clients als Antwort zurückgeliefert. Mit dem so erhaltenen Access-Token kann die Client-Anwendung dann ihre Fachanwendungen aufrufen. Das Access-Token enthält alle notwendigen Daten, um zu verifizieren, ob die aufrufende Anwendung ordnungsgemäß authentifiziert und autorisiert ist.
4.4. Access-Token
4.4.1. Inhalte der Access-Token
In IsyFact sind Access-Token vom Typ JSON Web Token (JWT), das heißt, sie sind konform zum JWT-Standard (JSON Web Token (JWT)) und enthalten Informationen über den authentifizierten Nutzer in Form von 'Claims', die für die Autorisierung und Ausführung des angeforderten Service benötigt werden. Diese werden bei Erzeugung des Access-Tokens durch das IAM-System hineingeschrieben und können von der Anwendung ausgelesen werden.
Das Minimum an Informationen, die ein JWT in IsyFact enthalten muss - zusätzlich zu den im JWT-Standard vorgeschriebenen, sind folgende:
| Information: | Claim Name: | Claim Type: |
|---|---|---|
Kennung der durchführenden Behörde |
BHKNZ |
non-namespaced custom claim |
Interne Kennung des durchführenden Benutzers |
internekennung |
non-namespaced custom claim |
Kennung des durchführenden Benutzers |
preferred_username |
IANA Public Claim Name / OIDC Standard Claim |
Name des durchführenden Sachbearbeiters |
family_name |
IANA Public Claim Name / OIDC Standard Claim |
Rollen des durchführenden Benutzers |
roles |
IANA Public Claim Name |
Refresh-Token sind für Anwendungen 'opaque Token'. Sie bestehen aus Universally Unique Identifier (UUID), einer zufälligen und einzigartigen Zeichenkette. Diese ist nur für den IAM-Service von Bedeutung. Sie werden vom IAM-Service erzeugt und mit dem Access-Token an die Anwendung geschickt. Diese speichert es und schickt es wieder an den IAM-Service, um ein neues Access-Token zu erhalten.
4.4.2. Validierung der Access-Token
Wenn eine Ressource oder ein Service einer Anwendung angefragt wird, muss das Access-Token von der empfangenden Anwendung validiert werden. Dazu sind folgende Validierungen verpflichtend:
-
Prüfung des Access-Tokens auf Echtheit/Authentizität
-
Prüfung des Access-Tokens auf Gültigkeit
Prüfung des Access-Tokens auf Echtheit/Authentizität
Die Prüfung auf Echtheit belegt, ob das Access-Token wirklich von dem bekannten IAM-Service der Anwendungslandschaft ausgestellt wurde und dass es nicht nachträglich verändert wurde. IsyFact verwendet vom IAM-Service signierte JWT Access-Token, wie in OAuth: Self-Encoded Access Tokens beschrieben. Zur Prüfung der Echtheit muss die Signatur von dem IsyFact-Anwendungssystem verifiziert werden, wie in RFC 9068: Validating JWT Access Tokens beschrieben.
Prüfung des Access-Tokens auf Gültigkeit
Access-Token besitzen eine zeitlich begrenzte Gültigkeit, die im Ermessen der Anwendungslandschaft definiert werden kann. Durch die begrenzte zeitliche Gültigkeit kann sichergestellt werden, dass das Access-Token kein 'ewiger Universalschlüssel' ist, sondern regelmäßig erneuert werden muss. Die Prüfung auf Gültigkeit gibt an, ob der Ablaufzeitpunkt des Access-Tokens bereits erreicht wurde. Für ein gültiges Access-Token muss der im Header-Claim 'exp' enthaltene Zeitstempel in der Zukunft liegen.
Reaktion auf ein invalides Access-Token
Wenn eine der oben beschriebenen Prüfungen fehlschlägt, ist das Access-Token invalide und die Anfrage muss abgelehnt werden. Als Antwort wird der HTTP status error code: 401 (Unauthorized) gesendet mit dem WWW-Authenticate header: Bearer error="invalid_token" u. error_description= <Fehlerbeschreibung> z.B. "The access token expired".
Beide Prüfungen werden durch den Baustein isy-security bzw. durch das Spring Security Framework implementiert.
Bei einem höheren Sicherheitsbedarf können weitere Informationen (Registered Claims) im Token mitgeliefert und validiert werden. Falls gefordert ist, auch vorzeitig abgelaufene Access-Token (z.B. durch globales Logout des Benutzers oder Rücknahme (Revoke) der Legitimation des Benutzers) zu erkennen und zu sperren, kann das IsyFact-Anwendungssystem das Access-Token zur Prüfung an den IAM-Service schicken, wie in RFC 7662: OAuth 2.0 Token Introspection beschrieben.
Um auf eine geschützte Ressource eines anderen Anwendungssystems (Ressourcen-Server) zugreifen zu können, muss die Anwendung in der Anfrage (Request) das Access-Token mitgeben.
Dazu wird es aus dem SecurityContext gelesen und - Base64-codiert, wie erhalten - mit in den Header des HTTP-Requests gesetzt.
Genauer gesagt, in das "Authorization" Request-header Feld und mit dem "Bearer" Authentifizierungs-Schema (Authorization: Bearer <accessTokenStringBase64> - Siehe auch:
RFC 6750 Authorization Bearer Token).
Der Ressourcen-Server liest das Access-Token aus dem Request-Header und gibt - nach Validierung des Access-Tokens und Prüfung des Inhalts (Ablaufdatum, Rechte aus Rollen) - die angeforderte Ressource frei.
4.4.3. Aktualisierung der Access-Token
Ein Access-Token muss eine begrenzte Gültigkeitsdauer besitzen, um den Zugriff auf geschützte Ressourcen zeitlich zu beschränken. Sobald die Gültigkeitsdauer überschritten ist, muss das Access-Token als ungültig erkannt werden (siehe Validierung der Access-Token). Die Verwendung eines abgelaufenen Access-Tokens bei einer Anfrage muss vom empfangenden System erkannt und mit HTTP status error code: 401 und der Fehlerbeschreibung: "The access token expired" beantwortet werden, wie oben beschrieben. Der Aufrufer muss die Antwort verarbeiten und die Anfrage mit einem gültigen Access-Token erneut senden.
Für menschliche Nutzer wurde mit dem Refresh-Token ein Mechanismus eingeführt, der eine automatische Aktualisierung des Access-Tokens erlaubt, ohne dass der Benutzer interagieren muss:
Das Webserver-Modul mod_auth_openidc koordiniert für Portal-Anwendungen die Erneuerung des Access-Tokens (automatisch mit Refresh-Token bzw. durch erneute Authentifizierung (siehe: Aufruf Web-Oberfläche/Portal)) - der Baustein Security wird hierfür nicht verwendet.
Technische Nutzer (Clients) können ihr Access-Token nur durch eine erneute Authentifizierung (siehe: Aufruf Service-Gateway bzw. Ausführung Batch & Task) erneuern.
Konfiguration des Refresh-Tokens im IAM-System
Zur weiteren Erhöhung der Sicherheit kann und sollte das Refresh-Token mit Rotation konfiguriert werden, denn dann wird bei Aktualisierung des Access Token auch ein neues Refresh-Token ausgestellt. Eine eventuelle nochmalige Einreichung desselben Refresh-Token bedeutet, dass sich unbefugte Dritte dieses Refresh-Token aneignen konnten. Das wird durch die 'Automatic Reuse Detection' im IAM-System erkannt und Gegenmaßnahmen ergriffen.
Die Ablaufzeit des Refresh-Token bestimmt, wie lange der Benutzer an der Anwendung angemeldet ist und mit ihr arbeiten kann, ohne sich neu authentifizieren zu müssen. Hierbei muss Sicherheit gegen Benutzerkomfort abgewogen werden.
4.5. Nutzung des Behördenkennzeichens
Als optional mögliche 2-Faktor-Authentifizierung ist im IAM-Service die Übermittlung und Auswertung des Behördenkennzeichens (BHKNZ) vorgesehen. Die Implementierung des IAM-Service muss für die 2-Faktor-Authentifizierung dieses Feature unterstützen, andernfalls wird das BHKNZ als optionales Attribut betrachtet. Wenn die IAM-Service-Implementierung dieses Feature unterstützt, dann wird ein mit den Authentifizierungsdaten gemeinsam übergebenes Behördenkennzeichen gegen das Behördenkennzeichen aus dem zu authentifizierenden Nutzerprofil geprüft.
Wie in Schnittstelle des Bausteins Security beschrieben, wird bei den Authentifizierungsmethoden authentifiziereClient() und authentifiziereSystem() das Behördenkennzeichen als optionaler Parameter an den Authentifizierungsmanager übergeben, der es mit den anderen Authentifizierungsdaten zusammen an den IAM-Service weiterleitet.
4.6. Aufruf des IAM-Services über unterschiedliche URIs
Wenn in einer Anwendungslandschaft der IAM-Service über mehrere unterschiedliche URIs aufgerufen werden kann, dann benötigt eine Anwendung mindestens eine bis alle dieser URIs in seiner Konfiguration, um eine Tokenvalidierung erfolgreich durchzuführen.
Dies ist zum Beispiel der Fall, wenn eine interne URI des IAM-Services für Aufrufe von innerhalb der Anwendungslandschaft und eine externe URI für Aufrufe von außerhalb der Anwendungslandschaft benötigt wird oder wenn sich die URIs aufgrund verschiedener Netzwerkzonen bzw. technischer Kommunikationskanäle unterscheiden (müssen).
Der Baustein isy-security bietet Unterstützung, um die Nutzung unterschiedlicher URIs für den IAM-Service zu ermöglichen.
Die nachfolgende Skizze zeigt dies schematisch auf.
Die externe IAM-URI wird vom Portal als Redirect an den WebClient zurückgeliefert, so dass dieser den IAM-Service direkt von extern aufrufen kann, um den IAM-Login-Dialog im WebClient zur Anzeige zu bringen.
Nach erfolgreicher Authentifizierung wird die externe IAM-URI in den Access-Token (iss-Claim) geschrieben.
Die interne IAM-URI wird von der Geschäftsanwendung benötigt, um direkt auf internem Wege mit dem IAM zu kommunizieren, z.B. zum Laden von Zertifikatsinformationen.
Die Geschäftsanwendung benötigt in ihrer Konfiguration alle IAM-URIs, um alle Access-Token validieren zu können.
Dazu gehört die zum ursprünglichen IAM-Aufruf verwendete URI (issuer-uri), die gegen den Wert im iss-Claim des Tokens verifiziert wird.
Die Prüfung schlägt fehl, wenn das Access-Token über die externe IAM-URI ausgestellt wurde, in der Geschäftsanwendung jedoch (nur) die interne IAM-URI zum Nachladen von Zertifikaten konfiguriert ist.
Um nun in einer Geschäftsanwendung Access-Tokens erfolgreich zu validieren, die über eine in der Anwendung abweichend konfigurierte IAM-URI ausgestellt wurden, müssen alle genutzten URIs des IAM-Services in der Anwendung hinterlegt werden. Dies geschieht über die Anwendungskonfiguration. Auf diese Weise können beliebig viele IAM-URIs konfiguriert werden.
Weitere Details zur Konfiguration mehrerer URIs eines IAM wird in den Nutzungsvorgaben - Konfiguration von mehreren IAM-URIs beschrieben.
Konfigurationsdetails
Zur weiteren Vertiefung dieser Sonderkonstellation kann in der Spring-Dokumentation und für Details bei der Implementierung bzw. Konfiguration kann in den Nutzungsvorgaben nachgeschlagen werden.
4.7. Unterstützung von Multi-Tenancy
Der Baustein isy-security unterstützt Multi-Tenancy, sodass eine Trennung von Benutzerarten, Zugriffswegen oder IAM-Instanzen in sogenannte Tenants möglich ist.
Beispiele für eine Trennung nach:
Benutzerart:
-
Trennung von Anwendern und Systemen
-
Trennung von internen und externen Anwendern
Zugriffsweg:
-
Trennung zwischen sgw- und Portal-Authentifizierungen
IAM-Instanz:
-
Nutzung mehrere interner und/oder externer IAM-Services
Die Zuweisung der Benutzer zu einzelnen Tenants erfolgt im IAM-Service.
Wichtig ist, dass alle Systeme, die entlang eines Zugriffsweges aufgerufen werden, jeweils für sich die tenant-spezifische Konfiguration benötigen. Dies bedeutet zum Beispiel, dass einer Geschäftsanwendung, die ein Access-Token von einem speziellen Tenant bei der Autorisierung validieren möchte, die Konfiguration des Tenants in der anwendungseigenen Konfiguration vorliegen muss. Beim Einsatz von Multi-Tenancy ist daher genau zu planen, welcher Tenant (bzw. für welchen Tenant ausgegebene Access-Tokens) Zugriff auf welche Anwendung ermöglichen sollen. Bei n Benutzergruppen müssen dann bis zu n unterschiedliche Tenant-Konfigurationen in der Anwendungskonfiguration existieren. Eine detaillierte Beschreibung anhand eines Beispiels findet sich im nächsten Kapitel.
Für IsyFact-Anwendungslandschaften werden mindestens folgende zwei Tenants für den Zugriff von außerhalb der Anwednungslandschaft gefordert:
-
Tenant 1: Gruppierung aller Systeme mit Zugriffsweg über das Service-Gateway.
-
Tenant 2: Gruppierung aller Anwender mit Zugriffsweg über das Portal.
Hintergrund: Ein Benutzer darf nur über einen festgelegten Zugriffsweg Zugriff auf die Anwendungslandschaft erhalten. Ein Anwender darf nur über das Portal auf die Anwendungslandschaft zugreifen, nicht aber über ein Service-Gateway. Bei technischen Nutzern (Systemen) ist dies genau umgekehrt.
4.7.1. Umsetzung für mehrere Zugriffswege
Die verschiedenen dargestellten Zugriffswege Portal, Service-Gateway, Authentication-Gateway oder interne Anwendungs-Authentifizierung (Batch/Task/Kontextwechsel) bis hin zu mehrfachen IAM-Instanzen können daher als einzelne Tenants nicht nur unterschieden, sondern auch als Multi-Instanzen des gleichen Typs identifiziert werden.
Die an den Zugriffswegen beteiligten Komponenten unterscheiden sich in ihrem Aufbau, ihrer Konfiguration und ihrer Funktionalität, sodass jede genau die speziellen Eigenheiten - siehe dazu Kapitel Aufruf Web-Oberfläche/Portal, Authentifizierung über das SGW am IAM-Service, Direkte Authentifizierung am IAM-Service und Ausführung Batch & Task bzw. Aufruf von Nachbarsystemen - am besten bedienen oder erfüllen kann. Die Umsetzung und sicherheitsrelevante Trennung dieser Zugriffswege werden als eigenständige Tenants betrachtet und können somit auch als mehrere Instanzen pro Zugriffsweg eingerichtet werden. Dadurch ist es möglich fachliche Unterschiede über den gleichen technischen Zugriffsweg bei der Authentifizierung zu machen.
Die bisher aufgezeigten Authentifizierungswege werden in Bezug auf isy-security als jeweilig unterschiedliche Tenants behandelt bzw. konfiguriert.
Aber auch pro Authentifizierungsweg ist es möglich unterschiedliche Tenants sprich mehrere Instanzen des gleichen Typs einzurichten.
Folgendes Beispiel zeigt die Trennung nach Zugriffswegen (Abbildung 16):
In diesem Beispiel wurde ein weiterer IAM-Service aufgenommen, um die Möglichkeiten zur Nutzung mehrere IAM-Services zu verdeutlichen. Dieser kann auch außerhalb der Anwendungslandschaft betrieben werden. Die IsyFact sieht weiterhin die Nutzung eines einzelnen IAM-Service je Anwendungslandschaft vor.
Ausgangssituation
-
Interne und externe Anwender werden Tenant 1 (T 1) zugewiesen. Ihnen steht der Zugang über das Portal zur Verfügung.
-
Externen Anwendungen wird der Tenant 2 (T 2) zugewiesen. Der Zugriff auf die Anwendungslandschaft erfolgt über das SGW.
-
Internen Anwendungen wird der Tenant 3 (T 3) zugewiesen.
-
Tenants 1 und 3 werden in IAM 1 verwaltet.
-
Tenant 2 wird in einem separaten IAM-Service (IAM 2) verwaltet.
Aufruf der Geschäftsanwendung (GA)
-
Die Anwender greifen über das Portal auf die GA zu. Daher muss in der GA der Tenant 1 (T 1) konfiguriert sein.
-
Die externen Anwendungen greifen über das SGW auf die GA zu. Daher muss in der GA auch der Tenant 2 (T 2) konfiguriert sein.
-
Die interne Batch-Anwendung greift auf die GA zu. Daher muss in der GA auch der Tenant 3 (T 3) konfiguriert sein.
-
Fehlt eine der drei Tenant-Konfigurationen in der GA, so erhält der betroffene Tenant bzw. der dem Tenant zugewiesene Anwender/Anwendung keinen Zugriff auf die GA.
5. Rollen & Rechte
Die Vergabe von Rollen ist das Mittel der Benutzeradministration, um Anwender der Anwendungslandschaft mit Berechtigungen auszustatten. Die Vergabe von Rollen an einen Anwender (menschlicher und technischer) erfolgt im Querschnitt: in der Querschnittsanwendung Benutzerverzeichnis.
Es ist konzeptionell beabsichtigt, dass die Administration per Rollen recht grobgranular erfolgt. Eine administrative Vergabe feingranularer Rechte ist konzeptionell nicht erwünscht. Die individuelle Zuordnung von Rechten zu Anwendern ist daher prinzipiell nicht möglich. Rechte werden Anwendern ausschließlich indirekt über Rollen zugeordnet. Welche Rechte einer Rolle zugeordnet sind, wird innerhalb der statischen Konfiguration eines IT-Systems definiert und ist damit Teil der Software.
Die Geschäftsanwendung X bietet zwei Dialoge zur Administration von Anwendungseigenschaften.
Die Dialoge sind über die Rolle AnwendungX_Administrator abgesichert.
Innerhalb der Anwendung ist Dialog 1 mit dem Recht AdministrierenDialog1 und Dialog 2 mit dem Recht AdministrierenDialog2 abgesichert.
Grobgranular wird die Rolle AnwendungX_Administrator einem Anwender zugeordnet.
Innerhalb der Konfiguration des IT-Systems X sind beide Rechte konfiguriert und der Rolle AnwendungX_Administrator zugeordnet.
Alle Anwender mit der Rolle AnwendungX_Administrator sind somit innerhalb der Anwendung autorisiert, die beiden Admin-Dialoge zu verwenden.
Der Vorteil an diesem Vorgehen ist, dass Änderungen an der Zuordnung von Anwendern zu Rollen oder von Rollen zu Rechten nur zu lokalen Änderungen führen. Soll eine Rolle andere Rechte in einer Geschäftsanwendung bekommen (z.B. durch das Hinzufügen neuer Dialoge), so kann dies für die Benutzeradministration transparent geschehen. Ebenso sind Änderungen an Anwendern oder ihren zugehörigen Rollen transparent für einzelne Geschäftsanwendungen.
5.1. Spezifikation der Rollen
Rollen werden bereits auf fachlicher Ebene als Teil der Systemspezifikation einer Geschäftsanwendung spezifiziert. Dazu werden zunächst in geeigneter Granularität Rechte definiert, die zur Benutzung bestimmter Funktionalität der Geschäftsanwendung berechtigen. Diese Rechte werden fachlichen Rollen zugeordnet, die dann wiederum den Anwendern der Anwendung zugeordnet werden können. Die fachlichen Rollen ermöglichen in der Regel pauschal den Zugriff auf die Geschäftsanwendung oder, im Sinne der Rolle eines fachlichen Sachbearbeiters, die Nutzung ausgewählter Anwendungsfälle.
5.2. Struktur einer Rolle
Alle Rollen besitzen die folgende Struktur:
Name: Interner Name der Rolle, wie er für die Autorisierung und innerhalb von Anwendungen zur Überprüfung bereitgestellt wird.
Label: Name der Rolle, wie sie in der Oberfläche der Benutzeradministration angezeigt wird. In der Regel ist dieser Name identisch mit dem technischen Namen der Rolle. Eine Abweichung ist nur dann sinnvoll, wenn die Vergabe der Rollen durch den Administrator dadurch intuitiver wird.
Beschreibung: Eine kurze Beschreibung der Rolle in einer fachlichen Sprache, die für die Benutzeradministration verständlich ist.
Typ: Eine Rolle kann fachlich oder technisch sein. Nur fachliche Rollen können über die Benutzeradministration verwaltet werden. Technische Rollen können fachlichen Rollen allerdings untergeordnet werden (siehe weiter unten: Untergeordnete Rollen).
Enthaltene Rechte: Die Ausstattung einer fachlichen Rolle mit Rechten beschreibt den Funktionsumfang, den diese Rolle bei Nutzung der Geschäftsanwendung ermöglicht.
Untergeordnete Rollen: Optional können fachliche Rollen untergeordnete technische Rollen besitzen. Dies ist z.B. immer dann notwendig, wenn ein Anwendungsfall die Services eines Nachbarsystems verwendet. Somit muss im Rahmen des Anwendungsfalls die Service-Schnittstelle des Nachbarsystems aufgerufen werden. Die dazu benötigte, technische Rolle muss der fachlichen Rolle untergeordnet werden, damit dies funktioniert.
Sichtbarkeit der Rolle: Die Sichtbarkeit der Rollen bei der Zuordnung an Anwender, externe Systeme und interne Systeme kann eingeschränkt werden, um die Administration zu vereinfachen.
Die meisten Rollen sind fachlicher Natur. Technische Rollen treten oft im Rahmen von Service-Schnittstellen auf. Bietet eine Geschäftsanwendung Funktionalität über Service-Schnittstellen an, so ist die Nutzung jeder Service-Schnittstelle zumindest durch eine technische Rolle abzusichern. Diese Rollen werden nicht direkt an Anwender vergeben, sondern fachlichen Rollen anderer Geschäftsanwendungen untergeordnet.
Wenn die Anwendung fachliche oder technische Batches enthält, dann müssen für diese Batches in der Spezifikation entsprechende „interne Systeme“ definiert werden.
Die Systemnamen sollten dem folgenden Schema entsprechen: <Anwendungskürzel>_BAT_<Batchname>.
Für jedes dieser internen Systeme müssen eigene fachliche Rollen definiert werden.
5.3. Richtlinien zum Schnitt der Rollen
Zum Schnitt von fachlichen und technischen Rollen gibt es Erfahrungswerte, welche das restliche Kapitel detailliert. Wichtig ist vor allem die Beziehung zwischen fachlichen und technischen Rollen. Des Weiteren sollte die Menge der Rollen so klein wie möglich gehalten werden.
Die Abbildung Abbildung 17 verdeutlicht den Inhalt der folgenden Abschnitte grafisch.
5.3.1. Technische Rollen
Technische Rollen sichern die Kommunikationswege innerhalb der Anwendungslandschaft ab. Sie werden für die Schnittstellen von Geschäftsanwendungen verwendet, welche nur von anderen Geschäftsanwendungen aufgerufen werden.
Technische Rollen berechtigen zur Ausführung der entsprechenden Services der Geschäftsanwendung selbst, sowie aller dadurch mittelbar ausgelösten Aktionen in nachgelagerten Anwendungen. Daher werden diesen technischen Rollen im Regelfall weitere technische Rollen untergeordnet sein, welche die nachgelagerten Anwendungen absichern.
5.3.2. Technische Zugangsrollen
Anwender gelangen in der Regel entweder über das Portal oder den Service-Gateway in eine Anwendungslandschaft.
Um den Zugriff über diese Schnittstellen zentral und einfach zu verwalten, können dafür entsprechende technische Rollen definiert werden (z.B. Zugang_Portal und Zugang_Service_Gateway).
Diese Rollen können dann einfach fachlichen Rollen untergeordnet werden, um den jeweiligen Zugriff zu erlauben.
5.3.3. Technische Querschnitts-Rolle
Für Services des Querschnitts, die nahezu alle Aufrufe benötigen und die keine sicherheitskritischen Operationen anbieten, kann eine zentrale Rolle (z.B. Querschnitt_Nutzer) angelegt werden.
Diese Rolle berechtigt zur Durchführung von unkritischen Operationen im Querschnitt, wie beispielsweise dem Auslesen von Schlüsselwerten.
Wenn die Querschnitts-Rolle den Zugangsrollen untergeordnet ist, darf jeder Anwender mit Zugriff automatisch auch auf den Querschnitt zugreifen. Dies reduziert die Anzahl der Rollen, die einem Nutzer zugewiesen sind, in der Regel deutlich.
5.3.4. Fachliche Rollen
Fachliche Rollen werden für Schnittstellen von Geschäftsanwendungen vergeben, welche Zugänge zur Anwendungslandschaft geben. Dies beinhaltet neben den Dialogen (der grafischen Oberfläche) und Zugängen über das Service-Gateway auch interne Systeme wie beispielsweise Systemtasks oder Batches.
Fachliche Rollen berechtigen zur Ausführung der entsprechenden Aktion über den entsprechenden Zugangsweg, sowie aller dadurch mittelbar ausgelösten Aktionen in nachgelagerten Anwendungen. Daher werden diesen fachlichen Rollen im Regelfall weitere technische Rollen untergeordnet sein, welche die nachgelagerten Anwendungen absichern.
Fachliche Rollen können über die Benutzeradministration verwaltet und Anwendern bzw. Systemen zugeordnet werden. Hierbei ist darauf zu achten, dass die Labels der Rollen sinnvoll genutzt werden.
5.4. Richtlinien zur Benennung der Rollen
Die Benennung von Rollen muss fachlich getrieben sein. Das bedeutet vor allem, dass Rollen für eine fachliche Operation, d.h. den Akteur, angelegt werden. Grundsätzlich gilt, dass die Namen der Rollen ausgeschrieben werden, sofern sie nicht zu lang werden. Ist dies der Fall, sollte der Namen abgekürzt und ein sprechendes Label für die Administration der Rollen vergeben werden.
5.4.1. Fachliche Rollen
Das Schema zur Benennung einer fachlichen Rolle für Anwender kann folgendermaßen aussehen:
<Fachlicher Systemname>_<Funktion>
Der fachliche Systemname beschreibt die Geschäftsanwendung, bzw. die Anwendungsdomäne, in welcher die entsprechende Funktionalität bereitgestellt wird. Er entspricht prinzipiell dem Systemnamen der Systemspezifikation, abzüglich technischer Kürzel.
Da die Rollen für fachliche Operationen angelegt werden, sollten sie unabhängig von technischen Aspekten gelten. So kann beispielsweise die Rolle unabhängig davon gelten, ob die Auskunft über ein Service-Gateway oder das Portal durchgeführt wird. Dies kann durch die Verwendung spezieller technischer Rollen (s. Technische Zugangsrollen) erreicht werden.
IT-Systeme werden intern in Form von Batches oder Timer-Tasks aktiv. Auch hier findet ein Zugang zur Anwendungslandschaft statt. Das Schema zur Benennung einer fachlichen Rolle für IT-Systeme kann folgendermaßen aussehen:
<Fachlicher Systemname>_SYSTEM_<Suffix>
Im Regelfall gibt es nur eine fachliche Rolle pro IT-System, die alle Batches und Tasks absichert.
Gibt es beispielsweise mehrere Batches in einer Anwendung, so sollten die einzelnen Batches mit verschiedenen Rechten abgesichert werden, die alle derselben Rolle zugeordnet sind. Falls mehrere differenzierte, fachliche Rollen erforderlich sind, werden die Rollen um ein entsprechendes Suffix ergänzt. Dies kann der Fall sein, wenn es fachlich unterschiedliche Nutzer von Tasks und Batches gibt. Zusätzlich dazu kann es erforderlich sein, einen (technischen) Anwender anzulegen, welchem die entsprechenden Rollen zugeordnet werden.
5.4.2. Technische Rollen
Das Schema zur Benennung einer technischen Rolle kann folgendermaßen aussehen:
<Technischer Systemname>_<Servicename>
Die Namen technischer Rollen enthalten keine festen Bestandteile wie z.B. SYSTEM, da es sich immer um Services handelt.
Der Servicename muss eindeutig und sprechend sein; vor allem, wenn mehrere Services mit derselben Rolle gemeinsam abgesichert werden.
Da die Rollen nur innerhalb der Anwendungslandschaft zum Einsatz kommen und nicht administriert werden müssen, wird der technische Systemname verwendet.
Auch hier sollte auf die Länge des Namens geachtet werden und im entsprechenden Fall, wie bei fachlichen Rollen, eine Abkürzung des Namens mit sprechendem Label vorgenommen werden.
5.5. Entwurf von Rollen
Wird ein neues IT-System entwickelt, sind die oben genannten Richtlinien zum Schnitt und zur Benennung der Rollen stärkstens empfohlen. Hierfür ist eine enge Abstimmung mit der Benutzeradministration und den jeweiligen fachlichen Ansprechpartnern erforderlich. Alle Parteien verfügen über unterschiedliches, sich ergänzendes Fachwissen, das essenziell für die Erstellung von Rollen ist.
Prinzipiell sollten so wenig Rollen wie möglich und so viele wie nötig vergeben werden. Der folgende Prozess bietet eine grobe Richtlinie:
-
Jede Schnittstelle wird mit einem Recht abgesichert.
-
In Abstimmung mit den fachlichen Ansprechpartnern und der Benutzeradministration werden diese Rechte zu technischen bzw. fachlichen Rollen zusammengefasst.
-
In Abstimmung mit den fachlichen Ansprechpartnern und der Benutzeradministration wird ermittelt, ob und welche zusätzlichen technischen Anwender benötigt werden.
-
Vorbereitung der Einspielung der neuen, fachlichen Rollen in die Benutzeradministration. Über das jeweilige Format bestimmt der IsyFact-Baustein, der zur Benutzeradministration eingesetzt wird.
Die Rollen und Rechte sollten bereits während der Erstellung des Systementwurfs entworfen werden, soweit dies möglich ist. Sobald die angebotenen Schnittstellen bekannt sind, können die entsprechenden Rollen nach obigen Richtlinien erstellt werden. Die zugehörigen untergeordneten Rollen lassen sich durch die aufgerufenen Nachbarsystemschnittstellen ermitteln.
5.6. Tests und Inbetriebnahmen
Eine wesentliche Einschränkung der bisherigen Modellierung findet sich bei Tests und Inbetriebnahmen. Es gestaltet sich bislang schwer, dass vor der eigentlichen Inbetriebnahme nur eine kleine Menge von Anwendern auf eine neue Geschäftsanwendung zugreifen kann. So werden oft, auch bei der Ablösung einer Geschäftsanwendung durch eine neue Umsetzung, komplett neue Rollen für die neue Geschäftsanwendung vergeben, um die Absicherung beider Geschäftsanwendungen zu gewährleisten. Dies führt oft zu aufwendigen Migrationen und zu einer stark ansteigenden Menge von Rollen.
Um dies zu vermeiden, kann eine neue fachliche Rolle für eine Art Testmodus eingeführt:
Tester_<Vorhaben>
Geschäftsanwendungen, die bestehende Geschäftsanwendungen ablösen oder vor der offiziellen Inbetriebnahme einer kleinen Menge von Anwendern zur Verfügung stehen, müssen in ihrer betrieblichen Konfiguration einen Schalter besitzen, der einen Testmodus aktiviert. Ist der Schalter (und damit der Testmodus) aktiv, wird zusätzlich zur üblichen Autorisierung auf die zusätzliche, fachliche Rolle geprüft. Somit ist sichergestellt, dass beim Ablösen von alten Geschäftsanwendungen auch die neue Geschäftsanwendung mit denselben Rollen abgesichert und (falls nötig) parallel betrieben werden kann. Genauso funktioniert auch das Freischalten einer neuen Geschäftsanwendung für einen zunächst kleinen Kreis von Anwendern. In beiden Fällen muss zur eigentlichen Inbetriebnahme, anstatt einer aufwändigen Migration, nur ein Schalter in der betrieblichen Konfiguration umgelegt werden.