Migrationsleitfaden IsyFact 3.2.x

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.

Creative Commons Namensnennung Die Nutzung ist unter den Lizenzbedingungen der Creative Commons Namensnennung 4.0 International gestattet.

Für die IsyFact gibt es hiermit drei Versionszweige: IsyFact 1, IsyFact 2 und seit Q1/2023 das neue Major-Release IsyFact 3.0.

Die auf dieser Seite aufgeführten Hinweise sollen IsyFact Anwendungsentwicklern bei der Umstellung einer auf IsyFact 2 basierenden Anwendung auf IsyFact 3.2.x helfen.

1. Geschäftsanwendung

1.1. Bridge-Module

Die drei in IsyFact 2 eingeführten Bridge-Module

isy-serviceapi-core-bridge
isy-serviceapi-sst-bridge
isy-exception-sst-bridge

entfallen in IsyFact 3. In einer Anwendung, die bisher Bridge-Module verwendet und auf IsyFact 3 umgestellt werden soll, müssen daher Anpassungen vorgenommen werden. Die Tabelle Abhängigkeiten in IsyFact 2 vs. IsyFact 3 zeigt für jedes der drei Bridge-Module, durch welches Modul es ersetzt wird. Dabei ist zu beachten, dass zwei der Ersatzmodule eine Abhängigkeit zu IsyFact-1.x haben.

Tabelle 1. Abhängigkeiten in IsyFact 2 vs. IsyFact 3
Abhängigkeit in IsyFact 2	Abhängigkeit in IsyFact 3
`isy-serviceapi-core-bridge`	`isy-serviceapi-core`
`isy-serviceapi-sst-bridge`	`isy-serviceapi-sst`, Version `1.11.1`
`isy-exception-sst-bridge`	`isy-exception-sst`, Version `1.11.1`

Zudem wird die Klasse

de.bund.bva.isyfact.exception.service.bridge.util.BridgeExceptionMapper

ersetzt durch:

de.bund.bva.isyfact.serviceapi.common.exception.ExceptionMapper

1.2. Überwachung

Es sind die Nutzungsvorgaben Überwachung zu IsyFact 3 zu verwenden.

2. Bausteine

2.1. Aufrufkontext

Der Baustein isy-aufrufkontext ist mit der Version 3.1 als deprecated gekennzeichnet und wird nicht mehr weiterentwickelt. Mit der Version 4 wird er endgültig aus dem Projekt entfernt.

Mit dem Umstieg auf isy-security und der Verwendung von REST Schnittstellen wird isy-aufrufkontext nicht länger benötigt.

2.2. Konfiguration

Der Baustein isy-konfiguration ist mit der Version 3.1 als deprecated gekennzeichnet und wird nicht mehr weiterentwickelt. Mit der Version 4 wird er endgültig aus dem Projekt entfernt.

Hintergrund der Deprecation und der Entfernung des Bausteines ist, dass isy-konfiguration schon seit IsyFact 2 nicht mehr weiterentwickelt wird und stattdessen von Springframework bereit gestellte Mechanismen genutzt werden sollen.

Die Dokumentation der Konfiguration mit Spring ist unter folgender Adresse zu finden:

https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.external-config

2.3. Batchrahmen

In IsyFact 3.0 wurde mit der Umstellung auf isy-security das Detailkonzept zur Authentifizierung und Autorisierung aktualisiert. Statt Benutzer, Passwort und BHKNZ muss in der Batch-Konfiguration eine oauth2ClientRegistrationId konfiguriert werden (siehe Eigenschaften eines Batchbenutzers)

Listing 1. Batch-Konfiguration zur Verwendung von isy-sicherheit in IsyFact 2

batch.benutzer=TestUser
batch.passwort=TestPasswort
batch.bhknz=TestBHKNZ

# [...]

Listing 2. Batch-Konfiguration zur Verwendung von isy-security in IsyFact 3

batch.oauth2ClientRegistrationId=TestClient

# [...]

Eine entsprechende Spring Security ClientRegistration wird durch isy-security Konfigurationsparameter bereitgestellt. Die folgenden Beispiele zeigen wie Konfigurationen nach der Migration aussehen können. Für die Batch-Konfiguration ist nicht relevant, ob die ClientRegistration den Resource-Owner-Password-Credentials Flow (authorization-grant-type: password) oder nach der empfohlenen Migration von technischen Nutzern zu Confidential Clients den Client-Credentials Flow (authorization-grant-type: client_credentials) nutzt.

