2.4. RH-SSO 7.3
다음 변경 사항은 RH-SSO 7.2에서 RH-SSO 7.3으로 변경되었습니다.
2.4.1. 권한 부여 서비스 변경
UMA 2.0에 대한 지원이 추가되었습니다. 이 버전의 UMA 사양에는 서버에서 권한을 얻는 방법에 대한 몇 가지 중요한 변경 사항이 도입되었습니다.
UMA 2.0 지원에 의해 도입된 주요 변경 사항은 다음과 같습니다. 자세한 내용은 인증 서비스 가이드를 참조하십시오.
- 권한 부여 API가 제거됨
- UMA 2.0 (UMA 1.0) 이전에는 클라이언트 애플리케이션이 RPT 형식으로 서버에서 권한을 얻기 위해 권한 부여 API를 사용하고 있었습니다. UMA 사양의 새 버전에서는 Red Hat Single Sign-On에서도 제거된 권한 부여 API가 제거되었습니다. UMA 2.0에서 이제 특정 권한 부여 유형을 사용하여 토큰 끝점에서 RPT를 가져올 수 있습니다. 자세한 내용은 인증 서비스 가이드를 참조하십시오.
- 인타이틀먼트 API가 제거됨
- UMA 2.0이 도입되면서 토큰 끝점 및 UMA 부여 유형을 활용하여 Red Hat Single Sign-On에서 RPT를 취득하고 다른 API를 사용하지 않도록 했습니다. 인타이틀먼트 API에서 제공하는 기능은 동일하게 유지되었으며 리소스 또는 범위가 없는 경우 하나 이상의 리소스 및 범위 또는 서버에서 모든 권한에 대한 권한을 얻을 수 있습니다. 자세한 내용은 인증 서비스 가이드를 참조하십시오.
- UMA Discovery Endpoint로 변경
- UMA Discovery 문서 변경, 자세한 내용은 인증 서비스 가이드를 참조하십시오.
- Red Hat Single Sign-On 인증 JavaScript 어댑터 변경
Red Hat Single Sign-On Authorization JavaScript 어댑터(keycloak-authz.js)는 이전 버전과 동일한 동작을 유지하면서 UMA 2.0에서 도입한 변경 사항을 준수하도록 변경되었습니다. 주요 변경 사항은 권한 부여 요청을 나타내는 특정 오브젝트 유형을 예상하는
권한 부여및인타이틀먼트메서드를 모두 호출하는 방법에 관한 것입니다. 이 새로운 오브젝트 유형은 UMA 부여 유형에서 지원하는 다양한 매개변수를 지원하여 서버에서 권한을 얻는 방법에 대한 유연성을 제공합니다. 자세한 내용은 인증 서비스 가이드를 참조하십시오.One of the main changes introduced by this release is that you are no longer required to exchange access tokens with RPTs in order to access resources protected by a resource server (when not using UMA). Depending on how the policy enforcer is configured on the resource server side, you can just send regular access tokens as a bearer token and permissions will still be enforced.
- Red Hat Single Sign-On Authorization Client Java API로 변경
-
Red Hat Single Sign-On Authorization Client Java API의 새 버전으로 업그레이드할 때 일부 표현 클래스는
org.keycloak:keycloak-core의 다른 패키지로 이동되었습니다.
2.4.2. 클라이언트 템플릿이 클라이언트 범위로 변경됨
마이그레이션 중에 몇 가지 주의가 필요한 클라이언트 범위에 대한 지원이 추가되었습니다.
- 클라이언트 템플릿이 클라이언트 범위로 변경됨
- 클라이언트 템플릿이 클라이언트 범위로 변경되었습니다. 클라이언트 템플릿이 있는 경우 해당 프로토콜 매퍼 및 역할 범위 매핑이 유지됩니다.
- 이름으로 대체되는 공백
-
공백은 클라이언트 범위 이름에 허용되지 않기 때문에 이름에 공백을 밑줄로 교체하여 이름에 공백 이름이 변경되었습니다. 예를 들어,
내 템플릿이클라이언트 범위my_template으로 변경됩니다. - 클라이언트에 클라이언트 범위 연결
-
클라이언트 템플릿이 있는 클라이언트의 경우 해당 클라이언트 범위가 클라이언트에
기본 클라이언트범위로 추가됩니다. 따라서 프로토콜 매퍼 및 역할 범위 매핑은 클라이언트에 보존됩니다. - 기존 클라이언트에 연결되지 않은 영역 기본 클라이언트 범위
-
마이그레이션 중에
기본 제공 클라이언트 범위 목록과 각 영역에 추가됩니다.그러나 기존 클라이언트는 업그레이드되지 않으며 새 클라이언트 범위가 자동으로 추가되지 않습니다. 또한 모든 프로토콜 매퍼 및 역할 범위 매핑은 기존 클라이언트에 유지됩니다. 새 버전에서는 새 클라이언트를 생성할 때 이 범위가 자동으로 연결되어 있으며 프로토콜 매퍼가 연결되어 있지 않습니다. 예를 들어 클라이언트의 프로토콜 매퍼는 적절하게 탐지할 수 없으므로 마이그레이션 중에 기존 클라이언트를 변경하지 않았습니다. 기존 클라이언트(에서 프로토콜 매퍼 제거)를 업데이트하고 클라이언트 범위로 연결하려면 수동으로 수행해야 합니다. - 동의가 다시 확인되어야 합니다.
- 고객 범위를 변경하려면 동의를 리팩토링해야 합니다. 이제 역할 또는 프로토콜 매퍼가 아닌 클라이언트 범위를 가리킵니다. 이러한 변경으로 인해 이전에 확인된 사용자가 확인한 영구 동의가 더 이상 유효하지 않으며 사용자는 마이그레이션 후 동의 페이지를 다시 확인해야 합니다.
- 일부 설정 스위치 제거
-
필요한 스위치 범위 매개변수가 역할 세부 정보에서 제거되었습니다.Consent Required및Consent text스위치가 프로토콜 매퍼 세부 정보에서 제거되었습니다. 이러한 스위치는 클라이언트 범위 기능으로 교체되었습니다.
2.4.3. 새로운 기본 클라이언트 범위
새로운 영역의 기본 클라이언트 범위 역할과 웹 출처를 추가했습니다. 이러한 클라이언트 범위에는 사용자의 역할을 추가하고 웹 원본을 토큰에 허용하는 프로토콜 매퍼가 포함되어 있습니다. 마이그레이션 중에 이러한 클라이언트 범위는 모든 OpenID Connect 클라이언트에 기본 클라이언트 범위로 자동으로 추가되어야 합니다. 따라서 데이터베이스 마이그레이션이 완료된 후에는 설정이 필요하지 않습니다.
2.4.3.1. 프로토콜 매퍼 SPI 추가
이와 관련하여 (지원되지 않은) 프로토콜 Mappers SPI에는 약간의 추가 기능이 있습니다. 사용자 지정 ProtocolMapper를 구현한 경우에만 영향을 받을 수 있습니다. ProtocolMapper 인터페이스에 새로운 getPriority() 메서드가 있습니다. 이 메서드에는 0을 반환하는 기본 구현이 설정되어 있습니다. 프로토콜 매퍼 구현이 액세스 토큰 realmAccess 또는 resourceAccess 속성의 역할을 사용하는 경우 매퍼의 우선 순위를 늘려야 할 수 있습니다.
2.4.3.2. 고객 문제 해결
인증된 사용자가 토큰에 하나 이상의 클라이언트 역할을 가진 모든 클라이언트의 오디언스는 이제 액세스 토큰의 aud 클레임에 자동으로 추가됩니다. 반면 액세스 토큰은 발행된 프런트 엔드 클라이언트의 대상을 자동으로 포함하지 않을 수 있습니다. 자세한 내용은 서버 관리 가이드를 참조하십시오.
2.4.4. EAP 7.2로 업그레이드
Red Hat Single Sign-On 서버가 EAP 7.2를 기본 컨테이너로 사용하도록 업그레이드되었습니다. 여기에는 특정 Red Hat Single Sign-On 서버 기능과 직접적인 관련이 없지만 마이그레이션과 관련하여 몇 가지 변경 사항이 있습니다.
- 종속성 업데이트
- 종속 항목은 EAP 7.2 서버에서 사용하는 버전으로 업데이트되었습니다. 예를 들어 Infinispan은 이제 9.3.1.Final입니다.
- 구성 변경
-
standalone(-ha).xml및domain.xml파일에서는 몇 가지 구성 변경 사항이 있습니다. 구성 파일 마이그레이션을 자동으로 처리하려면 3.1.2절. “Red Hat Single Sign-On 서버 업그레이드” 섹션에 따라야 합니다. - 데이터 센터 복제 변경
- RHDG 서버를 버전 7.3으로 업그레이드해야 합니다. 이전 버전은 계속 작동할 수 있지만 더 이상 테스트하지 않으므로 보장되지 않습니다.
-
값이
2.6인protocolVersion속성을 Red Hat Single Sign-On 구성의remote-store요소 구성에 추가해야 합니다. 이 작업은 RHDG 7.3에서 사용하는 버전과 호환되도록 HotRod 프로토콜 버전을 다운그레이드해야 하므로 필요합니다.
2.4.5. 호스트 이름 구성
이전 버전에서는 필터를 사용하여 허용된 호스트 이름을 지정하는 것이 좋습니다. 이제 유효한 호스트 이름이 사용되는지 확인하고 내부 애플리케이션에서 대체 URL(예: 내부 IP 주소)을 통해 Red Hat Single Sign-On을 호출할 수 있도록 고정 호스트 이름을 설정할 수 있습니다. 프로덕션 환경에서 이 방법으로 전환하는 것이 좋습니다.
2.4.6. JavaScript 어댑터의 약속
JavaScript 어댑터와 함께 네이티브 JavaScript를 사용하려면 이제 init 옵션에서 commitment Type 을 네이티브 로 설정해야 합니다.
이전에는 네이티브 약속이 사용 가능한 경우 기존 Keycloak 약속과 네이티브 약속 모두를 제공하는 래퍼가 반환되었습니다. 이로 인해 오류 처리기가 기본 오류 이벤트 이전에 설정되지 않았기 때문에 문제가 발생하여 Uncaught(예: Promise) 오류가 발생했습니다.
2.4.7. Microsoft Identity Provider가 Microsoft Graph API를 사용하도록 업데이트
Red Hat Single Sign-On의 Microsoft Identity Provider 구현은 라이브 SDK 엔드포인트를 사용하여 권한 부여 및 사용자 프로필을 얻는 데 사용되었습니다. 2018년 11월 부터 Microsoft는 새로운 Microsoft Graph API를 대신하여 Live SDK API에 대한 지원을 제거하고 있습니다. Red Hat Single Sign-On ID 공급자가 새 엔드포인트를 사용하도록 업데이트되었으므로 이 통합이 사용 중인 경우 최신 Red Hat Single Sign-On 버전으로 업그레이드해야 합니다.
"라이브 SDK 애플리케이션"에 등록된 기존 클라이언트 애플리케이션은 애플리케이션의 id 형식 변경으로 인해 Microsoft Graph 엔드 포인트에서 작동하지 않습니다. 디렉터리에 애플리케이션 ID를 찾을 수 없다는 오류가 발생하면 Microsoft Application 등록 포털에 클라이언트 애플리케이션을 다시 등록하여 새 애플리케이션 ID를 가져와야 합니다.
2.4.8. Google ID 공급자가 Google Sign-in 인증 시스템을 사용하도록 업데이트
Red Hat Single Sign-On의 Google ID 공급자 구현은 Google+ API 엔드포인트를 사용하여 권한 부여 및 사용자 프로필을 가져오는 데 사용됩니다. 2019년 3월 부터 Google은 새로운 Google Sign-in 인증 시스템을 사용하기 위해 Google+ API에 대한 지원을 제거하고 있습니다. Red Hat Single Sign-On ID 공급자가 새 엔드포인트를 사용하도록 업데이트되었으므로 이 통합이 사용 중인 경우 최신 Red Hat Single Sign-On 버전으로 업그레이드해야 합니다.
디렉터리에 애플리케이션 ID를 찾을 수 없다는 오류가 발생하면 Google API 콘솔 포털에 클라이언트 애플리케이션을 다시 등록하여 새 애플리케이션 ID 및 시크릿을 가져와야 합니다.
Google+ 사용자 정보 끝점에서 제공한 비표준 클레임에 대해 사용자 지정 매퍼를 조정해야 하며 Google Sign-in API에서 다른 이름으로 제공될 수 있습니다. 사용 가능한 클레임에 대한 최신 정보는 Google 설명서를 참조하십시오.
2.4.9. CloudEventResource Broker가 NVIDIA API의 버전 2로 업데이트
이에 따라, 모든 개발자가 자신의 API 및 OAuth 2.0 버전 2.0으로 마이그레이션해야 합니다. 이에 따라, 당사는 NVIDIA social Broker를 업데이트했습니다.
이 브로커를 사용하는 기존 배포에서는 iPXE API 버전 2를 사용하여 사용자 프로필을 가져올 때 오류가 발생할 수 있습니다. 이 오류는 프로필 API에 액세스할 수 없거나 인증 프로세스 중에 특정 OAuth2 범위를 요청할 수 없는 브로커를 구성하는 데 사용되는 클라이언트 애플리케이션에 부여된 권한 부족과 관련이 있을 수 있습니다.
새로 생성된 iPXE 클라이언트 애플리케이션의 경우에도 클라이언트가 r_liteprofile 및 r_emailaddress OAuth2 범위를 요청할 수 있고 클라이언트 애플리케이션이 https://api.linkedin.com/v2/me 끝점에서 현재 멤버의 프로필을 가져올 수 있는지 확인해야 합니다.
이러한 개인 정보 보호 제한으로 인해 멤버의 정보에 대한 액세스 및 현재 멤버의 프로필 API에서 반환한 제한된 클레임 세트와 관련된 이러한 개인 정보 보호 제한으로 인해, 현재 Link Broker는 멤버의 이메일 주소를 기본 사용자 이름으로 사용하고 있습니다. 즉, 인증 중에 권한 부여 요청을 보낼 때 r_emailaddress 가 항상 설정됩니다.
