12장. OpenID Connect 및 SAML 클라이언트 관리

OpenID connect 프로토콜을 사용하는 애플리케이션을 보호하려면 클라이언트를 생성합니다.

이 작업은 클라이언트를 생성하고 설정 탭으로 이동합니다.

OIDC 클라이언트를 생성할 때 설정 탭에 다음 필드가 표시됩니다.

로고 URL

클라이언트 애플리케이션의 로고를 참조하는 URL입니다.

정책 URL

Relying Party Client가 프로필 데이터를 사용하는 방법에 대해 읽기 위해 최종 사용자에게 제공하는 URL입니다.

서비스 약관 URL

Relying Party Client가 Relying Party의 서비스 약관을 읽기 위해 최종 사용자에게 제공하는 URL입니다.

고급 설정을 클릭하면 추가 필드가 표시됩니다.

OAuth 2.0 상호 TLS 인증서 Bound 액세스 토큰 활성화

상호 TLS는 TLS 핸드셰이크 중에 교환되는 액세스 토큰과 새로 고침 토큰을 클라이언트 인증서와 함께 바인딩합니다. 이 바인딩을 사용하면 공격자가 분할된 토큰을 사용할 수 없습니다.

이 유형의 토큰은 키 보유 토큰입니다. 전달자 토큰과 달리 보유자 토큰 수신자는 토큰 발신자가 적절한지 확인할 수 있습니다.

이 설정이 설정되어 있는 경우 워크플로우는 다음과 같습니다.

확인에 실패하면 Red Hat Single Sign-On에서 토큰을 거부합니다.

다음 경우 Red Hat Single Sign-On은 액세스 토큰 또는 새로 고침 토큰을 전송하는 클라이언트를 확인합니다.

자세한 내용은 OAuth 2.0 상호 TLS 클라이언트 인증 및 인증서 Bound 액세스 토큰 의 상호 TLS 클라이언트 인증서 Bound 액세스 토큰을 참조하십시오.

OIDC 고급 설정

OpenID Connect의 고급 설정을 사용하면 세션 및 토큰 시간 초과 에 대한 클라이언트 수준에서 재정의를 구성할 수 있습니다.

코드 교환 코드 챌린지 방법에 대한 검증 키

공격자가 적법한 클라이언트의 권한 부여 코드를 스틸링하는 경우 PKCE(Proof Key for Code Exchange)는 공격자가 코드에 적용되는 토큰을 수신하지 못하도록 합니다.

관리자는 다음 옵션 중 하나를 선택할 수 있습니다.

자세한 내용은 RFC 7636 Proof Key for Code Exchange by OAuth Public Clients 에서 참조하십시오.

서명 및 암호화된 ID 토큰 지원

Red Hat Single Sign-On은 Json Web Encryption(JWE) 사양에 따라 ID 토큰을 암호화할 수 있습니다. 관리자는 각 클라이언트에 대해 ID 토큰이 암호화되었는지 확인합니다.

ID 토큰을 암호화하는 데 사용되는 키는 콘텐츠 암호화 키(CEK)입니다. Red Hat Single Sign-On과 클라이언트는 사용 중인 ovirtK와 전달 방법을 협상해야 합니다. ovirtK를 결정하는 데 사용되는 방법은 키 관리 모드입니다. Red Hat Single Sign-On이 지원하는 키 관리 모드는 키 암호화입니다.

키 암호화에서 다음을 수행합니다.

클라이언트 이외의 당사자는 ID 토큰을 해독할 수 없습니다.

클라이언트는 ovirtK를 Red Hat Single Sign-On에 암호화하기 위해 공개 키를 전달해야 합니다. Red Hat Single Sign-On은 클라이언트가 제공하는 URL에서 공개 키를 다운로드할 수 있도록 지원합니다. 클라이언트는 Json Web Keys (JWK) 사양에 따라 공개 키를 제공해야 합니다.

절차는 다음과 같습니다.

키 암호화 알고리즘은 Json Web Algorithm(JWA) 사양에 정의되어 있습니다. Red Hat Single Sign-On은 다음을 지원합니다.

알고리즘을 선택하는 절차는 다음과 같습니다.

ACR to Level of Authentication (LoA) Mapping

클라이언트의 고급 설정에서 ACR(Authentication Context Class Reference) 값을 정의할 수 있습니다. 이 값은 LoA(Level of Authentication) 에 매핑됩니다. 이 매핑은 ACR에 언급된 LOA Mapping 영역에서도 지정할 수 있습니다. 가장 좋은 방법은 여러 클라이언트 간에 동일한 설정을 공유할 수 있는 영역 수준에서 이 매핑을 구성하는 것입니다.