Listing 3. Batch-Konfiguration mit technischen Nutzer

batch.oauth2ClientRegistrationId=TestClient

# [...]

spring.security.oauth2.client.provider.TestRealm.issuer-uri=http://localhost:9095/auth/realms/testrealm
spring.security.oauth2.client.registration.TestClient.client-id=test-client-id
spring.security.oauth2.client.registration.TestClient.client-secret=test-client-secret
spring.security.oauth2.client.registration.TestClient.authorization-grant-type=password
spring.security.oauth2.client.registration.TestClient.provider=TestRealm

# Benutzer, Passwort und BHKNZ werden auf die selbe registrationId abgebildet
isy.security.oauth2.client.registration.TestClient.username=TestUser
isy.security.oauth2.client.registration.TestClient.password=TestPasswort
isy.security.oauth2.client.registration.TestClient.bhknz=TestBHKNZ

Listing 4. Batch-Konfiguration nach Umstellung von technischem Nutzer auf technischen Client

batch.oauth2ClientRegistrationId=TestClient

# [...]

spring.security.oauth2.client.provider.TestRealm.issuer-uri=http://localhost:9095/auth/realms/testrealm
spring.security.oauth2.client.registration.TestClient.client-id=test-user-client-id
spring.security.oauth2.client.registration.TestClient.client-secret=test-user-client-secret
spring.security.oauth2.client.registration.TestClient.authorization-grant-type=client_credentials
spring.security.oauth2.client.registration.TestClient.provider=TestRealm

Die Bausteine isy-sicherheit und isy-sicherheit-keycloak werden durch isy-security abgelöst.

2.4. Task Scheduler

In IsyFact 3.0 wurden mit der Umstellung auf isy-security die Nutzungsvorgaben zur Authentifizierung von Tasks aktualisiert. Statt Benutzer, Passwort und BHKNZ (siehe Properties mit isy-sicherheit in IsyFact 2) muss in den Task Properties eine oauth2ClientRegistrationId konfiguriert werden (siehe Properties mit isy-security in IsyFact 3).

Listing 5. Properties mit isy-sicherheit in IsyFact 2

isy.task.tasks.halloWeltTask.benutzer=TestUser
isy.task.tasks.halloWeltTask.passwort=TestPasswort
isy.task.tasks.halloWeltTask.bhkz=TestBHKNZ

# [...]

Listing 6. Properties mit isy-security in IsyFact 3

isy.task.tasks.halloWeltTask.oauth2ClientRegistrationId=TestClient

# [...]

Eine entsprechende Spring Security ClientRegistration wird durch isy-security Konfigurationsparameter bereitgestellt. Die folgenden Beispiele zeigen wie Konfigurationen nach der Migration aussehen können. Für die TaskScheduler-Konfiguration ist nicht relevant, ob die ClientRegistration den Resource-Owner-Password-Credentials Flow (authorization-grant-type: password) oder nach der empfohlenen User-Migration von einem natürlichen User auf ein technischen Nutzer den Client-Credentials Flow (authorization-grant-type: client_credentials) nutzt.

Listing 7. Properties mit technischem Nutzer

isy.task.tasks.halloWeltTask.oauth2ClientRegistrationId=TestClient

# [...]

spring.security.oauth2.client.provider.TestRealm.issuer-uri=http://localhost:9095/auth/realms/testrealm
spring.security.oauth2.client.registration.TestClient.client-id=test-client-id
spring.security.oauth2.client.registration.TestClient.client-secret=test-client-secret
spring.security.oauth2.client.registration.TestClient.authorization-grant-type=password
spring.security.oauth2.client.registration.TestClient.provider=TestRealm

# Benutzer, Passwort und BHKNZ werden auf die selbe oauth2ClientRegistrationId abgebildet

isy.security.oauth2.client.registration.TestClient.username=TestUser
isy.security.oauth2.client.registration.TestClient.password=TestPasswort
isy.security.oauth2.client.registration.TestClient.bhknz=TestBHKNZ

Listing 8. Properties nach Umstellung von technischem Nutzer auf technischen Client

isy.task.tasks.halloWeltTask.oauth2ClientRegistrationId=TestClient

# [...]

spring.security.oauth2.client.provider.TestRealm.issuer-uri=http://localhost:9095/auth/realms/testrealm
spring.security.oauth2.client.registration.TestClient.client-id=test-user-client-id
spring.security.oauth2.client.registration.TestClient.client-secret=test-user-client-secret
spring.security.oauth2.client.registration.TestClient.authorization-grant-type=client_credentials
spring.security.oauth2.client.registration.TestClient.provider=TestRealm

