서버 관리 가이드

모든 UI 화면은 Red Hat Single Sign-On에서 국제화됩니다. 기본 언어는 영어이지만 지원할 로케일과 기본 로케일을 선택할 수 있습니다.

다음에 사용자가 로그인하면 해당 사용자는 로그인 화면, 계정 콘솔 및 관리 콘솔에 사용할 로그인 페이지에서 언어를 선택할 수 있습니다.

로케일 선택기 공급자는 사용 가능한 정보에 가장 적합한 로케일을 제안합니다. 그러나 사용자가 누구인지는 종종 알 수 없습니다. 이러한 이유로 이전에 인증된 사용자의 로케일이 영구 쿠키로 기억됩니다.

로케일 선택 논리는 사용 가능한 다음 중 첫 번째를 사용합니다.

사용자가 인증되면 앞서 언급한 영구 쿠키의 로케일을 업데이트하는 작업이 트리거됩니다. 사용자가 로그인 페이지에서 로케일 선택기를 통해 로케일을 적극적으로 전환한 경우 이 시점에서 사용자 로케일도 업데이트됩니다.

로케일 선택을 위한 논리를 변경하려면 사용자 지정 LocaleSelectorProvider 를 만드는 옵션이 있습니다. 자세한 내용은 서버 개발자 가이드를 참조하십시오.

Forgot Password 를 활성화하면 암호를 잊어 버렸거나 OTP 생성기가 손실되면 로그인 자격 증명을 재설정할 수 있습니다.

이메일로 전송된 텍스트는 구성할 수 있습니다. 자세한 내용은 서버 개발자 가이드를 참조하십시오.

이메일 링크를 클릭하면 Red Hat Single Sign-On에서 암호를 업데이트할 것을 요청하고 OTP 생성기를 설정한 경우 Red Hat Single Sign-On은 OTP 생성기를 재구성하도록 요청합니다. 조직의 보안 요구 사항에 따라 사용자가 이메일을 통해 OTP 생성기를 재설정하는 것을 원하지 않을 수 있습니다.

이 동작을 변경하려면 다음 단계를 수행합니다.

브라우저를 닫는 로그인한 사용자는 세션을 제거하며 해당 사용자는 다시 로그인해야 합니다. 로그인시 Remember Me 확인란을 클릭하면 해당 사용자가 사용자의 로그인 세션을 열린 상태로 유지하도록 Red Hat Single Sign-On을 설정할 수 있습니다. 이 작업은 로그인 쿠키를 세션 전용 쿠키에서 지속성 쿠키로 설정합니다.

이 설정을 저장하면 영역의 로그인 페이지에 내 확인란이 표시됩니다.

영역의 로그인 설정에서 LoA(Level of Authentication)에 매핑되는 ACR(Authentication Context Class Reference ) 값을 정의할 수 있습니다. ACR은 임의의 값일 수 있는 반면 LOA는 숫자여야 합니다. acr 클레임은 OIDC 요청에 전송된 claim 또는 acr_values 매개변수에서 요청할 수 있으며 액세스 토큰 및 ID 토큰에도 포함됩니다. 매핑된 수는 인증 흐름 조건에 사용됩니다.

특정 클라이언트가 영역과 다른 값을 사용해야 하는 경우 클라이언트 수준에서 매핑을 지정할 수도 있습니다. 그러나 가장 좋은 방법은 영역 매핑을 유지하는 것입니다.

자세한 내용은 단계별 인증 및 offical OIDC 사양을 참조하십시오.

정기적으로 키를 교체하는 것이 좋습니다. 먼저 기존 활성 키보다 우선 순위가 높은 새 키를 만듭니다. 대신 동일한 우선 순위로 새 키를 생성하고 이전 키를 수동 설정할 수 있습니다.

새 키를 사용할 수 있게 되면 모든 새 토큰과 쿠키가 새 키로 서명됩니다. 사용자가 애플리케이션에 인증하면 SSO 쿠키가 새 서명으로 업데이트됩니다. OpenID Connect 토큰이 새로 고쳐지면 새 토큰이 새 키로 서명됩니다. 결국 모든 쿠키와 토큰은 새 키를 사용하며 잠시 후 이전 키를 제거할 수 있습니다.

이전 키를 삭제하는 빈도는 보안의 장단점이며 모든 쿠키와 토큰이 업데이트되었는지 확인합니다. 새 키를 생성한 후 3~6개월마다 새 키를 생성하고 이전 키를 2개월 후에 삭제하는 것이 좋습니다. 사용자가 추가되는 새 키와 이전 키 사이의 기간에 비활성 상태인 경우 해당 사용자는 다시 인증해야 합니다.

회전 키는 오프라인 토큰에도 적용됩니다. 애플리케이션이 업데이트되도록 하려면 이전 키를 제거하기 전에 토큰을 새로 고쳐야 합니다.

이 절차를 사용하여 자체 서명된 인증서를 포함하여 키 쌍을 생성합니다.

공급자의 우선 순위를 변경하면 키가 다시 생성되지 않지만 키 크기를 변경하려면 공급자를 편집할 수 있으며 새 키가 생성됩니다.

RSA 생성된 키 쌍에서 인증서를 추출하고 새 키 저장소에서 해당 인증서를 사용하여 키를 회전할 수 있습니다.

다른 위치에서 가져온 키 쌍 및 인증서를 추가하려면 Provider 를 선택하고 드롭다운에서 rsa 를 선택합니다. 새 키 쌍이 활성 키 쌍이 되도록 우선 순위를 변경할 수 있습니다.

호스트의 Java 키 저장소 파일에 저장된 키 쌍과 인증서를 추가하려면 드롭다운에서 java-keystore 를 선택합니다. 새 키 쌍이 활성 키 쌍이 되도록 우선 순위를 변경할 수 있습니다.

연결된 인증서 체인을 로드하려면 키 쌍을 로드하는 데 사용되는 것과 동일한 키 별칭이 있는 Java 키 저장소 파일로 가져와야 합니다.

Red Hat Single Sign-On에는 서명 키가 로컬에 저장되고 클라이언트 애플리케이션, 사용자 또는 기타 엔티티와 공유되지 않습니다. 그러나 영역 서명 키가 손상되었다고 생각되면 먼저 위에 설명된 대로 새 키 쌍을 생성한 다음 손상된 키 쌍을 즉시 제거해야 합니다.

또는 공급자 테이블에서 공급자를 삭제할 수 있습니다.

not-before 정책을 내보내면 클라이언트 애플리케이션이 손상된 키로 서명된 기존 토큰을 허용하지 않습니다. 클라이언트 애플리케이션은 Red Hat Single Sign-On에서 새 키 쌍을 다운로드해야 하므로 손상된 키로 서명된 토큰이 유효하지 않습니다.

Red Hat Single Sign-On은 LDAP의 사용자를 로컬 Red Hat Single Sign-On 사용자 데이터베이스로 가져옵니다. 이 사용자 데이터베이스 복사본은 온 디맨드 또는 주기적 백그라운드 작업을 통해 동기화됩니다. 암호를 동기화하기 위한 예외가 있습니다. Red Hat Single Sign-On은 암호를 가져오지 않습니다. 암호 유효성 검사는 항상 LDAP 서버에서 수행됩니다.

동기화의 장점은 필요한 추가 사용자별 데이터가 로컬에 저장되므로 모든 Red Hat Single Sign-On 기능이 효율적으로 작동할 수 있다는 점입니다. 단점은 Red Hat Single Sign-On이 특정 사용자를 처음 쿼리할 때마다 Red Hat Single Sign-On이 해당 데이터베이스 삽입을 수행한다는 것입니다.

LDAP 서버와 가져오기를 동기화할 수 있습니다. LDAP 매퍼가 데이터베이스 대신 LDAP에서 특정 속성을 항상 읽으면 가져오기 동기화가 필요하지 않습니다.