Default ACR 값은 로그인 요청이 acr_values 매개변수 없이 Red Hat Single Sign-On으로 전송될 때 기본값을 지정하고 acr 클레임이 연결된 클레임 매개변수 없이 기본값을 지정할 수 있습니다. 외부 OIDC 동적 클라이언트 등록 사양을 참조하십시오.

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

클라이언트의 액세스 유형이 기밀 로 설정된 경우 클라이언트의 자격 증명은 Credentials 탭에서 구성해야 합니다.

Client Authenticator 드롭다운 목록은 클라이언트에 사용할 인증 정보 유형을 지정합니다.

클라이언트 ID 및 시크릿

이 옵션은 기본 설정입니다. 시크릿은 자동으로 생성되며 Regenerate 시크릿을 클릭하면 필요한 경우 시크릿이 다시 생성됩니다.

서명된 JWT 는 "Signed Json Web Token"입니다.

이 인증 정보 유형을 선택할 때 키 탭에서 클라이언트의 개인 키 및 인증서를 생성해야 합니다. 개인 키는 JWT에 서명하는 데 사용되며 인증서는 서버에서 서명을 확인하는 데 사용됩니다.

새 키와 인증서 생성 버튼을 클릭하여 이 프로세스를 시작합니다.

키를 생성할 때 Red Hat Single Sign-On은 인증서를 저장하고 클라이언트의 개인 키와 인증서를 다운로드합니다.

외부 도구를 사용하여 키를 생성한 다음 인증서 가져오기를 클릭하여 클라이언트 인증서를 가져올 수도 있습니다.

JWKS URL 사용을 클릭하면 인증서 가져오기가 필요하지 않습니다. 이 경우 공개 키가 JWK 형식으로 게시되는 URL을 제공할 수 있습니다. 이 옵션을 사용하면 키가 변경되면 Red Hat Single Sign-On에서 키를 다시 가져옵니다.

Red Hat Single Sign-On 어댑터에서 보호하는 클라이언트를 사용하는 경우 https://myhost.com/myapp 가 클라이언트 애플리케이션의 루트 URL이라고 가정하면 이 형식으로 JWKS URL을 구성할 수 있습니다.

https://myhost.com/myapp/k_jwks

자세한 내용은 서버 개발자 가이드를 참조하십시오.

클라이언트 시크릿을 사용하여 서명된 JWT

이 옵션을 선택하는 경우 개인 키 대신 클라이언트 시크릿에서 서명한 JWT를 사용할 수 있습니다.

클라이언트 시크릿은 클라이언트에서 JWT에 서명하는 데 사용됩니다.

X509 인증서

Red Hat Single Sign-On은 TLS 핸드셰이크 중에 클라이언트가 적절한 X509 인증서를 사용하는지 확인합니다.

유효성 검사기에서는 regexp 검증 표현식이 구성된 인증서의 Subject DN 필드도 확인합니다. 일부 사용 사례의 경우 모든 인증서를 수락하는 것으로 충분합니다. 이 경우 (.*?)(?:$) 표현식을 사용할 수 있습니다.

Red Hat Single Sign-On은 요청에서 클라이언트 ID를 가져오는 두 가지 방법이 있습니다.

기밀성 액세스 유형이 있는 클라이언트 의 경우 Red Hat Single Sign-On은 클라이언트 정책을 통해 클라이언트 순환 보안 기능을 지원합니다.

클라이언트 보안 교체 정책은 보안 누출과 같은 문제를 완화하기 위해 보안을 강화합니다. 활성화되면 Red Hat Single Sign-On은 각 클라이언트에 대해 최대 두 개의 동시에 활성 시크릿을 지원합니다. 정책은 다음 설정에 따라 회전을 관리합니다.

클라이언트 시크릿이 순환되면 새 기본 보안이 생성되고 이전 클라이언트 기본 시크릿이 새 만료 날짜가 포함된 보조 시크릿이 됩니다.

다음은 시크릿 교체 정책을 정의하는 예입니다.

각 OIDC 클라이언트에는 기본 제공 서비스 계정이 있습니다. 이 서비스 계정을 사용하여 액세스 토큰을 가져옵니다.

액세스 토큰의 역할은 다음과 같은 교집합입니다.