2.5. Service

Ab IsyFact 3 ist die Verwendung von REST-Schnittstellen für die Neuentwicklung verbindlich. Spring HTTP-Invoker ist deprecated und wird ab sofort als Schnittstellenformat durch REST abgelöst. Die Verwendung von REST-Schnittstellen wird im Baustein REST (siehe Konzept REST und Nutzungsvorgaben REST) erläutert. Desweiteren wurden die Bridge-Module isy-serviceapi-core-bridge, isy-serviceapi-sst-bridge und isy-exception-sst-bridge entfernt.

Mit der Verwendung von isy-security in der IsyFact 3 wird standardmäßig anstelle von IsyFacts AufrufKontext Springs SecurityContext verwendet.

Damit dennoch alte HTTP-Invoker Schnittstellen aufgerufen werden können (welche einen gefüllten AufrufKontext benötigen), wird eine spezielle RemoteInvocationFactory eingesetzt, welche Springs SecurityContext in ein AufrufKontextTo ad hoc per Request umwandelt.

Weitere Informationen können unter Nutzungsvorgaben HTTP-Invoker nachgelesen werden.

2.6. Sicherheit

2.6.1. Konfiguration

Eine Beschreibung der Parameter findet sich in den Nutzungsvorgaben Security und der Dokumentation von Spring Security.

Tabelle 1 gibt eine Übersicht über die zu ändernden Parameter. Die instances[n] Notation aus den isy-sicherheit-keycloak Properties wird in isy-security nicht länger unterstützt. Jede Instanz soll durch eine sprechende und eindeutige registration-id ersetzt werden. Falls mehrere Instanzen für das gleiche Realm konfiguriert wurden, kann der provider-name pro Realm einmalig konfiguriert und für mehrere OAuth 2.0 Client Registrations (registration-id) wiederverwendet werden.

Falls Keycloak als Identity Provider verwendet wird, müssen für die Clients zusätzlich ein "Realm Role Mapper", der die Realm-Rollen in den in isy.security.roles-claim-name konfigurierten Claim schreibt (Default: roles), sowie ein "Audience Mapper", welcher das aud-Claim auf den Namen des verwendeten Clients setzt, konfiguriert werden.

Aus Platzgründen wurde in der ersten Spalte auf das isy.sicherheit.keycloak Präfix verzichtet. Analog wurde bei allen Properties der zweiten Spalte, die mit einem Punkt beginnen, auf das Präfix spring.security.oauth2.client verzichtet.

Tabelle 2. Änderung der Konfigurationsparameter
isy-sicherheit(-keycloak)	isy-security	Bemerkung
`.auth-server-url`	`spring.security.resourceserver.jwt.issuer-uri`	Issuer, gegen den einkommende Bearer Tokens validiert werden sollen. An den bisherigen Wert wird `/realms/<realm-name>` angehängt.
`.auth-server-url`	`.provider.<provider-name>.issuer-uri`	Für die Verwendung in Kombination mit einer Spring Client Registration. An den bisherigen Wert wird `/realms/<realm-name>` angehängt.
`.realm`	-	Entfällt, da Teil der `issuer-uri`.
-	`.registration.<registration-id>.provider`	Neu, verbindet die Spring Client Registration und Provider Definition.
`.resource`	`.registration.<registration-id>.client-id`	Neu, Authentifizierungsidentifier der ConfidentialClient-Applikation im Autorisierungsserver.
`.credentials-secret`	`.registration.<registration-id>.client-secret`	Neu, Authentifizierungs-Secret, das nur der ConfidentialClient-Anwendung und dem Autorisierungsserver bekannt ist.
-	`.registration.<registration-id>.authorization-grant-type=password`	Neu, da ein zusätzlicher OAuth Flow unterstützt wird. Der Wert `password` entspricht dem bisherigen Flow in `isy-sicherheit-keycloak`.
`.bearer-only`	-	entfällt
`.standard-zertifikat-ou`	`isy.security.oauth2.client.default-certificate-ou`
`.bhknz-header-name`	`isy.security.oauth2.client.bhknz-header-name`
-	`isy.security.oauth2.registration.<registration-id>.username`	Neu, für ConfidentialClient-Konfiguration der geänderte Pfad für Property `username`, mit isy-security nun innerhalb einer Spring konformen ClientRegistration
-	`isy.security.oauth2.registration.<registration-id>.password`	Neu, für ConfidentialClient-Konfiguration der geänderte Pfad für Property `password`, mit isy-security nun innerhalb einer Spring konformen ClientRegistration
-	`isy.security.oauth2.registration.<registration-id>.bhknz`	Neu, für ConfidentialClient-Konfiguration der geänderte Pfad für Property `bhknz`, mit isy-security nun innerhalb einer Spring konformen ClientRegistration
`.default-instance`	-	entfällt
`.ext-auth-server-url`	-	entfällt
`.expected-realm-type`	-	entfällt
`.expected-realm`	-	entfällt
`.cert-header-name`	-	entfällt
`.cert-dn-header-name`	-	entfällt