사용자를 Red Hat Single Sign-On 사용자 데이터베이스로 가져오지 않고 Red Hat Single Sign-On에서 LDAP를 사용할 수 있습니다. LDAP 서버는 Red Hat Single Sign-On 런타임에서 사용하는 공통 사용자 모델을 백업합니다. LDAP에서 Red Hat Single Sign-On 기능에 필요한 데이터를 지원하지 않는 경우 해당 기능이 작동하지 않습니다. 이 접근 방식의 장점은 LDAP 사용자의 사본을 가져오고 Red Hat Single Sign-On 사용자 데이터베이스에 동기화하는 리소스 사용량이 없다는 것입니다.

LDAP 구성 페이지의 사용자 가져오기 스위치는 이 스토리지 모드를 제어합니다. 사용자를 가져오려면 이 스위치를 ON 으로 전환합니다.

사용자와 관리자는 Admin Console을 통해 사용자 메타데이터, 계정 콘솔을 통한 사용자 및 관리자를 수정할 수 있습니다. LDAP 구성 페이지의 Edit Mode 구성은 사용자의 LDAP 업데이트 권한을 정의합니다.

LDAP 저장소에 대한 보안 연결 URL(예:ldaps://myhost.com:636)을 구성하는 경우 Red Hat Single Sign-On은 SSL을 사용하여 LDAP 서버와 통신합니다. Red Hat Single Sign-On이 LDAP에 대한 SSL 연결을 신뢰할 수 있도록 Red Hat Single Sign-On 서버 측에서 신뢰 저장소를 구성합니다.

신뢰할 수 있는 SPI를 사용하여 Red Hat Single Sign-On의 글로벌 신뢰 저장소를 구성합니다. 글로벌 신뢰 저장소를 구성하는 방법에 대한 자세한 내용은 서버 설치 및 구성 가이드를 참조하십시오. 신뢰 저장소 SPI를 구성하지 않으면 신뢰 저장소는 Java에서 제공하는 기본 메커니즘으로 대체되며, 이 메커니즘은 javax.net.ssl.trustStore 시스템 속성 또는 시스템 속성이 설정되지 않은 경우 JDK의 cacerts 파일일 수 있습니다.

LDAP 페더레이션 공급자 구성의 Use Truststore SPI 구성 속성은 신뢰 저장소(SPI)를 제어합니다. 기본적으로 Red Hat Single Sign-On은 대부분의 배포에 적합한 ldaps의 속성을 로 설정합니다. Red Hat Single Sign-On은 LDAP에 대한 연결 URL이 ldaps 로만 시작하는 경우 Truststore SPI를 사용합니다.

사용자 가져오기 옵션을 설정하면 LDAP 공급자가 Red Hat Single Sign-On 로컬 데이터베이스로 LDAP 사용자 가져오기를 처리합니다. 사용자가 처음 로그인할 때 LDAP 공급자는 LDAP 사용자를 Red Hat Single Sign-On 데이터베이스로 가져와서 LDAP 암호를 검증합니다. 사용자가 처음 로그인하면 Red Hat Single Sign-On이 사용자를 가져오는 유일한 시간입니다. Admin Console에서 Users 메뉴를 클릭하고 모든 사용자 보기 버튼을 클릭하면 Red Hat Single Sign-On으로 한 번 이상 인증된 LDAP 사용자만 표시됩니다. Red Hat Single Sign-On은 사용자를 이러한 방식으로 가져오기 때문에 이 작업으로 전체 LDAP 사용자 데이터베이스를 가져오지 않습니다.

모든 LDAP 사용자를 Red Hat Single Sign-On 데이터베이스에 동기화하려면 LDAP 공급자 구성 페이지에서 동기화 설정을 구성하고 활성화합니다.

두 가지 유형의 동기화가 있습니다.

동기화하는 가장 좋은 방법은 LDAP 공급자를 처음 생성할 때 모든 사용자 동기화 를 클릭한 다음 변경된 사용자의 주기적 동기화를 설정하는 것입니다.

LDAP 매퍼는 LDAP 공급자가 트리거하는 리스너 입니다. LDAP 통합을 위한 또 다른 확장 지점을 제공합니다. LDAP 매퍼는 다음과 같은 경우 트리거됩니다.

LDAP 페더레이션 공급자를 생성하면 Red Hat Single Sign-On에서 이 공급자 의 매퍼 세트를 자동으로 제공합니다. 이 세트는 사용자가 매퍼를 개발하거나 기존 항목을 업데이트/삭제할 수도 있습니다.

사용자 이름, firstname, lastname, email과 같은 기본 Red Hat Single Sign-On 사용자 속성을 해당 LDAP 속성에 매핑하는 사용자 속성 매퍼입니다. 이러한 항목을 확장하고 추가 속성 매핑을 제공할 수 있습니다. 관리 콘솔은 해당 매퍼를 구성하는 데 도움이 되는 툴팁을 제공합니다.

Red Hat Single Sign-On에서 암호를 업데이트하면 Red Hat Single Sign-On에서 일반 텍스트 형식으로 암호를 보냅니다. 이 작업은 기본 제공 Red Hat Single Sign-On 데이터베이스의 암호를 업데이트하는 것과 다릅니다. 여기서 Red Hat Single Sign-On 해시 및 암호를 데이터베이스로 보내기 전에 암호를 압축합니다. LDAP의 경우 Red Hat Single Sign-On은 LDAP 서버를 사용하여 암호를 해시하고 해석합니다.

기본적으로 MSAD, RHDS 또는 FreeIPA 해시 및 압축 암호와 같은 LDAP 서버입니다. RFC3062 에 설명된 대로 LDAPv3 Password Modify Extended Operation 을 사용하지 않는 한 OpenLDAP 또는 ApacheDS와 같은 기타 LDAP 서버는 암호를 일반 텍스트로 저장합니다. LDAP 구성 페이지에서 LDAPv3 Password Modify Extended Operation을 활성화합니다. 자세한 내용은 LDAP 서버 설명서를 참조하십시오.

org.keycloak.storage.ldap 범주의 TRACE로 로깅 수준을 높이는 것이 유용합니다. 이 설정을 사용하면 LDAP 서버에 대한 모든 쿼리에 대한 로깅 로깅 및 쿼리를 보내는 데 사용된 매개 변수를 포함하여 많은 로깅 메시지가 TRACE 수준에 서버 로그에 전송됩니다. 사용자 포럼 또는 JIRA에 LDAP 질문을 생성할 때 활성화된 TRACE 로깅으로 서버 로그를 연결하는 것이 좋습니다. 이 방법이 너무 크면 작업 중에 로그에 추가된 메시지와 함께 서버 로그의 스니펫만 포함하는 것이 좋습니다. 이로 인해 문제가 발생합니다.

Creating new LDAP Store for the LDAP storage provider: ...

LDAP 공급자의 구성이 표시됩니다. 질문을 하거나 버그를 보고하기 전에 이 메시지를 포함하여 LDAP 구성을 표시하는 것이 좋습니다. 결국 일부 자리 표시자 값으로 포함하지 않는 일부 구성 변경 사항을 자유롭게 교체할 수 있습니다. 한 예로 bindDn=some-placeholder 가 있습니다. connectionUrl 의 경우 자유롭게 교체할 수 있지만 일반적으로 사용되는 프로토콜(ldap vs ldaps)을 포함하는 것이 유용합니다. 마찬가지로 DEBUG 수준에서 다음과 같이 메시지와 함께 표시되는 LDAP 매퍼 구성에 대한 세부 정보를 포함하는 것이 유용할 수 있습니다.

Mapper for provider: XXX, Mapper name: YYY, Provider: ZZZ ...

이러한 메시지는 DEBUG 로깅이 활성화된 경우에만 표시됩니다.

성능 또는 연결 풀링 문제를 추적하려면 LDAP 공급자의 연결 풀 디버그 수준 속성 값을 all 값으로 설정하는 것이 좋습니다. 그러면 LDAP 연결 풀링에 포함된 로깅을 사용하여 서버 로그에 많은 추가 메시지가 추가됩니다. 이는 연결 풀링 또는 성능과 관련된 문제를 추적하는 데 사용할 수 있습니다.

서버를 다시 시작한 후에도 연결 풀링에 대한 메시지가 더 이상 나타나지 않으면 LDAP 서버에서 연결 풀링이 작동하지 않음을 나타낼 수 있습니다.

LDAP 문제를 보고하는 경우 LDAP 트리의 일부를 대상 데이터에 첨부하여 환경에 문제가 발생할 수 있습니다. 예를 들어 일부 사용자의 로그인에 시간이 오래 걸리는 경우 다양한 "group" 항목의 멤버 속성 수를 보여주는 LDAP 항목을 연결하는 것이 좋습니다. 이 경우 Red Hat Single Sign-On의 일부 그룹 LDAP 매퍼(또는 Role LDAP Mapper)에 매핑된 그룹 항목을 추가하는 것이 유용할 수 있습니다.

FreeIPA Docker 이미지는 Docker Hub에서 사용할 수 있습니다. FreeIPA 서버를 설정하려면 FreeIPA 문서를 참조하십시오.

페더레이션 공급자는 D-BUS를 사용하여 SSSD에서 데이터를 가져옵니다. PAM을 사용하여 데이터를 인증합니다.

Red Hat Single Sign-On은 DBus-Java를 사용하여 D-Bus와 낮은 수준으로 통신합니다. D-Bus는 Unix 소켓 라이브러리에 따라 다릅니다.

SSSD 페더레이션 공급자를 활성화하기 전에 이 라이브러리의 RPM을 설치합니다.

$ sudo yum install rh-sso7-libunix-dbus-java

Red Hat Single Sign-On은 JNA를 사용하여 PAM에 인증합니다. JAN 패키지가 설치되어 있는지 확인합니다.

$ sudo yum install jna

sssctl user-checks 명령을 사용하여 설정을 검증합니다.

  $ sudo sssctl user-checks admin -s keycloak

사용자에게 암호가 없거나 암호가 삭제된 경우 Set Password 섹션이 표시됩니다.

사용자에게 이미 암호가 있는 경우 Reset Password (암호 재설정) 섹션에서 재설정할 수 있습니다.

해당 영역에서 OTP가 조건부인 경우 사용자는 Red Hat Single Sign-On 계정 콘솔로 이동하여 새 OTP 생성기를 재구성해야 합니다. OTP가 필요한 경우 사용자는 로그인할 때 새 OTP 생성기를 재구성해야 합니다.

또는 사용자가 OTP 생성기를 재설정하도록 요청하는 이메일을 사용자에게 보낼 수 있습니다. 다음 절차는 사용자에게 OTP 인증 정보가 이미 있는 경우에도 적용됩니다.

사용자가 직접 등록할 수 있도록 합니다.

이 설정을 활성화하면 Admin Console의 로그인 페이지에 Register 링크가 표시됩니다.

새 사용자는 처음으로 로그인하려면 등록 양식을 작성해야 합니다. 등록할 프로필 정보와 암호를 추가합니다.

모든 사용자에게 필요한 작업을 설정할 수 있습니다.

모든 새 사용자를 처음 로그인하기 전에 필요한 작업을 지정할 수 있습니다. 요구 사항은 사용자 페이지의 사용자 추가 버튼을 통해 생성된 사용자 또는 로그인 페이지의 등록 링크에 적용됩니다.

Red Hat Single Sign-On에 처음 로그인하기 전에 새 사용자가 약관을 수락해야 하는 필수 조치를 활성화할 수 있습니다.

필수 작업 탭에서 이 기능을 활성화합니다.

특정 사용자에게 계정을 삭제할 수 있는 역할을 제공할 수 있습니다.

delete-account 역할이 있으면 자체 계정을 삭제할 수 있습니다.

declarative_user_profile 기능을 활성화하는 것 외에도 영역에 대해 User Profile을 활성화해야 합니다. 이렇게 하려면 왼쪽 메뉴에서 CloudEvent Settings 링크를 클릭하고 User Profile Enabled 스위치를 켭니다.

활성화한 후 저장 버튼을 클릭하면 사용자 속성에 대한 구성을 관리할 수 있는 위치에서 User Profile (사용자 프로필) 탭에 액세스할 수 있습니다.

영역의 사용자 프로필을 활성화하면 Red Hat Single Sign-On은 사용자 프로필 구성에 따라 속성을 관리하는 방법에 대한 추가 제약 조건이 적용됩니다. 요약하면 이 기능이 활성화될 때 예상되는 사항 목록은 다음과 같습니다.

다음 주제에서는 사용자 프로필 구성을 관리하는 방법과 해당 구성이 귀하의 영역에 미치는 영향에 대해 살펴보겠습니다.

사용자 프로필 구성은 실제 기준으로 관리됩니다. 이를 위해 왼쪽 메뉴에서 CloudEvent Settings 링크를 클릭한 다음 User Profile 탭을 클릭합니다.

특성 하위 탭에는 현재 사용자 프로필과 연결된 속성 목록이 있습니다. 기본적으로 구성은 사용자 루트 속성을 기반으로 생성되며 각 속성은 검증 및 권한 부여 측면에서 몇 가지 기본값으로 구성됩니다.

특성 그룹 하위 탭에서 특성 그룹을 관리할 수 있습니다. 특성 그룹을 사용하면 사용자가 폼을 렌더링할 때 속성의 상관 관계를 조정할 수 있습니다.An attribute group allows you to correlate attributes so that they are displayed together when rendering user facet forms.

JSON 편집기 하위 탭에서는 잘 정의된 JSON 스키마를 사용하여 구성을 보고 편집할 수 있습니다. 다른 탭에서 변경한 내용은 이 탭에 표시된 JSON 구성에 반영됩니다.

다음 섹션에서는 특성 하위 탭에서 구성을 관리하는 방법을 알아봅니다.

특성 하위 탭에서 사용자 프로필과 연결된 특성을 생성, 편집 및 삭제할 수 있습니다.

새 속성을 정의하고 사용자 프로필과 연결하려면 속성 목록의 오른쪽 상단에 있는 만들기 버튼을 클릭합니다.

특성을 구성할 때 다음 설정을 정의할 수 있습니다.

특성 그룹 하위 탭에서 특성 그룹을 생성, 편집 및 삭제할 수 있습니다. 특성 그룹을 사용하면 사용자 쪽 양식에서 함께 렌더링되도록 관련 속성의 컨테이너를 정의할 수 있습니다.

새 그룹을 만들려면 속성 그룹 목록의 오른쪽 상단에 있는 만들기 버튼을 클릭합니다.

그룹을 구성할 때 다음 설정을 정의할 수 있습니다.

사용자 프로필 구성은 잘 정의된 JSON 스키마를 사용하여 저장됩니다. JSON 편집기 하위 탭을 클릭하여 사용자 프로필 구성을 직접 편집하도록 선택할 수 있습니다.

JSON 스키마는 다음과 같이 정의됩니다.

{
  "attributes": [
    {
      "name": "myattribute",
      "required": {
        "roles": [ "user", "admin" ],
        "scopes": [ "foo", "bar" ]
      },
      "permissions": {
        "view": [ "admin", "user" ],
        "edit": [ "admin", "user" ]
      },
      "validations": {
        "email": {},
        "length": {
          "max": 255
        }
      },
      "annotations": {
        "myannotation": "myannotation-value"
      }
    }
  ],
  "groups": [
    {
      "name": "personalInfo",
      "displayHeader": "Personal Information"
    }
  ]
}

스키마는 필요한 만큼의 속성을 지원합니다.

각 속성에 대해 필요한,권한 및 주석 설정을 선택적으로 정의해야 합니다.

{
  "attributes": [
    {
      "name": "myattribute",
      "required": {}
  ]
}

{
  "attributes": [
    {
      "name": "myattribute",
      "required": {
        "roles": ["user"]
      }
  ]
}

{
  "attributes": [
    {
      "name": "myattribute",
      "required": {
        "scopes": ["foo"]
      }
  ]
}

{
  "attributes": [
    {
      "name": "myattribute",
      "permissions": {
        "view": ["admin"],
        "edit": ["user"]
      }
  ]
}

{
  "attributes": [
    {
      "name": "myattribute",
      "annotations": {
        "foo": ["foo-value"],
        "bar": ["bar-value"]
      }
  ]
}

User Profile의 주요 기능 중 하나는 속성 메타데이터에 따라 사용자용 양식을 동적으로 렌더링할 수 있다는 점입니다. 영역에 기능이 활성화되면 등록 및 업데이트 프로필과 같은 양식이 특정 topic 템플릿을 사용하여 렌더링되어 사용자 프로필 구성을 기반으로 페이지를 동적으로 렌더링합니다.

즉, 기본 렌더링 메커니즘이 요구 사항에 적합한 경우 템플릿을 전혀 사용자 지정할 필요가 없습니다. 여전히 이러한 문제에 대한 사용자 지정이 필요한 경우 다음을 확인해야 하는 템플릿은 다음과 같습니다.

기본 렌더링 메커니즘은 다음과 같은 기능을 제공합니다.

"attributes": [
...
{
  "name": "jobTitle",
  "validations": {
    "options": {
      "options":[
        "sweng",
        "swarch"
      ]
    }
  },
  "annotations": {
    "inputType": "select",
    "inputOptionLabels": {
      "sweng": "Software Engineer",
      "swarch": "Software Architect"
    }
  }
}
...
]

"attributes": [
...
{
  "name": "jobTitle",
  "validations": {
    "options": {
      "options":[
        "sweng",
        "swarch"
      ]
    }
  },
  "annotations": {
    "inputType": "select-radiobuttons",
    "inputOptionLabels": {
      "sweng": "${jobtitle.swengineer}",
      "swarch": "${jobtitle.swarchitect}"
    }
  }
}
...
]

사용자 프로필이 구성을 준수하도록 하려면 관리자는 VerifyProfile 필수 조치를 사용하여 결국 사용자가 Red Hat Single Sign-On에 인증할 때 프로필을 업데이트하도록 할 수 있습니다.

활성화되면 사용자가 인증할 때 VerifyProfile 작업이 다음 단계를 수행합니다.

기본적으로 VerifyProfile 작업이 비활성화됩니다. 활성화하려면 왼쪽 메뉴에서 Authentication 링크를 클릭한 다음 Required Actions 탭을 클릭합니다. 이 탭에서 Register 버튼을 클릭하고 VerifyProfile 작업을 선택합니다.

영역에 User Profile 기능을 활성화하기 전에 알아야 할 몇 가지 중요한 고려 사항이 있습니다. 특성 메타데이터를 관리할 수 있는 단일 환경을 제공하므로 이 기능은 사용자에게 설정할 수 있는 속성과 관리 방법에 대해 매우 엄격한 기능입니다.

사용자 관리 측면에서 관리자는 사용자 프로필 구성에 정의된 속성만 관리할 수 있습니다. 사용자로 설정하고 사용자 프로필 구성에 아직 정의되어 있지 않은 다른 속성에는 액세스할 수 없습니다. 사용자 또는 관리자에게 노출하려는 모든 사용자 속성으로 사용자 프로필 구성을 업데이트하는 것이 좋습니다.

사용자 정보를 쿼리하기 위해 User REST API에 액세스하는 사용자에게 동일한 권장 사항이 적용됩니다.

해당 속성에 액세스하려면 LDAP_ID,LDAP_ENTRY_DN, KERBEROS_PRINCIPAL 과 같은 Red Hat Single Sign-On 내부 사용자 속성에 대한 속성을 액세스할 수 있습니다. 관리 콘솔을 통해 사용자 속성을 관리하거나 사용자 API를 통해 사용자를 쿼리할 때 이러한 속성을 관리자에게만 볼 수 있도록 이러한 속성을 관리자에게만 표시하는 것이 좋습니다.

파일과 관련하여 기존 템플릿(사용자 루트 속성을 사용하여 하드 코딩됨)에 대한 사용자 지정이 이미 있는 경우 사용자 쪽 양식을 렌더링하지만 이러한 양식을 동적으로 렌더링하는 새 템플릿을 사용하지 않습니다. 이상적으로 템플릿에 사용자 정의를 사용하지 말고 이러한 새 템플릿에서 제공하는 동작을 계속하여 양식을 동적으로 렌더링하는 것이 좋습니다. 요구 사항을 해결하기에 아직 충분하지 않은 경우 새 템플릿을 개선하는 것이 적합한지 여부를 논의할 수 있도록 사용자 지정하거나 피드백을 제공할 수 있습니다.

Logout all 버튼을 클릭하여 영역의 모든 사용자를 로그아웃 할 수 있습니다.

Logout all 버튼을 클릭하면 모든 SSO 쿠키가 유효하지 않게 되고 활성 브라우저 세션 내에서 인증을 요청하는 클라이언트는 다시 로그인해야 합니다. Red Hat Single Sign-On은 로그아웃 이벤트의 Red Hat Single Sign-On OIDC 클라이언트 어댑터를 사용하여 클라이언트에 알립니다. SAML과 같은 클라이언트 유형은 백 채널 로그 아웃 요청을 수신하지 않습니다.

세션 페이지에서 각 클라이언트를 클릭하여 해당 클라이언트의 세션 탭으로 이동할 수 있습니다. 애플리케이션에 있는 사용자를 보려면 세션 표시 버튼을 클릭합니다.

개별 사용자의 세션 탭으로 이동하면 사용자의 세션 정보를 볼 수도 있습니다.

그룹 및 역할에는 몇 가지 중요도와 차이점이 있습니다. Red Hat Single Sign-On에서 그룹은 역할 및 특성을 적용하는 사용자 컬렉션입니다. 역할은 사용자 및 애플리케이션의 유형을 정의하므로 권한 및 액세스 제어가 역할에 할당됩니다.

복합 역할은 동일한 기능을 제공하는 그룹과 유사합니다. 이 둘의 차이점은 개념입니다. 복합 역할은 권한 모델을 서비스 및 애플리케이션 집합에 적용합니다. 복합 역할을 사용하여 애플리케이션 및 서비스를 관리합니다.

그룹은 조직의 사용자 및 사용자 역할 컬렉션에 중점을 둡니다. 그룹을 사용하여 사용자 관리.

Identity Brokering 을 통해 가져오거나 가져온 모든 사용자에게 그룹 멤버십을 자동으로 할당하려면 기본 그룹을 사용합니다.

이 스크린샷은 일부 기본 그룹이 이미 있음을 보여줍니다.

OTP 생성기에 대해 Red Hat Single Sign-On에서 사용할 수 있는 알고리즘은 시간 기반이며 카운터 기반 알고리즘입니다.

TOTP(Time-Based One Time Passwords)를 사용하면 토큰 생성기가 현재 시간과 공유 시크릿을 해시합니다. 서버는 시간 내에 있는 해시를 제출된 값과 비교하여 OTP를 검증합니다. TOTP는 짧은 기간 동안 유효합니다.

qemu-Based One Time Passwords (HOTP)를 사용하면 Red Hat Single Sign-On은 현재 시간이 아닌 공유 카운터를 사용합니다. Red Hat Single Sign-On 서버는 OTP 로그인을 성공적으로 수행할 때마다 카운터를 늘립니다. 로그인에 성공한 후 유효한 OTP가 변경됩니다.

TOTP는 일치하는 OTP가 짧은 기간 동안 유효하고 OTP는 결정되지 않은 시간 동안 유효하기 때문에 TOTP는 보다 안전합니다. OTP에 들어가는 시간 제한이 없으므로 TOTP보다 사용자에게 친숙한 시간이 없습니다.

서버가 카운터를 증가할 때마다 데이터베이스를 업데이트해야 합니다. 이번 업데이트에서는 로드가 많은 동안 인증 서버에서 성능이 저하됩니다. 효율성을 높이기 위해 TOTP는 사용된 암호를 기억하지 않으므로 데이터베이스 업데이트를 수행할 필요가 없습니다. 단점은 유효한 시간 간격으로 TOTP를 다시 사용할 수 있다는 것입니다.

Red Hat Single Sign-On에는 여러 가지 흐름이 내장되어 있습니다. 이러한 흐름을 수정할 수는 없지만 필요에 맞게 흐름의 요구 사항을 변경할 수 있습니다.

드롭다운 목록에서 브라우저 를 선택하여 browsers Flow 화면을 표시합니다.

드롭다운 목록의 질문 표시 툴팁 위로 커서를 이동하여 흐름에 대한 설명을 확인합니다. 두 섹션이 있습니다.

중요한 기능 및 보안 고려 사항은 흐름을 설계할 때 적용됩니다.

흐름을 만들려면 다음을 수행합니다.

새 흐름을 만들 때 먼저 다음 옵션을 사용하여 최상위 흐름을 만들어야 합니다.

Red Hat Single Sign-On이 흐름을 생성하면 Red Hat Single Sign-On에 삭제,실행 추가, 흐름 추가 버튼이 표시됩니다.

세 가지 요소는 흐름 및 하위 흐름의 동작을 결정합니다.

실행은 재설정 이메일을 OTP 검증에 보내는 것부터 다양한 작업을 수행합니다. 실행 추가 버튼을 사용하여 실행을 추가합니다. 실행에 대한 설명을 보려면 공급자 옆에 있는 물음표 위로 마우스를 가져갑니다.

두 가지 유형의 실행, 자동 실행 및 대화형 실행이 있습니다. 자동 실행 은 10.0.0.1 실행 과 유사하며 흐름에서 자동으로 작업을 수행합니다. 대화형 실행 은 입력을 받기 위한 흐름을 중지합니다. 실행을 성공적으로 실행하면 상태가 success 로 설정됩니다. 흐름을 완료하려면 성공 상태의 실행이 하나 이상 필요합니다.

흐름 추가 버튼을 사용하여 최상위 흐름에 하위 흐름을 추가할 수 있습니다. 흐름 추가 버튼을 클릭하면 실행 흐름 만들기 페이지가 표시됩니다. 이 페이지는 최상위 양식 만들기 페이지와 유사합니다. 차이점은 흐름 유형이 일반 (기본값) 또는 형식일 수 있다는 것입니다. 양식 유형은 내장 등록 흐름과 유사하게 사용자의 양식을 생성하는 하위 흐름을 구성합니다. 하위 흐름 성공 여부는 포함된 하위 흐름을 포함하여 실행 결과를 평가하는 방법에 따라 달라집니다. 하위 흐름이 작동하는 방법에 대한 자세한 내용은 실행 요구 사항 섹션 을 참조하십시오.

흐름의 모든 요소에는 작업 메뉴의 Delete 옵션이 있습니다. 이 작업은 흐름에서 요소를 제거합니다. 실행에는 실행을 구성하는 Config 메뉴 옵션이 있습니다. 또한 실행 추가 및 흐름 추가 메뉴 옵션을 사용하여 실행 및 하위 흐름을 하위 흐름에 추가할 수도 있습니다.

실행 순서가 중요하므로 위 및 아래 버튼을 사용하여 흐름 내에서 실행 및 하위 흐름을 해당 이름 옆에 이동할 수 있습니다.

흐름 생성을 설명하기 위해 이 섹션에서는 고급 브라우저 로그인 흐름 만들기에 대해 설명합니다. 이 흐름의 목적은 사용자가 WebAuthn 을 사용하여 암호 없는 방식으로 로그인하거나 암호 및 OTP를 사용한 2단계 인증 중에서 선택할 수 있도록 하는 것입니다.

이 단계에서 양식에는 사용자 이름만 필요하지만 암호가 필요하지 않습니다. 보안 위험을 방지하려면 암호 인증을 활성화해야 합니다.

마지막으로 바인딩을 변경합니다.

사용자 이름을 입력하면 흐름은 다음과 같이 작동합니다.

사용자에게 WebAuthn 암호 없는 인증 정보가 기록된 경우 이러한 자격 증명을 사용하여 직접 로그인할 수 있습니다. 암호가 없는 로그인입니다. WebAuthn Passwordless 실행 및 OTP를 통한 암호 흐름이 Alternative 로 설정되어 있기 때문에 사용자가 OTP로 암호 를 선택할 수도 있습니다. Required 로 설정된 경우 사용자는 WebAuthn, password 및 OTP를 입력해야 합니다.

사용자가 WebAuthn 암호 없는 인증을 사용하여 다른 방법 확인 링크를 선택하면 사용자는 암호 와 보안 키 (WebAuthn 암호 없이)를 선택할 수 있습니다. 암호를 선택할 때 사용자는 계속해서 할당된 OTP로 로그인해야 합니다. 사용자에게 WebAuthn 자격 증명이 없는 경우 사용자는 암호를 입력한 다음 OTP를 입력해야 합니다. 사용자에게 OTP 인증 정보가 없는 경우 인증 정보를 기록하도록 요청합니다.

이 섹션에서는 단계별 메커니즘을 사용하여 고급 브라우저 로그인 흐름을 만드는 방법에 대해 설명합니다. 단계별 인증은 사용자의 특정 인증 수준에 따라 클라이언트 또는 리소스에 대한 액세스를 허용하는 것입니다.

이제 첫 번째 인증 수준에 대한 흐름을 구성합니다.

이제 두 번째 인증 수준에 대한 흐름을 구성합니다.

마지막으로 바인딩을 변경합니다.

https://{DOMAIN}/auth/realms/{REALMNAME}/protocol/openid-connect/auth?client_id={CLIENT-ID}&redirect_uri={REDIRECT-URI}&scope=openid&response_type=code&response_mode=query&nonce=exg16fxdjcu&claims=%7B%22id_token%22%3A%7B%22acr%22%3A%7B%22essential%22%3Atrue%2C%22values%22%3A%5B%22gold%22%5D%7D%7D%7D

claims 매개변수는 JSON 표현으로 지정됩니다.

claims= {
            "id_token": {
                "acr": {
                    "essential": true,
                    "values": ["gold"]
                }
            }
        }

Red Hat Single Sign-On JavaScript 어댑터는 이 JSON을 쉽게 구성하고 로그인 요청으로 전송합니다. 자세한 내용은 JavaScript 어댑터 문서를 참조하십시오.

claim 매개변수 대신 더 간단한 매개변수 acr_values 를 사용하여 특정 수준을 필수가 아닌 값으로 요청할 수도 있습니다. 이는 OIDC 사양에 설명되어 있습니다.

acr_values 매개변수 또는 acr 클레임이 있는 매개변수 클레임 이 없을 때 사용되는 특정 클라이언트에 대한 기본 수준을 구성할 수도 있습니다. 자세한 내용은 클라이언트 ACR 구성을참조하십시오.

자세한 내용은 공식 OIDC 사양 을 참조하십시오.

흐름 논리

이전에 구성된 인증 흐름의 논리는 다음과 같습니다.
클라이언트가 인증 2(LoA 2)의 고급 인증 수준을 요청하는 경우 사용자는 전체 2 단계 인증(사용자 이름/암호 + OTP)을 수행해야 합니다. 그러나 사용자에게 이미 사용자 이름과 암호(LoA 1)로 로그인한 Keycloak에 세션이 있는 경우 사용자에게 두 번째 OTP(인증 요인)만 요청됩니다.

조건의 Max Age (최대 기간) 옵션은 후속 인증 수준의 유효 기간(초)을 결정합니다. 이 설정은 후속 인증 중에 사용자에게 인증 요소를 다시 제공하도록 요청할지 여부를 결정하는 데 도움이 됩니다. 클레임 또는 acr_values 매개변수에 의해 요청되고 레벨 X로 이미 인증된 경우(예: max age는 300으로 구성되고 310초 전에 인증한 사용자) 특정 수준으로 다시 인증하라는 요청을 받습니다. 그러나 수준이 아직 만료되지 않은 경우 사용자는 해당 수준으로 자동으로 인증된 것으로 간주됩니다.

값이 0인 Max Age 를 사용하면 특정 수준이 이 단일 인증에서만 유효합니다. 따라서 해당 수준을 요청하는 모든 재인증은 해당 수준으로 다시 인증해야 합니다. 이는 애플리케이션에서 더 높은 보안이 필요한 작업(예: 결제 전송)에 유용하며 항상 특정 수준의 인증이 필요합니다.

매개 변수에서 명시적 수준을 요청하지 않는 경우 Red Hat Single Sign-On에는 이전 예제의 Username/Password와 같은 인증 흐름에 있는 첫 번째 KiA 조건으로 인증이 필요합니다. 사용자가 해당 수준으로 이미 인증되고 해당 수준이 만료된 경우 사용자는 다시 인증되지 않아도 되지만 토큰의 acr 값은 0입니다. 이 결과는 OIDC Core 1.0 사양의 섹션 2에 언급된 대로 수 명이 긴 브라우저 쿠키 만을 기반으로 한 인증으로 간주됩니다.

시나리오 예

토큰의 ACR 클레임

ACR 클레임은 acr 클라이언트 범위에 정의된 acr loa 수준 프로토콜 매퍼에 의해 토큰에 추가됩니다. 이 클라이언트 범위는 영역 기본 클라이언트 범위이므로 해당 영역의 새로 생성된 모든 클라이언트에 추가됩니다.

토큰 내에 acr 클레임을 사용하지 않거나 이를 추가하기 위한 사용자 지정 논리가 필요한 경우 클라이언트에서 클라이언트 범위를 제거할 수 있습니다.

로그인 요청이 필수 클레임으로 acr 을 요청하는 claims 매개변수를 사용하여 요청을 시작하는 경우 Red Hat Single Sign-On은 항상 지정된 수준 중 하나를 반환합니다. 지정된 수준 중 하나를 반환할 수 없는 경우(예: 요청된 수준이 인증 흐름에서 구성된 조건보다 알 수 없거나 큰 경우) Red Hat Single Sign-On에서 오류가 발생합니다.

사용자가 구성할 수 있는 세션 수에 대한 제한입니다. 세션은 영역별로 제한되거나 클라이언트별로 제한될 수 있습니다.

흐름에 세션 제한을 추가하려면 다음 단계를 수행합니다.

사용자 세션 제한은 바인딩된 browsers 흐름,직접 부여 흐름 ,자격 증명 재설정 및 구성된 모든 ID 공급자의 후 로그인 흐름에 추가해야 합니다. 현재 관리자는 서로 다른 구성 간의 일관성을 유지 관리합니다.

CIBA에서는 사용자 세션 제한 기능을 사용할 수 없습니다.

Kerberos 서버를 설정하는 단계는 운영 체제(OS) 및 Kerberos 벤더에 따라 다릅니다. Kerberos 서버 설정 및 구성에 대한 지침은 Windows Active Directory, MIT Kerberos 및 OS 설명서를 참조하십시오.

설치하는 동안 다음 단계를 수행합니다.

sudo kadmin.local

그런 다음 HTTP 주체를 추가하고 다음과 같은 명령을 사용하여 키를 키 탭 파일에 내보냅니다.

addprinc -randkey HTTP/www.mydomain.org@MYDOMAIN.ORG
ktadd -k /tmp/http.keytab HTTP/www.mydomain.org@MYDOMAIN.ORG

Red Hat Single Sign-On이 실행 중인 호스트에서 키 탭 파일 /tmp/http.keytab 에 액세스할 수 있는지 확인합니다.

시스템에 Kerberos 클라이언트를 설치합니다.

클라이언트 시스템에는 Kerberos 클라이언트가 있어야 하며 위에 설명된 대로 10.0.0.15.conf 를 설정해야 합니다. 클라이언트 머신은 브라우저에서도 10.0.0.1EGO 로그인 지원을 활성화해야 합니다. Firefox 브라우저를 사용하는 경우 Kerberos용 Firefox 구성을 참조하십시오.

.mydomain.org URI는 network.negotiate-auth.trusted-uris 구성 옵션에 있어야 합니다.

Windows 도메인에서 클라이언트는 구성을 조정할 필요가 없습니다. Internet Explorer 및 Edge는 이미 SelectEGO 인증에 참여할 수 있습니다.

Kerberos는 자격 증명 위임을 지원합니다. 애플리케이션은 Kerberos 티켓으로 보호되는 다른 서비스와 상호 작용하기 위해 다시 사용할 수 있도록 Kerberos 티켓에 액세스해야 할 수 있습니다. Red Hat Single Sign-On 서버에서 ChronyEGO 프로토콜을 처리했기 때문에 GSS 인증 정보를 OpenID Connect 토큰 클레임 또는 SAML 어설션 특성 내에서 애플리케이션에 전파해야 합니다. Red Hat Single Sign-On은 이를 Red Hat Single Sign-On 서버에서 애플리케이션에 전송합니다. 이 클레임을 토큰 또는 어설션에 삽입하려면 각 애플리케이션에서 기본 제공 프로토콜 매퍼 위임 자격 증명을 활성화해야 합니다. 이 매퍼는 애플리케이션 클라이언트 페이지의 Mappers 탭에서 사용할 수 있습니다. 자세한 내용은 프로토콜 맵퍼 장을 참조하십시오.

애플리케이션은 다른 서비스에 대해 GSS를 호출하기 전에 Red Hat Single Sign-On에서 수신하는 클레임을 역직렬화해야 합니다. 액세스 토큰에서 GSSCredential 오브젝트로 인증 정보를 역직렬화할 때 이 인증 정보를 사용하여 GSSContext를 GSSManager.createContext 메서드로 전달합니다. 예를 들면 다음과 같습니다.

// Obtain accessToken in your application.
KeycloakPrincipal keycloakPrincipal = (KeycloakPrincipal) servletReq.getUserPrincipal();
AccessToken accessToken = keycloakPrincipal.getKeycloakSecurityContext().getToken();

// Retrieve Kerberos credential from accessToken and deserialize it
String serializedGssCredential = (String) accessToken.getOtherClaims().
    get(org.keycloak.common.constants.KerberosConstants.GSS_DELEGATION_CREDENTIAL);

GSSCredential deserializedGssCredential = org.keycloak.common.util.KerberosSerializationUtils.
    deserializeCredential(serializedGssCredential);

// Create GSSContext to call other Kerberos-secured services
GSSContext context = gssManager.createContext(serviceName, krb5Oid,
    deserializedGssCredential, GSSContext.DEFAULT_LIFETIME);

Kerberos 프로토콜에서 영역은 Kerberos 사용자 집합입니다. 이러한 주체의 정의는 일반적으로 LDAP 서버인 Kerberos 데이터베이스에 있습니다.

Kerberos 프로토콜은 교차 영역 신뢰를 허용합니다. 예를 들어, 2개의 Kerberos 영역인 A 및 B가 존재하는 경우 교차 영역 신뢰를 통해 영역 A에서 영역 B의 리소스에 액세스할 수 있습니다. 영역 B는 영역 A를 신뢰합니다.

Red Hat Single Sign-On 서버는 교차 영역 신뢰를 지원합니다. 이를 구현하려면 다음을 수행합니다.

사용자를 찾는 것은 LDAP 스토리지 공급자 옵션 Kerberos 주체 속성을 기반으로 합니다. userPrincipalName 과 같은 값이 있는 인스턴스에 대해 구성된 경우, john@A ; 사용자 john@A )의 CryostatEGO 인증 후 Red Hat Single Sign-On은 john@A 와 동등한 userPrincipalName 특성을 사용하여 LDAP 사용자를 조회하려고 합니다. Kerberos 주체 속성이 비어 있으면 Red Hat Single Sign-On은 해당 영역을 생략한 kerberos 주체 접두사를 기반으로 LDAP 사용자를 조회합니다. 예를 들어 Kerberos 주체 사용자 john@A 는 사용자 이름 john 아래의 LDAP에서 사용할 수 있어야 하므로 일반적으로 uid= john,ou=People,dc=example,dc=com 과 같은 LDAP DN에서 사용할 수 있습니다. 영역 A 및 B의 사용자가 인증하도록 하려면 LDAP에서 A 영역 A와 B의 사용자를 모두 찾을 수 있는지 확인합니다.

여러 Kerberos 영역의 사용자는 모든 사용자에게 인증에 사용되는 kerberos 주체를 참조하는 KERBEROS_PRINCIPAL 속성이 있으므로 인증할 수 있으며, 이는 이 사용자를 추가로 조회하는 데 사용됩니다. kerberos 영역 A 및 B 모두에 사용자 john 이 있는 경우 충돌을 방지하기 위해 Red Hat Single Sign-On 사용자의 사용자 이름에 kerberos 영역이 소문자로 포함될 수 있습니다. 예를 들어 사용자 이름은 john@a 입니다. 구성된 Kerberos 영역과 realm이 일치하는 경우에만 realm 접미사가 생성된 사용자 이름에서 생략될 수 있습니다. 예를 들어 Kerberos 공급자에서 Kerberos 영역을 구성하는 경우 Kerberos 주체 john @ A 의 사용자 이름은 john입니다.

문제가 있는 경우 추가 로깅을 활성화하여 문제를 디버깅합니다.

지원되는 인증서 ID 소스:

emailAddress=(.*?)(?:,|$)

다음 섹션에서는 X.509 클라이언트 인증서 인증을 활성화하기 위해 JBoss EAP/Undertow 및 Red Hat Single Sign-On 서버를 구성하는 방법을 설명합니다.

<security-realms>
    <security-realm name="ssl-realm">
        <server-identities>
            <ssl>
                <keystore path="servercert.jks"
                          relative-to="jboss.server.config.dir"
                          keystore-password="servercert password"/>
            </ssl>
        </server-identities>
        <authentication>
            <truststore path="truststore.jks"
                        relative-to="jboss.server.config.dir"
                        keystore-password="truststore password"/>
        </authentication>
    </security-realm>
</security-realms>

<subsystem xmlns="urn:jboss:domain:undertow:12.0">
	....
    <server name="default-server">
	    <https-listener name="default"
                        socket-binding="https"
                        security-realm="ssl-realm"
                        verify-client="REQUESTED"/>
    </server>
</subsystem>

Red Hat Single Sign-On 서버에서 직접 HTTP 요청을 수신하면 JBoss EAP undertow 하위 시스템에서 SSL 핸드셰이크를 설정하고 클라이언트 인증서를 추출합니다. JBoss EAP는 서블릿 사양에 지정된 대로 클라이언트 인증서를 HTTP 요청의 javax.servlet.request.X509Certificate 속성에 저장합니다. Red Hat Single Sign-On X509 인증자는 이 특성에서 인증서를 조회할 수 있습니다.

그러나 Red Hat Single Sign-On 서버가 로드 밸런서 또는 역방향 프록시 뒤에서 HTTP 요청을 수신하면 프록시 서버가 클라이언트 인증서를 추출하고 상호 SSL 연결을 설정할 수 있습니다. 역방향 프록시는 일반적으로 인증된 클라이언트 인증서를 기본 요청의 HTTP 헤더에 배치합니다. 프록시는 요청을 백엔드 Red Hat Single Sign-On 서버로 전달합니다. 이 경우 Red Hat Single Sign-On은 HTTP 요청의 속성이 아닌 HTTP 헤더에서 X.509 인증서 체인을 조회해야 합니다.

Red Hat Single Sign-On이 역방향 프록시 뒤에 있는 경우 일반적으로 RHSSO_HOME/standalone/configuration/standalone.xml에서 x509cert-lookup SPI의 대체 공급자를 구성해야 합니다. HTTP 헤더 인증서를 검색하는 기본 공급자에서는 haproxy 및 apache 라는 두 개의 추가 기본 제공 공급자가 있습니다.

<spi name="x509cert-lookup">
    <default-provider>haproxy</default-provider>
    <provider name="haproxy" enabled="true">
        <properties>
            <property name="sslClientCert" value="SSL_CLIENT_CERT"/>
            <property name="sslCertChainPrefix" value="CERT_CHAIN"/>
            <property name="certificateChainLength" value="10"/>
        </properties>
    </provider>
</spi>

<spi name="x509cert-lookup">
    <default-provider>apache</default-provider>
    <provider name="apache" enabled="true">
        <properties>
            <property name="sslClientCert" value="SSL_CLIENT_CERT"/>
            <property name="sslCertChainPrefix" value="CERT_CHAIN"/>
            <property name="certificateChainLength" value="10"/>
        </properties>
    </provider>
</spi>

<spi name="x509cert-lookup">
    <default-provider>nginx</default-provider>
    <provider name="nginx" enabled="true">
        <properties>
            <property name="sslClientCert" value="ssl-client-cert"/>
            <property name="sslCertChainPrefix" value="USELESS"/>
            <property name="certificateChainLength" value="2"/>
        </properties>
    </provider>
</spi>

 ...
 server {
    ...
    ssl_client_certificate                  trusted-ca-list-for-client-auth.pem;
    ssl_verify_client                       optional_no_ca;
    ssl_verify_depth                        2;
    ...
    location / {
      ...
      proxy_set_header ssl-client-cert        $ssl_client_escaped_cert;
      ...
    }
    ...
}

...
    <profile>
        <subsystem xmlns="urn:jboss:domain:logging:8.0">
...
            <logger category="org.keycloak.authentication.authenticators.x509">
                <level name="TRACE"/>
            </logger>
            <logger category="org.keycloak.services.x509">
                <level name="TRACE"/>
            </logger>

다음 템플릿을 사용하여 Resource Owner Password Credentials Grant를 사용하여 토큰을 요청할 수 있습니다.

$ LOC=<install-dir>/intermediate1/user-certificate

$ curl --insecure https://localhost:8443/auth/realms/X509_demo/protocol/openid-connect/token --data "grant_type=password" -E $LOC/user1.crt --key $LOC/user1.key --cacert $LOC/intermediate-ca-chain.crt -d client_id=account -d client_secret=BNm5AQPJGEtbayIAoiKUetr0lkXKSlF4 | jq
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2097 100 2013 100 84 25481 1063 -::- -::- -::- 26544
{
"access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ1OUNpN0tzUjBIOEFCQXEtQ1Z4SEFDSUo1M1hNYWVhclJrYkw4cFd1VW4wIn0.eyJleHAiOjE2Njc4MzA5NjAsImlhdCI6MTY2NzgzMDY2MCwianRpIjoiNDU5YzE2OGMtODU3ZS00OWRjLTgxYjItZjVhM2M3M2MwODMzIiwiaXNzIjoiaHR0cHM6Ly9sb2NhbGhvc3Q6ODQ0My9hdXRoL3JlYWxtcy9YNTA5X2RlbW8iLCJzdWIiOiIwODZiMTgyZC00MzdhLTQzZDItYTRmZS05ZGZmYTNmOTBiZDAiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJhY2NvdW50Iiwic2Vzc2lvbl9zdGF0ZSI6ImMwYjNiMTJjLTM5YmEtNGQ0Ni1iNDNlLTZkMTM0MGJmNTA5OCIsImFjciI6IjEiLCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJwcm9maWxlIGVtYWlsIiwic2lkIjoiYzBiM2IxMmMtMzliYS00ZDQ2LWI0M2UtNmQxMzQwYmY1MDk4IiwiZW1haWxfdmVyaWZpZWQiOmZhbHNlLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ1c2VyMSIsImVtYWlsIjoidXNlckByZWRoYXQuY29tIn0.CDtltEkmITloDpqU5alq4U1JopqEJVeoglT-wA43edQ_DfeWSgefL0BIrPlt1SKhFMOVitwyq_9XZvfiS5ZiObE33cDmhr6eohbUtDPibU2GuEIYP9WjlVpZDMaSKQVu5SwM91m6yei22PtH-ApPOBeG4Ru0xZtNXjwGQpuIJEi_H1rZdPY3I4U2lPuQo4Uono5gnF7re_nUvf90FJi0uaOOrsvUhUkj1xEwQ0Diy1oIymcbrDL0Ek7B30StBcjn-fe3-0GpLttLQju0OGTkwD7Eb0UWTKoWAwspMlgpf9NaIGj8rmBsz6eBlGIGWBN2Qg6v3PzbJ2NXKvq435f9Zg",
"expires_in": 300,
"refresh_expires_in": 1800,
"refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICIyMmFkZDdhMy0xN2RjLTQ5NmQtYTk4NS05YWZhNGZhODVhMTEifQ.eyJleHAiOjE2Njc4MzI0NjAsImlhdCI6MTY2NzgzMDY2MCwianRpIjoiZWU4MjJhMzYtMWEzMS00ZGEzLWIxMGEtNmY1ODkxYmI0MzlhIiwiaXNzIjoiaHR0cHM6Ly9sb2NhbGhvc3Q6ODQ0My9hdXRoL3JlYWxtcy9YNTA5X2RlbW8iLCJhdWQiOiJodHRwczovL2xvY2FsaG9zdDo4NDQzL2F1dGgvcmVhbG1zL1g1MDlfZGVtbyIsInN1YiI6IjA4NmIxODJkLTQzN2EtNDNkMi1hNGZlLTlkZmZhM2Y5MGJkMCIsInR5cCI6IlJlZnJlc2giLCJhenAiOiJhY2NvdW50Iiwic2Vzc2lvbl9zdGF0ZSI6ImMwYjNiMTJjLTM5YmEtNGQ0Ni1iNDNlLTZkMTM0MGJmNTA5OCIsInNjb3BlIjoicHJvZmlsZSBlbWFpbCIsInNpZCI6ImMwYjNiMTJjLTM5YmEtNGQ0Ni1iNDNlLTZkMTM0MGJmNTA5OCJ9.MubgR9rvyrmSOcaq5ce-qVTPenVQye1KsEHJr7nh9-A",
"token_type": "Bearer",
"not-before-policy": 0,
"session_state": "c0b3b12c-39ba-4d46-b43e-6d1340bf5098",
"scope": "profile email"
}

2FA에 대한 WebAuthn 지원 설정 절차는 다음과 같습니다.

WebAuthn authenticator를 등록하면 사용자는 다음 작업을 수행합니다.

WebAuthn authenticator를 등록할 때 Red Hat Single Sign-On은 WebAuthn 인증자가 생성한 검증 문의 신뢰할 수 있는지 확인합니다. Red Hat Single Sign-On에는 이를 위해 신뢰 앵커의 인증서가 필요합니다. Red Hat Single Sign-On은 Keycloak 신뢰 저장소를 사용하므로 이러한 인증서를 미리 가져와야 합니다.

이 검증을 생략하려면 이 신뢰 저장소를 비활성화하거나 WebAuthn 정책의 구성 항목 "Attestation Conveyance Preference"를 "none"으로 설정합니다.

Red Hat Single Sign-On은 2단계 인증에 WebAuthn을 사용하지만 WebAuthn을 첫 번째 인증으로 사용할 수 있습니다. 이 경우 암호가 없는 WebAuthn 자격 증명을 가진 사용자는 암호 없이 Red Hat Single Sign-On에 인증할 수 있습니다. Red Hat Single Sign-On은 영역과 단일 인증 흐름 컨텍스트에서 WebAuthn을 암호 없이 2단계 인증 메커니즘으로 사용할 수 있습니다.

관리자는 일반적으로 WebAuthn 암호 없는 인증을 위해 사용자가 등록한 보안 키가 다른 요구 사항을 충족해야 합니다. 예를 들어 보안 키는 사용자가 CloudEvent를 사용하여 보안 키로 인증해야 하거나 더 강력한 인증 기관의 보안 키를 사용해야 할 수 있습니다.

이로 인해 Red Hat Single Sign-On을 통해 관리자는 별도의 WebAuthn 암호 없는 정책을 구성할 수 있습니다. Webauthn Register Passwordless action 유형 및 WebAuthn Passwordless Authenticator 유형의 인증기(Authn Passwordless Authenticator) 유형에는 필수 Webauthn Registerless 작업이 있습니다.

Red Hat Single Sign-On은 2단계 인증에 WebAuthn을 사용하지만 WebAuthn을 첫 번째 인증으로 사용할 수 있습니다. 이 경우 암호가 없는 WebAuthn 자격 증명을 가진 사용자는 로그인 또는 암호를 제출하지 않고도 Red Hat Single Sign-On에 인증할 수 있습니다. Red Hat Single Sign-On은 영역 컨텍스트에서 loginless/passwordless 및 2 단계 인증 메커니즘으로 WebAuthn을 사용할 수 있습니다.

관리자는 일반적으로 WebAuthn 로그인리스 인증을 위해 사용자가 등록한 보안 키가 다른 요구 사항을 충족해야 합니다. 로그인되지 않은 인증에서는 사용자가 보안 키(예: CloudEvent 코드 또는 지문을 사용하여) 인증하고 로그인리스 자격 증명과 관련된 암호화 키가 보안 키에 물리적으로 저장되어야 합니다. 모든 보안 키가 이러한 종류의 요구 사항을 충족하는 것은 아닙니다. 장치가 '사용자 확인' 및 '기타 키'를 지원하는지의 보안 주요 공급 업체에 확인하십시오. 지원되는 보안 키 를 참조하십시오.

Red Hat Single Sign-On에서는 관리자가 로그인 없이 인증할 수 있는 방식으로 WebAuthn 암호 없는 정책을 구성할 수 있습니다. 로그인리스 인증은 WebAuthn Passwordless 정책 및 WebAuthn 암호 없는 자격 증명으로만 구성할 수 있습니다. WebAuthn 로그인리스 인증 및 WebAuthn 암호 없는 인증은 동일한 영역에서 구성할 수 있지만 동일한 정책 WebAuthn 암호 없는 정책을 공유합니다.

조건부 흐름에서 리소스에 대한 액세스를 허용하거나 거부할 수 있습니다. 두 인증 정보 액세스 거부 및 허용 액세스 제어 조건별 리소스에 대한 액세스 권한 허용

다음은 role1 역할이 없고 속성 deny- role1 에 정의된 오류 메시지를 표시하는 모든 사용자에게 액세스를 거부하는 예제입니다. 이 예제에는 상태 - 사용자 역할 및 거부 액세스 실행이 포함됩니다.

마지막으로 로그인me messages_en.properties (한국어의 경우)에서 오류 메시지를 사용하여 속성을 정의하는 것입니다.

deny-role1 = You do not have required role!

Bitbucket을 사용하여 로그인하려면 다음 절차를 수행합니다.

Red Hat Single Sign-On은 프로필 요청을 graph.facebook.com/me?fields=id,name,email,first_name,last_name 으로 보냅니다. 응답에는 id, name, email, first_name, last_name 필드만 포함됩니다. Facebook 프로필에서 추가 필드를 가져오려면 해당 범위를 추가하고 추가 사용자의 프로필 필드 구성 옵션 필드에 필드 이름을 추가합니다.

Github로 로그인하려면 다음 절차를 수행하십시오.

자세한 내용은 공식 OpenShift 문서를 참조하십시오.