Red Hat Summit7.12. 이전 사용자 페더레이션 SPI에서 마이그레이션
이 장은 이전 (및 현재 사용자 페더레이션 SPI)을 사용하여 공급자를 구현 한 경우에만 적용됩니다.
Keycloak 버전 2.4.0 및 이전 버전에는 사용자 페더레이션 SPI가 있었습니다. Red Hat Single Sign-On 버전 7.0은 지원되지 않지만 이전 SPI도 사용할 수 있었습니다. 이전 사용자 페더레이션 SPI는 Keycloak 버전 2.5.0 및 Red Hat Single Sign-On 버전 7.1에서 제거되었습니다. 그러나 이 이전 SPI를 사용하여 공급자를 작성한 경우 이 장에서는 이 공급자를 포트하는 데 사용할 수 있는 몇 가지 전략에 대해 설명합니다.
7.12.1. 가져오기 대 비 가져오기
이전 사용자 페더레이션 SPI는 Red Hat Single Sign-On의 데이터베이스에서 사용자의 로컬 사본을 생성하고 외부 저장소에서 로컬 사본으로 정보를 가져와야 했습니다. 그러나 이는 더 이상 요구 사항이 아닙니다. 이전 공급자를 그대로 이식할 수 있지만 중요하지 않은 전략이 더 나은 접근 방식이 될 수 있는지 고려해야 합니다.
가져오기 전략의 장점은 다음과 같습니다.
- Red Hat Single Sign-On은 기본적으로 외부 저장소의 지속성 사용자 캐시가 됩니다. 사용자를 가져오면 더 이상 외부 저장소에 충돌하지 않으므로 로드를 해제합니다.
- 공식 사용자 저장소로 Red Hat Single Sign-On으로 이동하여 이전 외부 저장소를 사용 중단하는 경우 Red Hat Single Sign-On을 사용하도록 애플리케이션을 천천히 마이그레이션할 수 있습니다. 모든 애플리케이션이 마이그레이션되면 가져온 사용자를 분리하고 이전의 레거시 외부 저장소를 고집합니다.
가져오기 전략을 사용하는 데는 몇 가지 명확한 문제가 있습니다.
- 처음 사용자를 찾으려면 Red Hat Single Sign-On 데이터베이스에 대한 여러 업데이트가 필요합니다. 이는 부하가 크게 저하될 수 있으며 Red Hat Single Sign-On 데이터베이스에 많은 부담을 줄 수 있습니다. 사용자 페더레이션 스토리지 접근 방식은 필요에 따라 추가 데이터만 저장하고 외부 저장소의 기능에 따라 사용하지 않을 수 있습니다.
- 가져오기 접근 방식을 사용하면 로컬 Red Hat Single Sign-On 스토리지와 외부 스토리지를 동기화해야 합니다. User Storage SPI에는 동기화를 지원하기 위해 구현할 수 있는 기능 인터페이스가 있지만 이로 인해 번거롭고 혼란스러울 수 있습니다.
7.12.2. UserFederationProvider versus UserStorageProvider
가장 먼저 눈에 띄는 것은 UserFederationProvider 가 완전한 인터페이스라는 것입니다. 이 인터페이스의 모든 메서드를 구현했습니다. 그러나 UserStorageProvider 는 필요에 따라 이 인터페이스를 구현하는 여러 기능 인터페이스로 분류했습니다.
UserFederationProvider.getUserByUsername() 및 getUserByEmail() 은 새 SPI에 정확히 동등한 값을 갖습니다. 이 둘의 차이점은 어떻게 가져오는가입니다. 가져오기 전략을 계속 진행하려는 경우 더 이상 KeycloakSession.userStorage().addUser() 를 호출하여 로컬로 사용자를 생성하지 않습니다. Instead you call KeycloakSession.userLocalStorage().addUser(). userStorage() 메서드가 더 이상 존재하지 않습니다.
UserFederationProvider.validateAndProxy() 메서드가 선택적 기능 인터페이스 ImportedUserValidation 로 이동되었습니다. 이전 공급자를 그대로 이식하는 경우 이 인터페이스를 구현하려고 합니다. 또한 이전 SPI에서는 로컬 사용자가 캐시에 있는 경우에도 이 방법을 사용자가 액세스할 때마다 호출됩니다. 이후 SPI에서 이 방법은 로컬 사용자가 로컬 저장소에서 로드될 때만 호출됩니다. 로컬 사용자가 캐시되면 ImportedUserValidation.validate() 메서드를 전혀 호출하지 않습니다.
UserFederationProvider.isValid() 메서드는 이후 SPI에 더 이상 존재하지 않습니다.
UserFederationProvider 메서드는 synchronizeRegistrations (), registerUser() 및 removeUser() 가 UserRegistrationProvider 기능 인터페이스로 이동되었습니다. 이 새 인터페이스는 구현에 선택 사항이므로 공급자에서 사용자 생성 및 제거를 지원하지 않으면 구현할 필요가 없습니다. 이전 공급자가 새 사용자 등록 지원을 토글하도록 전환한 경우 새 SPI에서 지원되는 경우 공급자가 사용자 추가를 지원하지 않는 경우 UserRegistrationProvider.addUser() 에서 null 을 반환합니다.
인증 정보를 중심으로 하는 이전 UserFederationProvider 메서드가 CredentialInputValidator 및 CredentialInputUpdater 인터페이스에 캡슐화되며 인증 정보 유효성 확인 또는 업데이트를 지원하는 경우에 따라 구현할 수도 있습니다. UserModel 메서드에 존재하는 데 사용되는 인증 정보 관리. 또한 CredentialInputValidator 및 CredentialInputUpdater 인터페이스로 이동되었습니다. 한 가지 사항은 CredentialInputUpdater 인터페이스를 구현하지 않으면 Red Hat Single Sign-On 스토리지에서 로컬로 공급자에게 제공되는 모든 인증 정보를 재정의할 수 있습니다. 인증 정보를 읽기 전용으로 만들려면 CredentialInputUpdater.updateCredential() 메서드를 구현하고 ReadOnlyException 을 반환합니다.
UserFederationProvider 쿼리 메서드(예: searchByAttributes() 및 getGroupMembers ())는 이제 선택적 인터페이스 UserQueryProvider 로 캡슐화됩니다. 이 인터페이스를 구현하지 않으면 관리 콘솔에서 사용자를 볼 수 없습니다. 그러나 로그인할 수 있습니다.
7.12.3. UserFederationProviderFactory versus UserStorageProviderFactory
이전 SPI의 동기화 방법은 이제 선택적 ImportSynchronization 인터페이스 내에 캡슐화됩니다. 동기화 논리를 구현한 경우 새 UserStorageProviderFactory 가 ImportSynchronization 인터페이스를 구현하도록 합니다.
7.12.4. 새 모델로 업그레이드
User Storage SPI 인스턴스는 다른 관계형 테이블에 저장됩니다. Red Hat Single Sign-On은 마이그레이션 스크립트를 자동으로 실행합니다. 이전 사용자 페더레이션 공급자가 영역을 위해 배포되는 경우 데이터의 ID를 포함하여 이후 스토리지 모델로 변환됩니다. 이 마이그레이션은 사용자 스토리지 공급자가 이전 사용자 페더 공급자와 동일한 공급자 ID(예: "ldap", "kerberos")인 경우에만 발생합니다.
이를 알고 있는 경우 다양한 접근 방식을 취할 수 있습니다.
- 이전 Red Hat Single Sign-On 배포에서 이전 공급자를 제거할 수 있습니다. 이렇게 하면 가져온 모든 사용자의 로컬 링크 사본이 제거됩니다. 그런 다음 Red Hat Single Sign-On을 업그레이드할 때 해당 영역에 대한 새 공급자를 배포하고 구성하십시오.
-
두 번째 옵션은 새 공급자를 작성하여 새 공급자 ID:
UserStorageProviderFactory.getId()가 있는지 확인하는 것입니다. 이 공급자가 서버에 배포되었는지 확인합니다. 서버를 부팅하고 기본 제공 마이그레이션 스크립트가 이전 데이터 모델에서 이후 데이터 모델로 변환되도록 합니다. 이 경우 이전에 연결된 모든 사용자가 작동하고 동일합니다.
가져오기 전략을 제거하고 사용자 스토리지 공급자를 다시 작성하려면 Red Hat Single Sign-On을 업그레이드하기 전에 이전 공급자를 제거하는 것이 좋습니다. 이렇게 하면 가져온 사용자의 연결된 로컬 가져오기 사본이 제거됩니다.