Bei der Verwendung von isy-sicherheit-keycloak wurde die Absicherung gegen CSRF-Angriffe standardmäßig deaktiviert, da dies den Zugriff auf interne REST- und HTTP-Invoker-Schnittstellen vereinfacht. Dies ist mit isy-security nicht mehr der Fall, weshalb der automatisch von Spring Security konfigurierte CSRF-Filter mglw. deaktiviert werden muss.

2.6.2. @Gesichert

Die Annotation @Gesichert wird ersetzt durch die Spring-Annotation @Secured. Analog wird die Klasse GesichertInterceptor abgelöst durch SecuredInterceptor.

@Secured akzeptiert in isy-security nur Parameter, die mit PRIV_ beginnen. Beim Abbilden von Rollen auf Rechte wird in isy-security das Präfix PRIV_ automatisch gesetzt. Dies verdeutlicht die Abgrenzung zu Rollen, für die Spring das Präfix ROLE_ verwendet.

@Gesichert("RECHT_A") muss daher geändert werden zu @Secured("PRIV_Recht_A").

Werden mehrere Rechte an die Annotation übergeben, so sind sie bei @Gesichert konjunktiv verknüpft (= alle übergebenen Rechte müssen vorhanden sein). Bei der Verwendung von @Secured sind die übergebenen Rechte hingegen disjunktiv verknüpft (= es genügt, wenn eines der Rechte vorhanden ist).

Um konjunktive Verknüpfungen auch weiterhin umzusetzen, sollte die Annotation @PreAuthorize aus Spring Security verwendet werden. @PreAuthorize ist für die Prüfung eines einzigen Rechtes äquivalent zu @Secured, nutzt aber die Spring Expression Language (SpEL).

Dadurch sind Ausdrücke möglich wie

@PreAuthorize("hasAuthority('PRIV_Recht_A') and hasAuthority('PRIV_Recht_B')")

2.6.3. Berechtigungsmanager

Im Interface Berechtigungsmanager ändern sich die Rückgabewerte der Methoden getRechte() und getRollen() zu Set<String>. Grund dafür ist, dass die POJOs Recht und Rolle abgeschafft und durch String-Werte ersetzt wurden.

2.6.4. Interface Sicherheit

Das Interface Sicherheit wird abgelöst durch das Interface Security. Folgende Änderungen sind dabei relevant:

Die Methode getBerechtigungsManagerUndAuthentifiziere() wird entfernt und durch zwei neue Methoden im Interface Security ersetzt. Die Aufgaben sind hierbei wie folgt verteilt:
- Die Methode getAuthentifizierungsmanager() liefert das Interface Authentifizierungsmanager zurück, über dessen Implementierung dann eine Authentifizierung mit dem konfigurierten OpenID Connect Provider (bspw. Keycloak) durchgeführt werden kann. Nach erfolgreicher Authentifizierung wird das Bearer Token im Spring Security Context hinterlegt (siehe Nutzungsvorgaben zu Authentifizierungsmanager).
- Die Methode getBerechtigungsmanager() liefert das Interface Berechtigungsmanager zurück, über dessen Implementierung dann auf die im Bearer Token enthaltenen Autorisierungsinformationen zugegriffen werden kann. Konkret sind in dem Interface Berechtigungsmanager Methoden definiert, über dessen Implementierung Berechtigungen und Rollen abgefragt werden können (siehe Nutzungsvorgaben isy-security).
Die Methode leereCache() entfällt.
Wie in Abschnitt Berechtigungsmanager beschrieben, ändert sich der Rückgabewerte der Methode Set<Rolle> zu Set<String>.

2.6.5. @NutzerAuthentifizierung

Die Annotation @NutzerAuthentifizierung wird entfernt und durch eine neue Annotation @Authenticate ersetzt.

