8.5. X.509 클라이언트 인증서 사용자 인증
Red Hat Single Sign-On은 상호 SSL 인증을 사용하도록 서버를 구성한 경우 X.509 클라이언트 인증서로 로그인할 수 있도록 지원합니다.
일반적인 워크플로:
- 클라이언트는 SSL/TLS 채널을 통해 인증 요청을 보냅니다.
- SSL/TLS 핸드셰이크 동안 서버와 클라이언트는 x.509/v3 인증서를 교환합니다.
- 컨테이너(JBoss EAP)는 인증서 PKIX 경로와 인증서 만료 날짜를 검증합니다.
X.509 클라이언트 인증서 인증 고객은 다음 방법을 사용하여 클라이언트 인증서의 유효성을 검사합니다.
- CRL 또는 CRL 배포 포인트를 사용하여 인증서 해지 상태를 확인합니다.
- OCSP(Online Certificate Status Protocol)를 사용하여 인증서 해지 상태를 확인합니다.
- 인증서의 키가 예상 키와 일치하는지 확인합니다.
- 인증서의 확장 키가 예상 확장 키와 일치하는지 확인합니다.
- 이러한 검사 중 하나라도 실패하면 x.509 인증이 실패합니다. 그렇지 않으면 인증자가 인증서 ID를 추출하여 기존 사용자에게 매핑합니다.
인증서가 기존 사용자에게 매핑되면 인증 흐름에 따라 동작이 달라집니다.
- 브라우저 흐름에서 서버는 사용자에게 ID를 확인하거나 사용자 이름 및 암호를 사용하여 로그인하라는 메시지를 표시합니다.
- 직접 권한 부여 흐름에서 서버는 사용자에게 서명합니다.
웹 컨테이너는 인증서 PKIX 경로를 검증해야 합니다. Red Hat Single Sign-On 측의 X.509 인증기는 인증서 만료, 인증서 해지 상태 및 주요 사용량을 확인하는 추가 지원만 제공합니다. 역방향 프록시 뒤에 배포된 Red Hat Single Sign-On을 사용하는 경우 PKIX 경로의 유효성을 확인하도록 역방향 프록시가 구성되어 있는지 확인합니다. 역방향 프록시를 사용하지 않고 JBoss EAP에 직접 액세스하는 사용자를 사용하지 않는 경우 아래에 설명된 대로 PKIX 경로를 확인하는 동안 JBoss EAP를 통해 PKIX 경로를 검증해야 합니다.
8.5.1. 기능
지원되는 인증서 ID 소스:
- 정규 표현식을 사용하여 SubjectDN 일치
- X500 Subject의 email 특성
- 주체 대체 이름 확장 (RFC822Name 일반 이름)에서 X500 주체의 이메일
- X500 Subject의 다른 이름: Subject Alternative Name Extension. 이 다른 이름은 일반적으로 UPN(User Principal Name)입니다.
- X500 주체의 일반적인 이름 특성
- 정규식을 사용하여 IssuerDN 일치
- 인증서 일련 번호
- 인증서 일련 번호 및 IssuerDN
- SHA-256 인증서 지문
- PEM 형식의 전체 인증서
8.5.1.1. 정규 표현식
Red Hat Single Sign-On은 정규식을 필터로 사용하여 Subject DN 또는 Issuer DN에서 인증서 ID를 추출합니다. 예를 들어 이 정규식은 email 특성과 일치합니다.
emailAddress=(.*?)(?:,|$)
정규식 필터링은 ID 소스가 정규식 을
사용하여 일치하는 SubjectDN 또는 정규식을 사용하여
일치 IssuerDN
으로 설정된 경우 적용됩니다.
8.5.1.1.1. 기존 사용자에게 인증서 ID 매핑
인증서 ID 매핑은 추출된 사용자 ID를 인증서 ID와 일치하는 기존 사용자의 사용자 이름, 이메일 또는 사용자 지정 속성에 매핑할 수 있습니다. 예를 들어 ID 소스를
주체의 이메일 또는 사용자 매핑 방법으로
설정하면 X.509 클라이언트 인증서가 인증서 주체 DN의 email 속성을 사용자 이름별로 검색할 때 검색 기준으로 사용합니다.
- 영역 설정에서 이메일로 로그인을 비활성화하면 인증서 인증에 동일한 규칙이 적용됩니다. 사용자는 email 속성을 사용하여 로그인할 수 없습니다.
-
인증서 일련 번호 및 IssuerDN
을 ID 소스로 사용하려면 일련 번호와 IssuerDN에 대한 두 가지 사용자 지정 속성이 필요합니다. -
SHA-256 인증서 지문은 SHA-256 인증서 지문
의 소문자 16진수 표현입니다. -
PEM 형식의 전체 인증서를
ID 소스로 사용하는 것은 LDAP와 같은 외부 페더레이션 소스에 매핑된 사용자 지정 속성으로 제한됩니다. Red Hat Single Sign-On은 길이 제한으로 인해 데이터베이스에 인증서를 저장할 수 없으므로 LDAP의 경우 항상LDAP에서 항상 읽기 값을
활성화해야 합니다.
8.5.1.1.2. 확장 인증서 검증
- CRL을 사용한 해지 상태 점검.
- CRL/Distribution Point를 사용한 해지 상태 검사
- OCSP/Responder URI를 사용한 해지 상태 검사
- 인증서 키Usage 검증입니다.
- 인증서 ExtendedKeyUsage 검증.
8.5.2. X.509 클라이언트 인증서 사용자 인증 활성화
다음 섹션에서는 X.509 클라이언트 인증서 인증을 활성화하기 위해 JBoss EAP/Undertow 및 Red Hat Single Sign-On 서버를 구성하는 방법을 설명합니다.
8.5.2.1. JBoss EAP에서 상호 SSL 활성화
JBoss EAP에서 SSL을 활성화하는 방법은 SSL 사용을 참조하십시오.
- RHSSO_HOME/standalone/configuration/standalone.xml을 열고 새 영역을 추가합니다.
<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>
ssl/keystore
-
ssl
요소에는 JKS키 저장소
에서 서버 공개 키 쌍을 로드하기 위한 세부 정보가 포함된 키 저장소 요소가 포함되어 있습니다. ssl/keystore/path
- JKS 키 저장소의 경로입니다.
ssl/keystore/relative-to
- 키 저장소 경로가 상대 경로인 경로입니다.
ssl/keystore/keystore-password
- 키 저장소를 여는 암호입니다.
SSL/키store/alias
(선택 사항)- 키 저장소의 항목 별칭입니다. 키 저장소에 여러 항목이 포함된 경우 설정됩니다.
SSL/keystore/key-password
(선택 사항)- 키 저장소 암호와 다른 경우 개인 키 암호입니다.
authentication/truststore
- 인바운드/outgoing 연결의 원격 측에서 제공하는 인증서를 확인하기 위해 신뢰 저장소를 로드하는 방법을 정의합니다. 일반적으로 신뢰 저장소에는 신뢰할 수 있는 CA 인증서 컬렉션이 포함되어 있습니다.
authentication/truststore/path
- 신뢰할 수 있는 인증 기관의 인증서가 포함된 JKS 키 저장소의 경로입니다.
authentication/truststore/relative-to
- 신뢰 저장소 경로가 상대적인 경로입니다.
authentication/truststore/keystore-password
- 신뢰 저장소를 여는 암호입니다.
8.5.2.2. HTTPS 리스너 활성화
WildFly에서 HTTPS를 활성화하는 방법은 HTTPS Listener 를 참조하십시오.
- <https-listener> 요소를 추가합니다.
<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>
https-listener/security-realm
- 이 값은 이전 섹션의 영역 이름과 일치해야 합니다.
https-listener/verify-client
- REQUESTED 로 설정하면 서버에서 필요한 경우 클라이언트 인증서를 요청합니다. REQUIRED 로 설정하면 클라이언트 인증서가 제공되지 않은 경우 서버에서 인바운드 연결을 거부합니다.
8.5.3. 브라우저 흐름에 X.509 클라이언트 인증서 인증 추가
- 메뉴에서 인증을 클릭합니다.
- "Forwardedr" 흐름을 클릭합니다.
- 복사를 클릭하여 내장된 "LoadBalancerr" 흐름의 사본을 만듭니다.
- 복사의 이름을 입력합니다.
- 확인을 클릭합니다.
- 정책 추가 드롭다운 상자에서 사본을 클릭합니다.
- 실행 추가를 클릭합니다.
- "X509/Validate Username Form"을 클릭합니다.
저장을 클릭합니다.
X509 실행
- 위쪽/다운 화살표 버튼을 클릭하여 'X509/Validate Username Form'을 이동합니다.
요구 사항을 "ALTERNATIVE"로 설정합니다.
X509 브라우저 흐름
- 바인딩 탭을 클릭합니다.
- browsers flow 드롭다운 목록을 클릭합니다.
- 드롭다운 목록에서 브라우저 흐름의 사본을 클릭합니다.
저장을 클릭합니다.
X509 브라우저 흐름 바인딩
8.5.4. X.509 클라이언트 인증서 인증 구성
X509 구성
- 사용자 ID 소스
- 클라이언트 인증서에서 사용자 ID를 추출하는 방법을 정의합니다.
- 표준 DN 표현 활성화
- 정식 형식을 사용하여 고유 이름을 결정할지 여부를 정의합니다. 공식 Java API 문서에서는 형식을 설명합니다. 이 옵션은 정규식을 사용하는 두 개의 User Identity Sources Match SubjectDN과 정규식 만 사용하여 일치 IssuerDN 에 영향을 줍니다. 새 Red Hat Single Sign-On 인스턴스를 설정하는 경우 이 옵션을 활성화합니다. 기존 Red Hat Single Sign-On 인스턴스와 이전 버전과의 호환성을 유지하려면 이 옵션을 비활성화합니다.
- 일련 번호 16진수 표시 활성화
- 일련 번호를 16진수로 나타냅니다. 부호 비트가 1로 설정된 일련 번호는 00 색으로 채워집니다. 예를 들어 10진수 값이 161 인 일련번호 또는 16진수 표현의 a1 은 RFC5280에 따라 00a1 로 인코딩됩니다. 자세한 내용은 RFC5280, appendix-B 를 참조하십시오.
- 정규 표현식
- 인증서 ID를 추출하는 필터로 사용할 정규식입니다. 식에는 단일 그룹이 포함되어야 합니다.
- 사용자 매핑 방법
- 기존 사용자와 인증서 ID를 일치시키는 메서드를 정의합니다. 사용자 이름 또는 이메일 은 사용자 이름 또는 이메일을 통해 기존 사용자를 검색합니다. 사용자 정의 속성 맵퍼는 인증서 ID와 일치하는 사용자 지정 속성을 사용하여 기존 사용자를 검색합니다. 사용자 정의 속성의 이름은 구성할 수 있습니다.
- 사용자 속성의 이름
- 인증서 ID와 일치하는 사용자 정의 속성입니다. 속성 매핑이 여러 값과 관련된 경우 여러 사용자 지정 속성을 사용합니다(예: 'Certificate Serial Number 및 IssuerDN').
- CRL 검사 활성화됨
- 인증서 해지 목록을 사용하여 인증서 해지 상태를 확인합니다. 목록의 위치는 CRL 파일 경로 속성에 정의되어 있습니다.
- CRL 배포 포인트에서 인증서 해지 상태를 확인할 수 있습니다.
- CDP를 사용하여 인증서 해지 상태를 확인합니다. 대부분의 PKI 기관에는 인증서에 CDP가 포함됩니다.
- CRL 파일 경로
- CRL 목록이 포함된 파일의 경로입니다. CRL Checking Enabled 옵션이 활성화된 경우 값은 유효한 파일의 경로여야 합니다.
- OCSP 검사 활성화
- 온라인 인증서 상태 프로토콜을 사용하여 인증서 해지 상태를 확인합니다.
- OCSP Fail-Open vsphere
- 기본적으로 OCSP 검사는 성공적인 인증을 계속 진행하기 위해 양수 응답을 반환해야 합니다. 그러나 경우에 따라 이 검사에 불일치할 수 있습니다. 예를 들어 OCSP 서버에 연결할 수 없거나 과부하되거나 클라이언트 인증서에 OCSP 응답자 URI가 포함되지 않을 수 있습니다. 이 설정을 설정하면 OCSP 응답자가 명시적인 음수 응답이 수신되고 인증서가 명확하게 취소되는 경우에만 인증이 거부됩니다. 유효한 OCSP 응답이 유효하지 않은 경우 인증 시도가 수락됩니다.
- OCSP 반응기 URI
- 인증서의 OCSP 응답자 URI 값을 재정의합니다.
- 키 사용량 검증
- 인증서의 KeyUsage 확장 비트가 설정되어 있는지 확인합니다. 예를 들어 "digitalSignature,KeyEncipherment"는 KeyUsage 확장에서 비트 0 및 2가 설정되어 있는지 확인합니다. Key Usage 검증을 비활성화하려면 이 매개변수를 비워 둡니다. 자세한 내용은 RFC5280, Section-4.2.1.3 을 참조하십시오. Red Hat Single Sign-On은 주요 사용량 불일치가 발생할 때 오류가 발생합니다.
- 확장된 키 사용량 검증
- 확장 키 사용량 확장에 정의된 하나 이상의 용도를 확인합니다. 자세한 내용은 RFC5280, Section-4.2.1.12 을 참조하십시오. Extended Key Usage 검증을 비활성화하려면 이 매개변수를 비워 둡니다. Red Hat Single Sign-On은 발급된 CA의 문제로 플래그가 지정되면 오류가 발생하고 주요 사용량 확장 불일치가 발생합니다.
- 인증서 정책 검증
- 인증서 정책 확장에 정의된 하나 이상의 정책 OID를 확인합니다. RFC5280, Section-4.2.1.4 를 참조하십시오. 인증서 정책 검증을 비활성화하려면 매개변수를 비워 둡니다. 여러 정책을 쉼표로 구분해야 합니다.
- 인증서 정책 유효성 검사 모드
-
검증 인증서 정책
설정에 둘 이상의 정책이 지정되면 일치에서 모든 요청된 정책이 존재하는지 아니면 하나의 일치가 성공적인 인증을 위해 충분한지 여부를 결정합니다. 기본값은모두
입니다. 즉, 요청된 모든 정책이 클라이언트 인증서에 있어야 합니다. - ID 확인 우회
- 활성화된 경우 X.509 클라이언트 인증서 인증이 사용자에게 인증서 ID를 확인하라는 메시지를 표시하지 않습니다. 성공적인 인증 시 사용자에게 Red Hat Single Sign-On 서명.
- 클라이언트 인증서 재검사
- 설정되어 있는 경우 클라이언트 인증서 신뢰 체인은 구성된 신뢰 저장소에 있는 인증서를 사용하여 애플리케이션 수준에서 항상 확인합니다. 이는 기본 웹 서버가 클라이언트 인증서 체인 검증을 적용하지 않는 경우, 예를 들어 평가되지 않은 로드 밸런서 또는 역방향 프록시 뒤에 있기 때문에 또는 허용되는 CA 수가 상호 SSL 협상에 비해 너무 큰 경우(대부분의 브라우저가 약 200개의 공개된 CA에 해당하는 최대 SSL 협상 패킷 크기를 제한함)할 때 유용할 수 있습니다. 기본적으로 이 옵션은 해제되어 있습니다.
8.5.5. 직접 권한 부여 흐름에 X.509 클라이언트 인증서 인증 추가
- 메뉴에서 인증을 클릭합니다.
- "Direct Grant" 흐름을 클릭합니다.
- 복사를 클릭하여 "Direct Grant" 흐름의 사본을 만듭니다.
- 복사의 이름을 입력합니다.
- 확인을 클릭합니다.
- "사용자 이름 유효성 검사"에 대한 Actions 링크를 클릭하고 삭제 를 클릭합니다.
- 삭제를 클릭합니다.
- "Password"에 대한 Actions 링크를 클릭하고 삭제 를 클릭합니다.
- 삭제를 클릭합니다.
- 실행 추가를 클릭합니다.
- "X509/Validate Username"을 클릭합니다.
저장을 클릭합니다.
X509 직접 부여 실행
- x509 browser Flow 섹션에 설명된 단계에 따라 x509 인증 구성을 설정합니다.
- 바인딩 탭을 클릭합니다.
- Direct Grant Flow 드롭다운 목록을 클릭합니다.
- 새로 생성된 "x509 Direct Grant" 흐름을 클릭합니다.
저장을 클릭합니다.
X509 직접 부여 흐름 바인딩
8.5.6. 클라이언트 인증서 조회
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
라는 두 개의 추가 기본 제공 공급자가 있습니다.
8.5.6.1. HAProxy 인증서 조회 공급자
Red Hat Single Sign-On 서버가 HAProxy 역방향 프록시 뒤에 있는 경우 이 공급자를 사용합니다. 서버에 다음 구성을 사용합니다.
<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>
이 예제 구성에서 클라이언트 인증서는 HTTP 헤더, SSL_CLIENT_CERT
에서 검색되고, 체인의 다른 인증서는 NetRT_ CHAIN_0 ~ hieradataRT_
와 같은 HTTP 헤더에서 검색됩니다. 속성 CHAIN_
9certificateECDHELength는 체인
의 최대 길이이므로 마지막 속성은 ovirtRT _CHAIN_9
입니다.
클라이언트 인증서 및 클라이언트 인증서 체인에 대한 HTTP 헤더 구성에 대한 자세한 내용은 HAProxy 설명서를 참조하십시오.
8.5.6.2. Apache 인증서 조회 공급자
Red Hat Single Sign-On 서버가 Apache 역방향 프록시 뒤에 있는 경우 이 공급자를 사용할 수 있습니다. 서버에 다음 구성을 사용합니다.
<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>
이 구성은 haproxy
공급자와 동일합니다. 클라이언트 인증서 및 클라이언트 인증서 체인의 HTTP 헤더가 구성된 방법에 대한 자세한 내용은 mod_ssl 및 mod_headers 의 Apache 설명서를 참조하십시오.
8.5.6.3. NGINX 인증서 조회 공급자
Red Hat Single Sign-On 서버가 NGINX 역방향 프록시 뒤에 있는 경우 이 공급자를 사용할 수 있습니다. 서버에 다음 구성을 사용합니다.
<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>
NGINX SSL/TLS 모듈은 클라이언트 인증서 체인을 노출하지 않습니다. Red Hat Single Sign-On의 NGINX 인증서 조회 공급자는 Keycloak 신뢰 저장소를 사용하여 다시 빌드합니다. 키tool CLI를 모든 루트 및 중간 CA의 클라이언트 인증서 체인을 다시 작성하여 Red Hat Single Sign-On 신뢰 저장소를 채웁니다.
클라이언트 인증서에 대한 HTTP 헤더 구성에 대한 자세한 내용은 NGINX 설명서를 참조하십시오.
NGINX 구성 파일의 예:
... 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; ... } ... }
trusted-ca-list-for-client-auth.pem의 모든 인증서를 Keycloak 신뢰 저장소에 추가해야 합니다.
8.5.6.4. 기타 역방향 프록시 구현
Red Hat Single Sign-On은 다른 역방향 프록시 구현을 지원하지 않습니다. 그러나 apache
또는 haproxy
와 유사한 방식으로 다른 역방향 프록시가 작동하도록 할 수 있습니다. 이러한 작업이 없는 경우
및 org.keycloak.services.x509ClientCertificateLookup 공급자 구현을 생성합니다. 공급자를 추가하는 방법에 대한 자세한 내용은 서버 개발자 가이드를 참조하십시오.
org.keycloak.services.x509.X509ClientCertificateLookup
Factory
8.5.7. 문제 해결
- HTTP 헤더 덤프
-
역방향 프록시가 Keycloak으로 전송하는 내용을 보려면
RequestDumpingHandler
filter를 활성화하고server.log
파일을 참조합니다. - 로깅 하위 시스템에서 TRACE 로깅 활성화
... <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>
프로덕션에서 RequestDumpingHandler 또는 TRACE 로깅을 사용하지 마십시오.
- X.509를 사용한 직접 권한 부여
이 인증을 수행하려면 다음이 필요합니다.
- 루트 CA 및 중간 CA
- 루트 CA/중간 CA로 서명된 사용자 서명된 인증서 요청
다음 템플릿을 사용하여 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" }
[host][:port]
- 원격 Red Hat Single Sign-On 서버의 호스트 및 포트 번호입니다.
user_cert.crt
- 사용자를 위한 공개 키입니다.
user_cert.key
- 사용자의 개인 키입니다. 이 키는 공개 키가 위조되지 않았는지 확인합니다. 개인 키는 공개 키와 동일한 해시를 가리킵니다.
CLIENT_ID
- 클라이언트 ID입니다.
CLIENT_SECRET
- 기밀 클라이언트의 경우 고객 시크릿입니다.