호출할 REST URL은 /auth/realms/{realm-name}/protocol/openid-connect/token 입니다. 이 URL은 POST 요청으로 호출되어야 하며 요청을 사용하여 클라이언트 자격 증명을 게시해야 합니다.

기본적으로 클라이언트 인증 정보는 Authorization: Basic 헤더에서 클라이언트의 clientId 및 clientSecret으로 표시되지만 서명된 JWT 어설션 또는 클라이언트 인증을 위한 기타 사용자 정의 메커니즘으로 클라이언트를 인증할 수도 있습니다.

또한 OAuth2 사양에 따라 grant_type 매개변수를 "client_credentials"로 설정해야 합니다.

예를 들어 서비스 계정을 검색하는 POST 호출은 다음과 같습니다.

    POST /auth/realms/demo/protocol/openid-connect/token
    Authorization: Basic cHJvZHVjdC1zYS1jbGllbnQ6cGFzc3dvcmQ=
    Content-Type: application/x-www-form-urlencoded

    grant_type=client_credentials

응답은 OAuth 2.0 사양의 액세스 토큰 응답 과 유사합니다.

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"bearer",
    "expires_in":60
}

기본적으로 액세스 토큰만 반환됩니다. 새로 고침 토큰이 반환되지 않으며 기본적으로 인증에 성공하면 Red Hat Single Sign-On 측에서 사용자 세션이 생성되지 않습니다. 새로 고침 토큰이 없기 때문에 액세스 토큰이 만료되면 다시 인증해야 합니다. 그러나 이러한 상황은 세션이 기본적으로 생성되지 않기 때문에 Red Hat Single Sign-On 서버에 대한 추가 오버헤드를 나타내는 것은 아닙니다.

이 경우 로그아웃이 필요하지 않습니다. 하지만 OpenID Connect Endpoints 섹션에 설명된 대로 OAuth2 Revocation Endpoints에 요청을 전송하면 발행된 액세스 토큰을 취소할 수 있습니다.

일반적으로 Red Hat Single Sign-On이 배포된 환경은 인증을 위해 Red Hat Single Sign-On을 사용하는 기밀 또는 공용 클라이언트 애플리케이션 세트로 구성됩니다.

클라이언트 애플리케이션의 요청을 제공하고 이러한 애플리케이션에 리소스를 제공하는 서비스 ( OAuth 2 사양의 리소스서버 )도 사용할 수 있습니다. 이러한 서비스에는 요청을 인증하기 위해 액세스 토큰 (Bearer 토큰)이 전송되어야 합니다. 이 토큰은 Red Hat Single Sign-On에 로그인하면 프런트 엔드 애플리케이션에서 가져옵니다.

서비스 간 신뢰가 낮은 환경에서는 다음 시나리오가 발생할 수 있습니다.

이 시나리오는 서비스 간에 높은 수준의 신뢰가 있는 환경에서는 가능성이 크지 않지만 신뢰가 낮은 환경에서는 그렇지 않습니다. 일부 환경에서는 신뢰할 수 없는 서비스에서 원래 클라이언트 애플리케이션으로 데이터를 반환하기 위해 신뢰할 수 없는 서비스에서 데이터를 검색해야 할 수 있으므로 이 워크플로가 정확할 수 있습니다.

무제한 오디언스는 서비스 간에 높은 수준의 신뢰가 존재하는 경우 유용합니다. 그렇지 않으면 사용자가 제한해야 합니다. 대상을 제한하고 동시에 신뢰할 수 없는 서비스에서 신뢰할 수 있는 서비스에서 데이터를 검색할 수 있습니다. 이 경우 신뢰할 수 없는 서비스와 신뢰할 수 있는 서비스가 토큰에 오디언스로 추가되었는지 확인합니다.

액세스 토큰을 오용하지 않도록 하려면 토큰에서 오디언스를 제한하고, 토큰의 오디언스를 확인하도록 서비스를 구성합니다. 흐름은 다음과 같이 변경됩니다.

클라이언트가 나중에 신뢰할 수 있는 서비스를 호출하려는 경우 범위=<trusted service>로 SSO 로그인을 다시 발행하여 다른 토큰을 가져와야 합니다. 그런 다음 반환된 토큰은 신뢰할 수 있는 서비스를 대상자로 포함합니다.

"audience": [ "<trusted service>" ]

이 값을 사용하여 < 신뢰할 수 있는 서비스& gt;를 호출합니다.