Der Annotation @Authenticate wird die Client-Registration-ID eines OAuth2.0-Clients übergeben. Der entsprechende Client muss dafür gemäß den Nutzungsvorgaben Security konfiguriert sein. Hierfür werden die OAuth2ClientProperties verwendet, sodass bei der Nutzung von @Authenticate gegenüber @NutzerAuthentifizierung die Notwendigkeit für das Erstellen der NutzerAuthentifizierungProperties entfällt. Entsprechend muss allerdings die spring-security-oauth2-client-Dependency eingebunden sein.

Zusätzliche für die Aktivierung der Annotation notwendige Beans müssen nicht mehr definiert werden, da diese durch die IsyOAuth2ClientAutoConfiguration erstellt werden, solange die Gegebenheiten für die Erstellung von ClientRegistrations vorhanden sind.

Beispiel für die Konfiguration mit @NutzerAuthentifizierung:

@NutzerAuthentifizierung(benutzer = "test-benutzer")

<property-prefix>.benutzer.test-benutzer.kennung = benutzer-name
<property-prefix>.benutzer.test-benutzer.passwort = super_secret_password
<property-prefix>.benutzer.test-benutzer.bhknz = 123456

Beispiel für die Konfiguration mit @Authenticate:

@Authenticate(oauth2ClientRegistrationId = "test-client") // fest

oder

@Authenticate(oauth2ClientRegistrationId = "${test-project.client-id}") // mit Property-Platzhalter

Die Client-ID kann sowohl fest als auch in Form eines Property-Platzhalters an die Annotation gegeben werden. Beispiele für weitere Schreibweisen sind in den Nutzungsvorgaben Security zu finden.

# Property-Platzhalter
test-project.client-id = test-client

spring.security.oauth2.client.provider.testrealm.issuer-uri = http://localhost:12345/auth/realms/testrealm

spring.security.oauth2.client.registration.test-client.client-id = client-credentials-test-client
spring.security.oauth2.client.registration.test-client.client-secret = super_secret_password
spring.security.oauth2.client.registration.test-client.authorization-grant-type = client_credentials
spring.security.oauth2.client.registration.test-client.provider = testrealm

2.6.6. AccessManager und zugehörige Klassen

Das Interface AccessManager sowie zugehörige Interfaces entfallen. Genauer wurden folgende Interfaces entfernt:

de.bund.bva.isyfact.sicherheit.accessmgr.AccessManager
de.bund.bva.isyfact.sicherheit.SicherheitAdmin
de.bund.bva.isyfact.sicherheit.accessmgr.AuthentifizierungsErgebnis

2.6.7. Exceptions

Die Exceptions aus dem Paket de.bund.bva.isyfact.sicherheit.common.exception entfallen. Sie werden durch Exceptions aus Spring Security ersetzt.

Eine Ausnahme davon bildet die Exception

de.bund.bva.isyfact.sicherheit.common.exception.RollenRechteMappingException,

die ersetzt wird durch:

de.bund.bva.isyfact.security.xmlparser.RolePrivilegesMappingException

2.6.8. Mock für Testumgebungen

Der Baustein isy-security-test stellt zum Erstellen von (automatisierten) Tests einen OpenId Connect Provider Mock bereit. Dieser löst den Keycloak Mock aus isy-sicherheit-keycloak-test ab.

Die Klassen und Interfaces

de.bund.bva.isyfact.sicherheit.keycloak.test.EmbeddedKeycloakStub
de.bund.bva.isyfact.sicherheit.keycloak.test.KeycloakMockBase
de.bund.bva.isyfact.sicherheit.keycloak.test.EmbeddedKeycloakMock
de.bund.bva.isyfact.sicherheit.keycloak.test.RemoteKeycloakMock
de.bund.bva.isyfact.sicherheit.keycloak.test.RsaKeyGenerator

werden ersetzt durch:

de.bund.bva.isyfact.security.test.oidcprovider.EmbeddedOidcProviderStub
de.bund.bva.isyfact.security.test.oidcprovider.OidcProviderMockBase
de.bund.bva.isyfact.security.test.oidcprovider.EmbeddedOidcProviderMock
de.bund.bva.isyfact.security.test.oidcprovider.RemoteOidcProviderMock
de.bund.bva.isyfact.security.test.RsaKeyGenerator

Dabei haben sich die Konstruktoren, Felder und Methodensignaturen leicht geändert.

Konstruktoren

