8.5. 발신 HTTP 요청
Red Hat Single Sign-On 서버는 보호되는 애플리케이션 및 서비스에 대해 브라우저 이외의 HTTP 요청을 수행해야 하는 경우가 많습니다. auth 서버는 HTTP 클라이언트 연결 풀을 유지 관리하여 발신 연결을 관리합니다. standalone.xml,standalone-ha.xml 또는 domain.xml 에서 구성해야 할 몇 가지 사항이 있습니다. 이 파일의 위치는 작동 모드에 따라 다릅니다.
HTTP 클라이언트 구성 예
<spi name="connectionsHttpClient">
<provider name="default" enabled="true">
<properties>
<property name="connection-pool-size" value="256"/>
</properties>
</provider>
</spi>
가능한 구성 옵션은 다음과 같습니다.
- establish-connection-timeout-millis
- 소켓 연결을 설정하는 데 필요한 시간 초과입니다.
- socket-timeout-millis
- 발신 요청에서 이 시간 동안 데이터를 수신하지 못하면 연결 시간 초과입니다.
- connection-pool-size
- 풀에 있을 수 있는 연결 수(기본적으로 128개) 수입니다.
- max-pooled-per-route
- 호스트당 풀링할 수 있는 연결 수입니다(기본적으로 64개).
- connection-ttl-millis
- 최대 연결 시간(밀리초)입니다. 기본적으로 설정되지 않습니다.
- max-connection-idle-time-millis
-
연결이 연결 풀에서 유휴 상태를 유지할 수 있는 최대 시간(기본적으로 900초). Apache HTTP 클라이언트의 백그라운드 정리 스레드를 시작합니다. 이 검사 및 백그라운드 스레드를 비활성화하려면
-1로 설정합니다. - disable-cookies
-
기본적으로
true입니다. true로 설정하면 모든 쿠키 캐싱이 비활성화됩니다. - client-keystore
- Java 키 저장소 파일의 파일 경로입니다. 이 키 저장소에는 양방향 SSL에 대한 클라이언트 인증서가 포함되어 있습니다.
- client-keystore-password
-
클라이언트 키 저장소의 암호입니다.
client-keystore가 설정된 경우 REQUIRED 입니다. - client-key-password
-
클라이언트 키의 암호입니다.
client-keystore가 설정된 경우 REQUIRED 입니다. - proxy-mappings
- 발신 HTTP 요청에 대한 프록시 구성을 나타냅니다. 자세한 내용은 HTTP 요청의 프록시 매핑 섹션을 참조하십시오.
- disable-trust-manager
-
발신 요청에 HTTPS가 필요하며 이 구성 옵션이
true로 설정된 경우 truststore를 지정할 필요가 없습니다. 이 설정은 개발 중에만 사용해야 하며, SSL 인증서 확인을 비활성화하므로 프로덕션에서는 사용하지 않아야 합니다. 이것은 선택 사항입니다. 기본값은false입니다.
8.5.1. 발신 HTTP 요청에 대한 프록시 매핑 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat Single Sign-On에서 보낸 발신 HTTP 요청은 선택적으로 프록시 매핑의 쉼표로 구분된 목록을 기반으로 프록시 서버를 사용할 수 있습니다. proxy-mapping은 hostnamePattern;proxyUri 형식으로 regex 기반 호스트 이름 패턴과 proxy-uri의 조합을 나타냅니다. 예를 들면 다음과 같습니다.
.*\.(google|googleapis)\.com;http://www-proxy.acme.com:8080
나가는 HTTP 요청의 프록시를 확인하기 위해 대상 호스트 이름이 구성된 호스트 이름 패턴과 일치합니다. 첫 번째 일치 패턴은 사용할 proxy-uri를 결정합니다. 지정된 호스트 이름과 일치하는 패턴이 없는 경우 프록시가 사용되지 않습니다.
프록시 서버에 인증이 필요한 경우 이 형식의 proxy 사용자 자격 증명을 username:password@. 예를 들면 다음과 같습니다.
.*\.(google|googleapis)\.com;http://user01:pas2w0rd@www-proxy.acme.com:8080
proxy-uri의 특수 값 NO_PROXY 를 사용하여 연결된 호스트 이름 패턴과 일치하는 호스트에 프록시를 사용하지 않아야 함을 나타낼 수 있습니다. 프록시 매핑 끝에 catch-all 패턴을 지정하여 나가는 모든 요청에 대한 기본 프록시를 정의할 수 있습니다.
다음 예제는 프록시 매핑 구성을 보여줍니다.
# All requests to Google APIs should use http://www-proxy.acme.com:8080 as proxy
.*\.(google|googleapis)\.com;http://www-proxy.acme.com:8080
# All requests to internal systems should use no proxy
.*\.acme\.com;NO_PROXY
# All other requests should use http://fallback:8080 as proxy
.*;http://fallback:8080
이는 다음 jboss-cli 명령을 통해 구성할 수 있습니다. 다음과 같이 regex-pattern을 올바르게 이스케이프해야 합니다.
echo SETUP: Configure proxy routes for HttpClient SPI
# In case there is no connectionsHttpClient definition yet
/subsystem=keycloak-server/spi=connectionsHttpClient/provider=default:add(enabled=true)
# Configure the proxy-mappings
/subsystem=keycloak-server/spi=connectionsHttpClient/provider=default:write-attribute(name=properties.proxy-mappings,value=[".*\\.(google|googleapis)\\.com;http://www-proxy.acme.com:8080",".*\\.acme\\.com;NO_PROXY",".*;http://fallback:8080"])
jboss-cli 명령을 실행하면 다음과 같은 하위 시스템 구성이 생성됩니다. " 문자를 "로 인코딩해야 합니다.
<spi name="connectionsHttpClient">
<provider name="default" enabled="true">
<properties>
<property
name="proxy-mappings"
value="[".*\\.(google|googleapis)\\.com;http://www-proxy.acme.com:8080",".*\\.acme\\.com;NO_PROXY",".*;http://fallback:8080"]"/>
</properties>
</provider>
</spi>
8.5.2. 표준 환경 변수 사용 링크 복사링크가 클립보드에 복사되었습니다!
또는 표준 환경 변수를 사용하여 HTTP_PROXY,HTTPS_PROXY 및 NO_PROXY 변수인 프록시 매핑을 구성할 수 있습니다.
HTTP_PROXY 및 HTTPS_PROXY 변수는 나가는 모든 HTTP 요청에 사용해야 하는 프록시 서버를 나타냅니다. Red Hat Single Sign-On은 둘 간에 차이가 없습니다. 둘 다 지정하면 프록시 서버가 사용하는 실제 체계에 관계없이 HTTPS_PROXY 가 우선 순위를 갖습니다.
NO_PROXY 변수는 프록시를 사용하지 않아야 하는 쉼표로 구분된 호스트 이름 목록을 정의하는 데 사용됩니다. 호스트 이름이 지정되면 모든 접두사(subdomains)도 proxy 사용에서 제외됩니다.
다음 예제를 참조하십시오.
HTTPS_PROXY=https://www-proxy.acme.com:8080
NO_PROXY=google.com,login.facebook.com
이 예에서 나가는 모든 HTTP 요청은 login.google.com,google.com,auth.login.facebook.com 과 같은 요청을 제외하고 https://www-proxy.acme.com:8080 프록시 서버를 사용합니다. 그러나 예를 들어 groups.facebook.com 은 프록시를 통해 라우팅됩니다.
환경 변수는 소문자 또는 대문자일 수 있습니다. 소문자가 우선합니다. 예를 들어 HTTP_PROXY 및 http_proxy 가 모두 정의되면 http_proxy 가 사용됩니다.
위에 설명된 대로 하위 시스템 구성을 사용하여 프록시 매핑을 정의하는 경우 환경 변수는 Red Hat Single Sign-On에서 고려하지 않습니다. 이 시나리오는 정의된 HTTP_PROXY 환경 변수의 보유에도 불구하고 프록시 서버를 사용하지 않는 경우에 적용됩니다. 이를 위해 다음과 같이 일반 프록시 경로를 지정할 수 있습니다.
<spi name="connectionsHttpClient">
<provider name="default" enabled="true">
<properties>
<property name="proxy-mappings" value=".*;NO_PROXY"/>
</properties>
</provider>
</spi>
8.5.3. 발신 HTTPS 요청 신뢰 저장소 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat Single Sign-On이 원격 HTTPS 엔드포인트에서 호출되면 원격 서버의 인증서가 신뢰할 수 있는 서버에 연결되어 있는지 확인해야 합니다. 이는 메시지 가로채기(man-in-the-middle) 공격을 방지하기 위해 필요합니다. 이러한 원격 서버 또는 이러한 인증서에 서명한 CA의 인증서는 신뢰 저장소에 배치해야 합니다. 이 신뢰 저장소는 Red Hat Single Sign-On 서버에서 관리합니다.
신뢰의 구성은 항상 Red Hat Single Sign-On 신뢰 저장소 SPI에서 수행합니다. 이 섹션의 지침은 JBoss Security Legacy 또는 Elytron TLS로 키 저장소를 구성한 경우 적용됩니다.
신뢰 저장소는 ID 브로커, LDAP ID 공급자, 이메일을 보낼 때, 클라이언트 애플리케이션과 백채널 통신할 때 사용됩니다.
기본적으로 신뢰 저장소 공급자는 구성되지 않으며 Java의 JSSE 참조 가이드에 설명된 대로 https 연결은 표준 java truststore 구성으로 대체됩니다. 설정된 신뢰가 없으면 발신되는 HTTPS 요청이 실패합니다.
keytool 을 사용하여 새 신뢰 저장소 파일을 생성하거나 신뢰할 수 있는 호스트 인증서를 기존에 추가할 수 있습니다.
$ keytool -import -alias HOSTDOMAIN -keystore truststore.jks -file host-certificate.cer
신뢰 저장소는 배포의 standalone.xml,standalone-ha.xml 또는 domain.xml 파일 내에 구성됩니다. 이 파일의 위치는 작동 모드에 따라 다릅니다. 다음 템플릿을 사용하여 신뢰 저장소 구성을 추가할 수 있습니다.
<spi name="truststore">
<provider name="file" enabled="true">
<properties>
<property name="file" value="path to your .jks file containing public certificates"/>
<property name="password" value="password"/>
<property name="hostname-verification-policy" value="WILDCARD"/>
</properties>
</provider>
</spi>
이 설정에 사용 가능한 구성 옵션은 다음과 같습니다.
- file
- Java 키 저장소 파일의 경로입니다. HTTPS 요청은 통신 중인 서버의 호스트를 확인하는 방법이 필요합니다. 이것이 신뢰가 하는 것입니다. 키 저장소에는 하나 이상의 신뢰할 수 있는 호스트 인증서 또는 인증 기관이 포함됩니다. 이 신뢰 저장소 파일에는 보안 호스트의 공용 인증서만 포함되어야 합니다. 이러한 속성이 정의된 경우 REQUIRED 입니다.
- 암호
- 키 저장소의 암호입니다. 이러한 속성이 정의된 경우 REQUIRED 입니다.
- hostname-verification-policy
-
기본적으로
WILDCARD입니다. HTTPS 요청의 경우 서버 인증서의 호스트 이름을 확인합니다.어떠한 경우에도호스트 이름이 확인되지 않음을 의미합니다.WILDCARD는 하위 도메인 이름(예: *.foo.com)에서 와일드카드를 허용합니다.STRICTCN은 호스트 이름과 정확히 일치해야 합니다.