Die Konstruktoren haben keinen Parameter vom Typ RsaKeyGenerator mehr. Falls bisher ein Konstruktor verwendet wurde, der als einen der Parameter ein Objekt vom Typ RsaKeyGenerator empfängt, kann dieser Parameter bei der Umstellung gestrichen werden.
Konstruktoren, die bisher zwei Objekte vom java.security.PrivateKey und java.security.PublicKey empfangen haben, wurden zusammengefasst in einem Objekt vom Typ java.security.KeyPair.

Felder

Die Änderungen der Felder sind in den nachfolgenden Tabellen beschrieben. Die Namen der zugehörigen Getter-Methoden wurden angepasst.

Tabelle 3. Änderung der Felder in EmbeddedKeycloakMock
EmbeddedKeycloakMock (IFS 2)	EmbeddedOidcProviderMock (IFS 3)
`WireMockServer keycloakServer`	`WireMockServer oidcServerStub`

Tabelle 4. Änderung der Felder in EmbeddedKeycloakStub
EmbeddedKeycloakStub (IFS 2)	EmbeddedOidcProviderStub (IFS 3)
`String realm`	`URI issuer`

Methodensignaturen

Die Änderungen der Methodensignaturen sind in den nachfolgenden Tabellen beschrieben.

Tabelle 5. Änderung der Methodensignaturen in KeycloakMockBase
KeycloakMockBase (IFS 2)	OidcProviderMockBase (IFS 3)	Änderung
`addUser(String username, String password, String bhknz, Set<String> roles)`	`addUser(String clientId, String secret, String username, String password, Optional<String> bhknz, Set<String> roles)`	neue Parameter `String clientId` und `String secret`

Tabelle 6. Änderung der Methodensignaturen in EmbeddedKeycloakStub
EmbeddedKeycloakStub (IFS 2)	EmbeddedOidcProviderStub (IFS 3)	Änderung
`public JWK getJwk()`	`public JWKSet getJwkSet()`	geänderter Methodenname und Rückgabetyp
`public String getRealmKey()`	`public String getPublicKey()`	geänderter Methodenname
`public String getOIDCConfigResponse(String jwksEndpoint, String tokenEndpoint)`	`public String getOIDCConfigResponse(String jwksEndpoint, String authorizationEndpoint, String tokenEndpoint)`	zusätzlicher Parameter `String authorizationEndpoint`
`public AccessToken getAccessToken(UUID userId, String userName, Optional<String> bhknz, Set<String> roles)`	`public JwtClaimsSet getAccessToken(UUID userId, String clientId, String userName, Optional<String> bhknz, Set<String> roles)`	zusätzlicher Parameter `String clientId`, geänderter Rückgabetyp
`public AccessToken getAccessToken(UUID userId, String userName, Optional<String> bhknz, Set<String> roles, int newTokenLifespan)`	`public JwtClaimsSet getAccessToken(UUID userId, String clientId, String userName, Optional<String> bhknz, Set<String> roles, int newTokenLifespan)`	zusätzlicher Parameter `String clientId`, geänderter Rückgabetyp
`public String getAccessTokenString(String userName, Optional<String> bhknz, Set<String> roles)`	`public String getAccessTokenString(String clientId, String userName, Optional<String> bhknz, Set<String> roles)`	zusätzlicher Parameter `String clientId`
`public String getAccessTokenString(UUID userId, String userName, Optional<String> bhknz, Set<String> roles)`	`public String getAccessTokenString(UUID userId, String clientId, String userName, Optional<String> bhknz, Set<String> roles)`	zusätzlicher Parameter `String clientId`
`public String getAccessTokenString(AccessToken token)`	`public String getAccessTokenString(JwtClaimsSet claims)`	geänderter Parametertyp
`public String getAccessTokenResponse(String userName, Optional<String> bhknz, Set<String> roles)`	`public String getAccessTokenResponse(String clientId, String userName, Optional<String> bhknz, Set<String> roles)`	zusätzlicher Parameter `String clientId`
`public String getAccessTokenResponse(AccessToken accessToken)`	`public String getAccessTokenResponse(JwtClaimsSet claims)`	geänderter Parametertyp

2.7. Persistence

In IsyFact 3 werden DataSourceProperties von Spring Boot verwendet und lediglich um die Attribute schemaVersion und schemaInvalidVersionAction erweitert. Hierdurch haben sich die Namen der Konfigurationsschlüssel geändert und müssen angepasst werden. Details zur Konfiguration sind in den Nutzungsvorgaben Persistence zu finden.