서버 설치 및 구성 가이드

Red Hat Single Sign-On은 JBoss EAP 애플리케이션 서버 및 Infinispan(캐스팅용) 및 Hibernate(속도용)와 같은 하위 프로젝트를 기반으로 구축됩니다. 이 가이드에서는 인프라 수준 구성의 기본 사항만 다룹니다. JBoss EAP 및 해당 하위 프로젝트에 대한 문서를 사용하는 것이 좋습니다. 문서에 대한 링크는 다음과 같습니다.

다음은 Red Hat Single Sign-On 인증 서버를 실행하기 위한 요구 사항입니다.

Red Hat Single Sign-On 서버 다운로드 ZIP 파일에는 Red Hat Single Sign-On 서버를 실행하는 스크립트 및 바이너리가 포함되어 있습니다. 먼저 7.4.0.GA 서버를 설치한 다음 7.4.10.GA 서버 패치를 설치합니다.

RPM에서 RH-SSO를 설치하려면 JBoss EAP 7.3 및 RH-SSO 7.4 리포지토리를 모두 구독해야 합니다.

subscription-manager repos --enable=jb-eap-7.3-for-rhel-<RHEL_VERSION>-server-rpms --enable=rhel-<RHEL_VERSION>-server-rpms

subscription-manager repos --enable=jb-eap-7.3-for-rhel-8-x86_64-rpms --enable=rhel-8-for-x86_64-baseos-rpms --enable=rhel-8-for-x86_64-appstream-rpms

이 장에서는 서버 배포의 디렉터리 구조를 안내합니다.

일부 디렉토리의 목적을 살펴보겠습니다.

독립 실행형 운영 모드는 하나의 Red Hat Single Sign-On 서버 인스턴스만 실행하려는 경우에만 유용합니다. 클러스터형 배포에는 사용할 수 없으며 모든 캐시는 배포되지 않고 로컬 전용입니다. 단일 장애 지점이 있으므로 프로덕션에서 독립 실행형 모드를 사용하지 않는 것이 좋습니다. 독립 실행형 모드 서버가 다운되면 사용자가 로그인할 수 없습니다. 이 모드는 Red Hat Single Sign-On의 기능을 사용하여 드라이브를 테스트하고 플레이하는 데에만 유용합니다.

$ .../bin/standalone.sh

> ...\bin\standalone.bat

독립 실행형 클러스터형 작동 모드는 클러스터 내에서 Red Hat Single Sign-On을 실행하려는 경우입니다. 이 모드에서는 서버 인스턴스를 실행하려는 각 머신에 Red Hat Single Sign-On 배포 사본이 있어야 합니다. 이 모드는 처음에 배포하기가 매우 쉽지만 매우 번거로울 수 있습니다. 구성을 변경하려면 각 시스템에서 각 배포를 수정해야 합니다. 대규모 클러스터의 경우 시간이 오래 걸릴 수 있으며 오류가 발생하기 쉽습니다.

$ .../bin/standalone.sh --server-config=standalone-ha.xml

> ...\bin\standalone.bat --server-config=standalone-ha.xml

도메인 모드는 서버의 구성을 중앙에서 관리하고 게시하는 방법입니다.

표준 모드에서 클러스터를 실행하면 클러스터가 크기가 증가함에 따라 빠르게 악화될 수 있습니다. 구성을 변경해야 할 때마다 클러스터의 각 노드에서 수행해야 합니다. 도메인 모드는 구성을 저장하고 게시하는 중앙 위치를 제공하여 이 문제를 해결합니다. 설정하는 것은 매우 복잡할 수 있지만 결국 가치가 있습니다. 이 기능은 Red Hat Single Sign-On이 파생되는 JBoss EAP Application Server에 빌드됩니다.

다음은 도메인 모드에서 실행의 몇 가지 기본 개념입니다.

도메인 모드에서는 마스터 노드에서 도메인 컨트롤러가 시작됩니다. 클러스터 구성은 도메인 컨트롤러에 있습니다. 다음으로 클러스터의 각 시스템에서 호스트 컨트롤러가 시작됩니다. 각 호스트 컨트롤러 배포 구성은 해당 시스템에서 시작할 Red Hat Single Sign-On 서버 인스턴스 수를 지정합니다. 호스트 컨트롤러가 부팅되면 이를 수행하도록 구성된 만큼 Red Hat Single Sign-On 서버 인스턴스가 시작됩니다. 이러한 서버 인스턴스는 도메인 컨트롤러에서 구성을 가져옵니다.

    <profiles>
        <profile name="auth-server-standalone">
            ...
        </profile>
        <profile name="auth-server-clustered">
            ...
        </profile>

    <socket-binding-groups>
        <socket-binding-group name="standard-sockets" default-interface="public">
           ...
        </socket-binding-group>
        <socket-binding-group name="ha-sockets" default-interface="public">
           ...
        </socket-binding-group>
        <!-- load-balancer-sockets should be removed in production systems and replaced with a better software or hardware based one -->
        <socket-binding-group name="load-balancer-sockets" default-interface="public">
           ...
        </socket-binding-group>
    </socket-binding-groups>

$ domain.sh -Djboss.http.port=80

    <server-groups>
        <!-- load-balancer-group should be removed in production systems and replaced with a better software or hardware based one -->
        <server-group name="load-balancer-group" profile="load-balancer">
            <jvm name="default">
                <heap size="64m" max-size="512m"/>
            </jvm>
            <socket-binding-group ref="load-balancer-sockets"/>
        </server-group>
        <server-group name="auth-server-group" profile="auth-server-clustered">
            <jvm name="default">
                <heap size="64m" max-size="512m"/>
            </jvm>
            <socket-binding-group ref="ha-sockets"/>
        </server-group>
    </server-groups>

    <servers>
        <!-- remove or comment out next line -->
        <server name="load-balancer" group="loadbalancer-group"/>
        ...
    </servers>

    <servers>
        ...
        <server name="server-one" group="auth-server-group" auto-start="true">
             <socket-bindings port-offset="150"/>
        </server>
    </servers>

$ .../bin/domain.sh --host-config=host-master.xml

> ...\bin\domain.bat --host-config=host-master.xml

$ add-user.sh
 What type of user do you wish to add?
  a) Management User (mgmt-users.properties)
  b) Application User (application-users.properties)
 (a): a
 Enter the details of the new user to add.
 Using realm 'ManagementRealm' as discovered from the existing property files.
 Username : admin
 Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
  - The password should not be one of the following restricted values {root, admin, administrator}
  - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
  - The password should be different from the username
 Password :
 Re-enter Password :
 What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]:
 About to add user 'admin' for realm 'ManagementRealm'
 Is this correct yes/no? yes
 Added user 'admin' to file '/.../standalone/configuration/mgmt-users.properties'
 Added user 'admin' to file '/.../domain/configuration/mgmt-users.properties'
 Added user 'admin' with groups to file '/.../standalone/configuration/mgmt-groups.properties'
 Added user 'admin' with groups to file '/.../domain/configuration/mgmt-groups.properties'
 Is this new user going to be used for one AS process to connect to another AS process?
 e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
 yes/no? yes
 To represent the user add the following to the server-identities definition <secret value="bWdtdDEyMyE=" />

     <management>
         <security-realms>
             <security-realm name="ManagementRealm">
                 <server-identities>
                     <secret value="bWdtdDEyMyE="/>
                 </server-identities>

     <remote security-realm="ManagementRealm" username="admin">

$ domain.sh --host-config=host-master.xml

$ domain.sh --host-config=host-slave.xml

Red Hat Single Sign-On 7.2에서 기술 프리뷰 기능으로 도입된 교차 사이트 복제는 최신 RH-SSO 7.6 릴리스를 포함한 Red Hat SSO 7.x 릴리스에서 지원되는 기능으로 더 이상 사용할 수 없습니다. Red Hat은 지원되지 않으므로 고객 구현 또는 해당 환경에서 이 기능을 사용하지 않는 것이 좋습니다. 또한 이 기능에 대한 지원 예외는 더 이상 고려되거나 허용되지 않습니다.

사이트 간 복제를 위한 새로운 솔루션은 Red Hat SSO 8 대신 도입될 제품인RHBK(Red Hat build of Keycloak)의 향후 릴리스에 대해 지속적으로 고려하고 있습니다. 자세한 내용은 곧 제공될 예정입니다.

각 구성 설정의 세부 사항은 해당 설정과 관련된 다른 위치에서 설명합니다. 그러나 SPI 공급자의 설정을 선언하는 데 사용되는 형식을 이해하는 것이 유용합니다.

Red Hat Single Sign-On은 뛰어난 유연성을 제공하는 모듈식 시스템입니다. 50개 이상의 SPI(서비스 공급자 인터페이스)가 있으며 각 SPI 구현을 스왑 아웃할 수 있습니다. SPI의 구현은 공급자 라고 합니다.

SPI 선언의 모든 요소는 선택 사항이지만 전체 SPI 선언은 다음과 같습니다.

<spi name="myspi">
    <default-provider>myprovider</default-provider>
    <provider name="myprovider" enabled="true">
        <properties>
            <property name="foo" value="bar"/>
        </properties>
    </provider>
    <provider name="mysecondprovider" enabled="true">
        <properties>
            <property name="foo" value="foo"/>
        </properties>
    </provider>
</spi>

여기 SPI myspi 에 대해 정의된 두 개의 공급자가 있습니다. default-provider 는 myprovider 로 나열됩니다. 그러나 SPI는 이 설정을 처리하는 방법을 결정합니다. 일부 SPI는 두 개 이상의 공급자를 허용하고 일부는 제공하지 않습니다. 따라서 default-provider 는 SPI를 선택하는 데 도움이 될 수 있습니다.

또한 각 공급자는 고유한 구성 속성 세트를 정의합니다. 위의 두 공급자에 모두 foo 라는 속성이 있다는 사실은 단순히 비만입니다.

각 속성 값의 유형은 공급자가 해석합니다. 그러나 한 가지 예외가 있습니다. eventsStore SPI의 jpa 공급자를 고려하십시오.

<spi name="eventsStore">
    <provider name="jpa" enabled="true">
        <properties>
            <property name="exclude-events" value="[&quot;EVENT1&quot;,
                                                    &quot;EVENT2&quot;]"/>
        </properties>
    </provider>
</spi>

이 값은 대괄호로 시작하고 대괄호로 끝나는 것을 알 수 있습니다. 즉, 값이 공급자에게 목록으로 전달됩니다. 이 예제에서 시스템은 두 개의 요소 값이 있는 목록을 공급자에게 전달합니다. 목록에 값을 더 추가하려면 각 목록 요소를 쉼표로 구분합니다. 안타깝게도 각 목록 요소 옆에 있는 따옴표를 이스케이프해야 합니다.

구성을 직접 편집하는 것 외에도 jboss-cli 툴을 통해 명령을 실행하여 구성을 변경할 수도 있습니다. CLI를 사용하면 서버를 로컬 또는 원격으로 구성할 수 있습니다. 스크립팅과 결합할 때 특히 유용합니다.

JBoss EAP CLI를 시작하려면 jboss-cli 를 실행해야 합니다.

$ .../bin/jboss-cli.sh

> ...\bin\jboss-cli.bat

이렇게 하면 다음과 같은 프롬프트가 표시됩니다.

[disconnected /]

실행 중인 서버에서 명령을 실행하려면 먼저 connect 명령을 실행합니다.

[disconnected /] connect
connect
[standalone@localhost:9990 /]

자신을 생각하고 있을 수 있습니다. "사용자 이름이나 비밀번호를 입력하지 않았습니다!" 실행 중인 독립 실행형 서버 또는 도메인 컨트롤러와 동일한 시스템에서 jboss-cli 를 실행하고 계정에 적절한 파일 권한이 있는 경우 관리자 사용자 이름과 암호를 설정하거나 입력할 필요가 없습니다. 해당 설정을 사용하지 않는 경우 보안을 강화하는 방법에 대한 자세한 내용은 JBoss EAP 구성 가이드를 참조하십시오.

독립 실행형 서버와 동일한 머신에 있고 서버가 활성 상태가 아닌 동안 명령을 실행하려는 경우 서버를 CLI에 삽입하고 들어오는 요청을 허용하지 않는 특수 모드를 변경할 수 있습니다. 이렇게 하려면 변경하려는 구성 파일을 사용하여 embed-server 명령을 실행합니다.

[disconnected /] embed-server --server-config=standalone.xml
[standalone@embedded /]

CLI는 GUI 모드에서도 실행할 수 있습니다. GUI 모드는 실행 중인 서버의 전체 관리 모델을 그래픽으로 보고 편집할 수 있는 Swing 애플리케이션을 시작합니다. GUI 모드는 CLI 명령을 포맷하고 사용 가능한 옵션에 대해 학습하는 데 도움이 필요한 경우 특히 유용합니다. GUI는 로컬 또는 원격 서버에서 서버 로그를 검색할 수도 있습니다.

$ .../bin/jboss-cli.sh --gui

참고: 원격 서버에 연결하려면 --connect 옵션도 전달합니다. 자세한 내용은 --help 옵션을 사용합니다.

GUI 모드를 시작한 후 아래로 스크롤하여 하위 시스템=keycloak-server 를 찾습니다. 노드를 마우스 오른쪽 버튼으로 클릭하고 Explore subsystem=keycloak-server 를 클릭하면 keycloak-server 하위 시스템만 표시되는 새 탭이 표시됩니다.

CLI에는 광범위한 스크립팅 기능이 있습니다. 스크립트는 CLI 명령이 포함된 텍스트 파일일 뿐입니다. 테마 및 템플릿 캐싱을 해제하는 간단한 스크립트를 고려하십시오.

/subsystem=keycloak-server/theme=defaults/:write-attribute(name=cacheThemes,value=false)
/subsystem=keycloak-server/theme=defaults/:write-attribute(name=cacheTemplates,value=false)

스크립트를 실행하려면 CLI GUI의 스크립트 메뉴를 따르거나 명령줄에서 다음과 같이 스크립트를 실행할 수 있습니다.

$ .../bin/jboss-cli.sh --file=turn-off-caching.cli

다음은 일부 구성 작업과 CLI 명령을 사용하여 수행하는 방법입니다. 첫 번째 예제를 제외한 첫 번째 예제에서는 와일드카드 경로 ** 를 사용하여 대체해야 하거나 keycloak-server 하위 시스템 경로를 사용해야 합니다.

독립 실행형의 경우 다음을 의미합니다.

** = /subsystem=keycloak-server

도메인 모드의 경우 다음과 같습니다.

** = /profile=auth-server-clustered/subsystem=keycloak-server

/subsystem=keycloak-server/:write-attribute(name=web-context,value=myContext)

**/theme=defaults/:write-attribute(name=default,value=myTheme)

**/spi=mySPI/:add
**/spi=mySPI/provider=myProvider/:add(enabled=true)

**/spi=mySPI/provider=myProvider/:write-attribute(name=enabled,value=false)

**/spi=mySPI/:write-attribute(name=default-provider,value=myProvider)

**/spi=dblock/:add(default-provider=jpa)
**/spi=dblock/provider=jpa/:add(properties={lockWaitTimeout => "900"},enabled=true)

**/spi=dblock/provider=jpa/:map-put(name=properties,key=lockWaitTimeout,value=3)

**/spi=dblock/provider=jpa/:map-remove(name=properties,key=lockRecheckTime)

**/spi=eventsStore/provider=jpa/:map-put(name=properties,key=exclude-events,value=[EVENT1,EVENT2])

다음은 Red Hat Single Sign-On에 대해 RDBMS를 구성하기 위해 수행해야 하는 단계입니다.

이 장에서는 모든 예제에 PostgresSQL을 사용합니다. 다른 데이터베이스는 설치를 위해 동일한 단계를 따릅니다.

RDBMS용 JDBC 드라이버 JAR을 찾아 다운로드합니다. 이 드라이버를 사용하려면 먼저 모듈에 패키지하여 서버에 설치해야 합니다. 모듈은 Red Hat Single Sign-On 클래스 경로에 로드되는 JAR과 다른 모듈에 있는 JAR의 종속성을 정의합니다. 쉽게 설정할 수 있습니다.

Red Hat Single Sign-On 배포의 …​/modules/ 디렉터리에 모듈 정의를 유지할 디렉터리 구조를 생성해야 합니다. 규칙은 디렉터리 구조 이름에 JDBC 드라이버의 Java 패키지 이름을 사용합니다. PostgreSQL의 경우 org/postgresql/main 디렉터리를 생성합니다. 데이터베이스 드라이버 JAR을 이 디렉터리에 복사하고 여기에 빈 module.xml 파일도 생성합니다.

이 작업을 수행한 후 module.xml 파일을 열고 다음 XML을 생성합니다.

<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.3" name="org.postgresql">

    <resources>
        <resource-root path="postgresql-9.4.1212.jar"/>
    </resources>

    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

모듈 이름은 모듈의 디렉터리 구조와 일치해야 합니다. 따라서 org/postgresql 는 org.postgresql 에 매핑됩니다. resource-root path 속성은 드라이버의 JAR 파일 이름을 지정해야 합니다. 나머지 부분은 JDBC 드라이버 JAR에 있는 일반 종속 항목일 뿐입니다.

다음 작업은 새로 패키징된 JDBC 드라이버를 배포 프로필에 선언하여 서버가 부팅될 때 로드되고 사용 가능하게 하는 것입니다. 이 작업을 수행하는 위치는 작동 모드에 따라 다릅니다. 표준 모드로 배포하는 경우 …​/standalone/configuration/standalone.xml 을 편집합니다. 표준 클러스터링 모드로 배포하는 경우 …​/standalone/configuration/standalone-ha.xml 을 편집합니다. 도메인 모드로 배포하는 경우 …​/domain/configuration/domain.xml 을 편집합니다. 도메인 모드에서는 사용 중인 프로필을 편집해야 합니다. auth-server-standalone 또는 auth-server-clustered

프로필 내에서 데이터 소스 하위 시스템 내에서 drivers XML 블록을 검색합니다. H2 JDBC 드라이버에 대해 선언된 사전 정의 드라이버가 표시됩니다. 여기에서 외부 데이터베이스에 대한 JDBC 드라이버를 선언합니다.

  <subsystem xmlns="urn:jboss:domain:datasources:5.0">
     <datasources>
       ...
       <drivers>
          <driver name="h2" module="com.h2database.h2">
              <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
          </driver>
       </drivers>
     </datasources>
  </subsystem>

drivers XML 블록 내에서 추가 JDBC 드라이버를 선언해야 합니다. 원하는 대로 선택할 수 있는 이름이 있어야 합니다. 드라이버 JAR에 대해 이전에 생성한 모듈 패키지를 가리키는 module 속성을 지정합니다. 마지막으로 드라이버의 Java 클래스를 지정해야 합니다. 다음은 이 장의 앞부분에서 정의한 모듈 예제에 있는 PostgreSQL 드라이버 설치의 예입니다.

  <subsystem xmlns="urn:jboss:domain:datasources:5.0">
     <datasources>
       ...
       <drivers>
          <driver name="postgresql" module="org.postgresql">
              <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
          </driver>
          <driver name="h2" module="com.h2database.h2">
              <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
          </driver>
       </drivers>
     </datasources>
  </subsystem>

JDBC 드라이버를 선언한 후에는 Red Hat Single Sign-On에서 새 외부 데이터베이스에 연결하는 데 사용하는 기존 데이터 소스 구성을 수정해야 합니다. JDBC 드라이버를 등록한 것과 동일한 구성 파일 및 XML 블록 내에서 이 작업을 수행합니다. 다음은 새 데이터베이스에 대한 연결을 설정하는 예입니다.

  <subsystem xmlns="urn:jboss:domain:datasources:5.0">
     <datasources>
       ...
       <datasource jndi-name="java:jboss/datasources/KeycloakDS" pool-name="KeycloakDS" enabled="true" use-java-context="true">
           <connection-url>jdbc:postgresql://localhost/keycloak</connection-url>
           <driver>postgresql</driver>
           <pool>
               <max-pool-size>20</max-pool-size>
           </pool>
           <security>
               <user-name>William</user-name>
               <password>password</password>
           </security>
       </datasource>
        ...
     </datasources>
  </subsystem>

KeycloakDS 에 대한 데이터 소스 정의를 검색합니다. 먼저 connection-url 을 수정해야 합니다. 벤더의 JDBC 구현에 대한 문서는 이 연결 URL 값의 형식을 지정해야 합니다.

다음으로 사용할 드라이버 를 정의합니다. 이 장의 이전 섹션에서 선언한 JDBC 드라이버의 논리적 이름입니다.

트랜잭션을 수행하려는 때마다 데이터베이스에 대한 새 연결을 여는 것은 비용이 많이 듭니다. 이를 보완하기 위해 데이터 소스 구현에서는 오픈 연결 풀을 유지 관리합니다. max-pool-size 는 풀할 최대 연결 수를 지정합니다. 시스템의 부하에 따라 이 값을 변경할 수 있습니다.

마지막으로 PostgreSQL을 사용하여 데이터베이스에 연결하는 데 필요한 데이터베이스 사용자 이름과 암호를 정의해야 합니다. 이 예제에서는 명확한 텍스트로 표시된다고 우려할 수 있습니다. 이를 난독화하는 방법이 있지만 이 가이드의 범위를 벗어납니다.

이 구성 요소의 구성은 배포판의 standalone.xml,standalone-ha.xml 또는 domain.xml 파일에 있습니다. 이 파일의 위치는 작동 모드에 따라 다릅니다.

<subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
    ...
    <spi name="connectionsJpa">
     <provider name="default" enabled="true">
         <properties>
             <property name="dataSource" value="java:jboss/datasources/KeycloakDS"/>
             <property name="initializeEmpty" value="false"/>
             <property name="migrationStrategy" value="manual"/>
             <property name="migrationExport" value="${jboss.home.dir}/keycloak-database-update.sql"/>
         </properties>
     </provider>
    </spi>
    ...
</subsystem>

가능한 구성 옵션은 다음과 같습니다.

Red Hat Single Sign-On의 데이터베이스 스키마는 다음 특수 필드의 유니코드 문자열만 고려합니다.

그렇지 않으면 문자는 종종 8비트인 데이터베이스 인코딩에 포함된 문자로 제한됩니다. 그러나 일부 데이터베이스 시스템의 경우 유니코드 문자의 UTF-8 인코딩을 활성화하고 모든 텍스트 필드에서 전체 유니코드 문자를 사용할 수 있습니다. 종종 이는 8비트 인코딩의 경우보다 짧은 최대 문자열 길이만큼 균형을 이루는 경우가 많습니다.

일부 데이터베이스는 유니코드 문자를 처리할 수 있도록 데이터베이스 및/또는 JDBC 드라이버에 특수 설정이 필요합니다. 아래에서 데이터베이스에 대한 설정을 찾으십시오. 데이터베이스가 여기에 나열되어 있는 경우에도 데이터베이스 및 JDBC 드라이버 수준에서 UTF-8 인코딩을 올바르게 처리할 수 있습니다.

기술적으로 모든 필드에 대한 유니코드 지원의 핵심 기준은 데이터베이스가 VARCHAR 및 Cryostat 필드에 설정된 유니코드 문자 설정을 허용하는지 여부입니다. 예인 경우 일반적으로 유니코드가 필드 길이를 희생할 가능성이 높습니다. NVARCHAR 및 N CHAR 필드에서 유니코드만 지원하는 경우 모든 텍스트 필드에 대한 유니코드 지원은 Keycloak 스키마에서 VARCHAR 및 Cryostat 필드를 광범위하게 사용하므로 거의 지원되지 않습니다.

show server_encoding;

create database keycloak with encoding 'UTF8';

기본 호스트 이름 공급자는 구성된 frontendUrl 을 frontend 요청의 기본 URL(user-agents의 요청)으로 사용하고 요청 URL을 백엔드 요청(클라이언트의 직접 요청)으로 사용합니다.

프런트 엔드 요청은 Keycloak 서버와 동일한 컨텍스트 경로를 가질 필요가 없습니다. 즉, 내부 URL이 https://10.0.0.10:8080/auth 일 수 있는 반면, 예를 들어 https://example.org/keycloak 또는 https://example.org/keycloak 에 Keycloak을 노출할 수 있습니다.

이렇게 하면 사용자 에이전트(브라우저)에서 공용 도메인 이름을 통해 ${project.name}에 요청을 보낼 수 있지만 내부 클라이언트는 내부 도메인 이름 또는 IP 주소를 사용할 수 있습니다.

이는 authorization_endpoint 에서 프런트 엔드 URL을 사용하는 반면 token_endpoint 는 백엔드 URL을 사용하는 경우 OpenID Connect Discovery 끝점에 반영됩니다. 여기에 인스턴스의 공용 클라이언트가 공용 끝점을 통해 Keycloak에 문의하므로 authorization_endpoint 및 token_endpoint 의 기반이 동일합니다.

Keycloak에 대한 frontendUrl을 설정하려면 add -Dkeycloak.frontendUrl=https://auth.example.org 를 시작에 전달하거나 standalone.xml 에서 구성할 수 있습니다. 아래 예제를 참조하십시오.

<spi name="hostname">
    <default-provider>default</default-provider>
    <provider name="default" enabled="true">
        <properties>
            <property name="frontendUrl" value="https://auth.example.com"/>
            <property name="forceBackendUrlToFrontendUrl" value="false"/>
        </properties>
    </provider>
</spi>

jboss-cli로 frontendUrl 을 업데이트하려면 다음 명령을 사용합니다.

/subsystem=keycloak-server/spi=hostname/provider=fixed:write-attribute(name=properties.frontendUrl,value="https://auth.example.com")

모든 요청이 공용 도메인 이름을 통과하도록 하려면 백엔드 요청에서 프런트 엔드 URL을 사용하도록 강제 적용하고 forceBackendUrlToFrontendUrl 을 true 로 설정하여 .

개별 영역에 대한 기본 프런트 엔드 URL을 덮어쓸 수도 있습니다. 이 작업은 관리자 콘솔에서 수행할 수 있습니다.

공용 도메인에 관리 끝점 및 콘솔을 노출하지 않으려면 속성 adminUrl 을 사용하여 frontendUrl 과 다른 관리자 콘솔의 고정 URL을 설정합니다. 또한 서버 관리 가이드를 참조하는 방법에 대한 자세한 내용은 외부에서 /auth/admin 에 대한 액세스를 차단해야 합니다.

사용자 정의 호스트 이름 공급자를 개발하려면 org.keycloak.urls.HostnameProvider y 및 org.keycloak.urls.HostnameProvider 를 구현해야 합니다.

사용자 지정 공급자를 개발하는 방법에 대한 자세한 내용은 서버 개발자 가이드 의 서비스 공급자 인터페이스 섹션의 지침을 따르십시오.

기본적으로 Red Hat Single Sign-On은 localhost 루프백 주소 127.0.0.1 에 바인딩됩니다. 네트워크에서 인증 서버를 사용할 수 있도록 하려면 매우 유용한 기본값이 아닙니다. 일반적으로 공용 네트워크에 역방향 프록시 또는 로드 밸런서를 배포하고 트래픽을 사설 네트워크의 개별 Red Hat Single Sign-On 서버 인스턴스로 라우팅하는 것이 좋습니다. 두 경우 모두 localhost 가 아닌 다른 항목에 바인딩하도록 네트워크 인터페이스를 설정해야 합니다.

bind 주소를 설정하는 것은 매우 쉬우며 명령행에서 운영 모드 선택 장에 설명된 standalone.sh 또는 domain.sh 부팅 스크립트를 사용하여 수행할 수 있습니다.

$ standalone.sh -b 192.168.0.5

-b 스위치는 모든 공용 인터페이스의 IP 바인딩 주소를 설정합니다.

또는 명령줄에서 바인딩 주소를 설정하지 않으려면 배포의 프로필 구성을 편집할 수 있습니다. 프로필 구성 파일( 운영 모드에따라standalone.xml 또는 domain.xml )을 열고 인터페이스 XML 블록을 찾습니다.

    <interfaces>
        <interface name="management">
            <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
        </interface>
        <interface name="public">
            <inet-address value="${jboss.bind.address:127.0.0.1}"/>
        </interface>
    </interfaces>

공용 인터페이스는 공개적으로 사용할 수 있는 소켓을 생성하는 하위 시스템에 해당합니다. 이러한 하위 시스템 중 하나의 예로는 Red Hat Single Sign-On의 인증 끝점을 제공하는 웹 계층이 있습니다. 관리 인터페이스는 JBoss EAP의 관리 계층에 의해 열리는 소켓에 해당합니다. 특히 jboss-cli.sh 명령줄 인터페이스와 JBoss EAP 웹 콘솔을 사용할 수 있는 소켓입니다.

공용 인터페이스를 보면 특수 문자열 ${jboss.bind.address:127.0.0.1} 이 있습니다. 이 문자열은 Java 시스템 속성을 설정하여 명령줄에서 재정의할 수 있는 127.0.0.1 값을 나타냅니다. 예를 들면 다음과 같습니다.

$ domain.sh -Djboss.bind.address=192.168.0.5

b 는 이 명령에 대한 간략한 표기법일 뿐입니다. 따라서 프로필 구성에서 직접 bind address 값을 변경하거나 부팅 시 명령줄에서 이 값을 변경할 수 있습니다.

각 소켓에 대해 열린 포트에는 명령줄 또는 구성에서 재정의할 수 있는 사전 정의된 기본값이 있습니다. 이 구성을 설명하기 위해 독립 실행형 모드로 실행 중이어서 …​/standalone/configuration/standalone.xml 을 엽니다. socket-binding-group 을 검색합니다.

    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
        <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
        <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
        <socket-binding name="http" port="${jboss.http.port:8080}"/>
        <socket-binding name="https" port="${jboss.https.port:8443}"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
        </outbound-socket-binding>
    </socket-binding-group>

socket-bindings 는 서버에서 열 소켓 연결을 정의합니다. 이러한 바인딩은 사용하는 인터페이스 (바인드 주소)와 열 포트 번호를 지정합니다. 관심 있는 대상은 다음과 같습니다.

예제 domain.xml 파일에 여러 socket-binding-groups 가 정의되어 있으므로 도메인 모드를 설정하는 경우 소켓 구성은 비트 래시티입니다. server-group 정의까지 아래로 스크롤하면 각 server-group 에 사용되는 socket-binding-group 을 확인할 수 있습니다.

    <server-groups>
        <server-group name="load-balancer-group" profile="load-balancer">
            ...
            <socket-binding-group ref="load-balancer-sockets"/>
        </server-group>
        <server-group name="auth-server-group" profile="auth-server-clustered">
            ...
            <socket-binding-group ref="ha-sockets"/>
        </server-group>
    </server-groups>

이 기본 동작은 각 Red Hat Single Sign-On 영역의 SSL/HTTPS 모드로 정의됩니다. 이 내용은 서버 관리 가이드에서 자세히 설명하지만 이러한 모드에 대한 몇 가지 컨텍스트와 간략한 개요를 제공합니다.

각 영역의 SSL 모드는 Red Hat Single Sign-On 관리 콘솔에서 구성할 수 있습니다.

$ keytool -genkey -alias localhost -keyalg RSA -keystore keycloak.jks -validity 10950
    Enter keystore password: secret
    Re-enter new password: secret
    What is your first and last name?
    [Unknown]:  localhost
    What is the name of your organizational unit?
    [Unknown]:  Keycloak
    What is the name of your organization?
    [Unknown]:  Red Hat
    What is the name of your City or Locality?
    [Unknown]:  Westford
    What is the name of your State or Province?
    [Unknown]:  MA
    What is the two-letter country code for this unit?
    [Unknown]:  US
    Is CN=localhost, OU=Keycloak, O=Test, L=Westford, ST=MA, C=US correct?
    [no]:  yes

$ keytool -certreq -alias yourdomain -keystore keycloak.jks > keycloak.careq

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIC2jCCAcICAQAwZTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk1BMREwDwYDVQQHEwhXZXN0Zm9y
ZDEQMA4GA1UEChMHUmVkIEhhdDEQMA4GA1UECxMHUmVkIEhhdDESMBAGA1UEAxMJbG9jYWxob3N0
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr7kck2TaavlEOGbcpi9c0rncY4HhdzmY
Ax2nZfq1eZEaIPqI5aTxwQZzzLDK9qbeAd8Ji79HzSqnRDxNYaZu7mAYhFKHgixsolE3o5Yfzbw1
29RvyeUVe+WZxv5oo9wolVVpdSINIMEL2LaFhtX/c1dqiqYVpfnvFshZQaIg2nL8juzZcBjj4as
H98gIS7khql/dkZKsw9NLvyxgJvp7PaXurX29fNf3ihG+oFrL22oFyV54BWWxXCKU/GPn61EGZGw
Ft2qSIGLdctpMD1aJR2bcnlhEjZKDksjQZoQ5YMXaAGkcYkG6QkgrocDE2YXDbi7GIdf9MegVJ35
2DQMpwIDAQABoDAwLgYJKoZIhvcNAQkOMSEwHzAdBgNVHQ4EFgQUQwlZJBA+fjiDdiVzaO9vrE/i
n2swDQYJKoZIhvcNAQELBQADggEBAC5FRvMkhal3q86tHPBYWBuTtmcSjs4qUm6V6f63frhveWHf
PzRrI1xH272XUIeBk0gtzWo0nNZnf0mMCtUBbHhhDcG82xolikfqibZijoQZCiGiedVjHJFtniDQ
9bMDUOXEMQ7gHZg5q6mJfNG9MbMpQaUVEEFvfGEQQxbiFK7hRWU8S23/d80e8nExgQxdJWJ6vd0X
MzzFK6j4Dj55bJVuM7GFmfdNC52pNOD5vYe47Aqh8oajHX9XTycVtPXl45rrWAH33ftbrS8SrZ2S
vqIFQeuLL3BaHwpl3t7j2lMWcK1p80laAxEASib/fAwrRHpLHBXRcq6uALUOZl4Alt8=
-----END NEW CERTIFICATE REQUEST-----

$ keytool -import -keystore keycloak.jks -file root.crt -alias root

$ keytool -import -alias yourdomain -keystore keycloak.jks -file your-certificate.cer

$ /core-service=management/security-realm=UndertowRealm:add()

$ /core-service=management/security-realm=UndertowRealm/server-identity=ssl:add(keystore-path=keycloak.jks, keystore-relative-to=jboss.server.config.dir, keystore-password=secret)

$ /host=<host_name>/core-service=management/security-realm=UndertowRealm/server-identity=ssl:add(keystore-path=keycloak.jks, keystore-relative-to=jboss.server.config.dir, keystore-password=secret)

<security-realm name="UndertowRealm">
    <server-identities>
        <ssl>
            <keystore path="keycloak.jks" relative-to="jboss.server.config.dir" keystore-password="secret" />
        </ssl>
    </server-identities>
</security-realm>

$ /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=security-realm, value=UndertowRealm)

<subsystem xmlns="urn:jboss:domain:undertow:10.0">
   <buffer-cache name="default"/>
   <server name="default-server">
      <https-listener name="https" socket-binding="https" security-realm="UndertowRealm"/>
   ...
</subsystem>

Red Hat Single Sign-On 서버는 안전한 애플리케이션 및 서비스에 대한 브라우저 이외의 HTTP 요청을 수행해야 하는 경우가 많습니다. 인증 서버는 HTTP 클라이언트 연결 풀을 유지 관리하여 이러한 발신 연결을 관리합니다. standalone.xml,standalone-ha.xml 또는 domain.xml 에서 구성해야 하는 몇 가지 사항이 있습니다. 이 파일의 위치는 작동 모드에 따라 다릅니다.

<spi name="connectionsHttpClient">
    <provider name="default" enabled="true">
        <properties>
            <property name="connection-pool-size" value="256"/>
        </properties>
    </provider>
</spi>

가능한 구성 옵션은 다음과 같습니다.

.*\.(google|googleapis)\.com;http://www-proxy.acme.com:8080

.*\.(google|googleapis)\.com;http://user01:pas2w0rd@www-proxy.acme.com:8080

# 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

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"])

<spi name="connectionsHttpClient">
    <provider name="default" enabled="true">
        <properties>
            <property
            name="proxy-mappings"
            value="[&quot;.*\\.(google|googleapis)\\.com;http://www-proxy.acme.com:8080&quot;,&quot;.*\\.acme\\.com;NO_PROXY&quot;,&quot;.*;http://fallback:8080&quot;]"/>
        </properties>
    </provider>
</spi>

$ keytool -import -alias HOSTDOMAIN -keystore truststore.jks -file host-certificate.cer

<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"/>
            <property name="disabled" value="false"/>
        </properties>
    </provider>
</spi>

Red Hat Single Sign-On 배포를 위해 권장되는 네트워크 아키텍처는 프라이빗 네트워크에 있는 Red Hat Single Sign-On 서버로 요청을 라우팅하는 공용 IP 주소에 HTTP/HTTPS 로드 밸런서를 설정하는 것입니다. 이는 모든 클러스터링 연결을 분리하고 서버를 보호하는 좋은 수단을 제공합니다.

Red Hat Single Sign-On에는 도메인 모드를 활용하는 박스 클러스터링 데모가 포함되어 있습니다. 자세한 내용은 클러스터된 도메인 예제 장을 검토하십시오.

이 섹션에서는 클러스터형 Red Hat Single Sign-On 배포 앞에 역방향 프록시 또는 로드 밸런서를 배치하기 전에 구성해야 하는 여러 사항에 대해 설명합니다. 또한 클러스터된 도메인 예제 를 사용한 기본 제공 로드 밸런서 구성에 대해 설명합니다.

다음 다이어그램에서는 로드 밸런서를 사용하는 방법을 보여줍니다. 이 예에서 로드 밸런서는 3개의 클라이언트와 3개의 Red Hat Single Sign-On 서버 클러스터 간의 역방향 프록시 역할을 합니다.

<subsystem xmlns="urn:jboss:domain:undertow:10.0">
   <buffer-cache name="default"/>
   <server name="default-server">
      <ajp-listener name="ajp" socket-binding="ajp"/>
      <http-listener name="default" socket-binding="http" redirect-socket="https"
          proxy-address-forwarding="true"/>
      ...
   </server>
   ...
</subsystem>

<subsystem xmlns="urn:jboss:domain:undertow:10.0">
     <buffer-cache name="default"/>
     <server name="default-server">
         <ajp-listener name="ajp" socket-binding="ajp"/>
         <http-listener name="default" socket-binding="http" redirect-socket="https"/>
         <host name="default-host" alias="localhost">
             ...
             <filter-ref name="proxy-peer"/>
         </host>
     </server>
        ...
     <filters>
         ...
         <filter name="proxy-peer"
                 class-name="io.undertow.server.handlers.ProxyPeerAddressHandler"
                 module="io.undertow.core" />
     </filters>
 </subsystem>

<subsystem xmlns="urn:jboss:domain:undertow:10.0">
    ...
    <http-listener name="default" socket-binding="http"
        proxy-address-forwarding="true" redirect-socket="proxy-https"/>
    ...
</subsystem>

<socket-binding-group name="standard-sockets" default-interface="public"
    port-offset="${jboss.socket.binding.port-offset:0}">
    ...
    <socket-binding name="proxy-https" port="443"/>
    ...
</socket-binding-group>

08:14:21,287 WARN  XNIO-1 task-45 [org.keycloak.events] type=LOGIN_ERROR, realmId=master, clientId=security-admin-console, userId=8f20d7ba-4974-4811-a695-242c8fbd1bf8, ipAddress=X.X.X.X, error=invalid_user_credentials, auth_method=openid-connect, auth_type=code, redirect_uri=http://localhost:8080/auth/admin/master/console/?redirect_fragment=%2Frealms%2Fmaster%2Fevents-settings, code_id=a3d48b67-a439-4546-b992-e93311d6493e, username=admin

<subsystem xmlns="urn:jboss:domain:undertow:10.0">
  ...
  <handlers>
      <reverse-proxy name="lb-handler">
         <host name="host1" outbound-socket-binding="remote-host1" scheme="ajp" path="/" instance-id="myroute1"/>
         <host name="host2" outbound-socket-binding="remote-host2" scheme="ajp" path="/" instance-id="myroute2"/>
         <host name="remote-host3" outbound-socket-binding="remote-host3" scheme="ajp" path="/" instance-id="myroute3"/>
      </reverse-proxy>
  </handlers>
  ...
</subsystem>

<socket-binding-group name="load-balancer-sockets" default-interface="public">
    ...
    <outbound-socket-binding name="remote-host1">
        <remote-destination host="localhost" port="8159"/>
    </outbound-socket-binding>
    <outbound-socket-binding name="remote-host2">
        <remote-destination host="localhost" port="8259"/>
    </outbound-socket-binding>
    <outbound-socket-binding name="remote-host3">
        <remote-destination host="192.168.0.5" port="8259"/>
    </outbound-socket-binding>
</socket-binding-group>

$ domain.sh --host-config=host-master.xml -Djboss.bind.address=192.168.0.2 -Djboss.bind.address.management=192.168.0.2

$ domain.sh --host-config=host-slave.xml
     -Djboss.bind.address=192.168.0.5
      -Djboss.bind.address.management=192.168.0.5
       -Djboss.domain.master.address=192.168.0.2

일반적인 클러스터 배포는 로드 밸런서(reverse proxy)와 사설 네트워크의 Red Hat Single Sign-On 서버 2개로 구성됩니다. 성능을 위해 로드 밸런서에서 특정 브라우저 세션과 관련된 모든 요청을 동일한 Red Hat Single Sign-On 백엔드 노드로 전달하는 경우 유용할 수 있습니다.

그 이유는 Red Hat Single Sign-On이 현재 인증 세션 및 사용자 세션과 관련된 데이터를 저장하기 위해 적용 대상에서 Infinispan 분산 캐시를 사용하고 있기 때문입니다. Infinispan 분산 캐시는 기본적으로 하나의 소유자로 구성됩니다. 즉, 특정 세션이 하나의 클러스터 노드에만 저장되고 다른 노드는 액세스하려는 경우 원격으로 세션을 조회해야 합니다.

예를 들어 ID 123 이 있는 인증 세션이 node1 의 Infinispan 캐시에 저장된 다음 node2 에서 이 세션을 조회해야 하는 경우 특정 세션 엔터티를 반환하려면 네트워크를 통해 node1 에 요청을 보내야 합니다.

특정 세션 엔터티를 로컬에서 항상 사용할 수 있는 경우 유용합니다. 이 경우 고정 세션의 도움을 받아 수행할 수 있습니다. 공용 프런트 엔드 로드 밸런서가 있는 클러스터 환경의 워크플로우와 Red Hat Single Sign-On 노드 두 개는 다음과 같을 수 있습니다.

이 시점에서 로드 밸런서가 ID 123 이 있는 인증 세션의 소유자이므로 모든 다음 요청을 node2 로 전달하는 경우 유용합니다. 따라서 Infinispan은 이 세션을 로컬로 조회할 수 있습니다. 인증이 완료되면 인증 세션이 사용자 세션으로 변환되며 ID 123 이 동일하기 때문에 node2 에도 저장됩니다.

고정 세션은 클러스터 설정에 필수는 아니지만 위에서 언급한 이유로 성능에 적합합니다. AUTH_SESSION_ID 쿠키를 고정하도록 로드 밸런서를 구성해야 합니다. 이 작업은 로드 밸런서에 따라 어떻게 됩니까.

시작 중에 시스템 속성 jboss.node.name 을 경로 이름에 해당하는 값과 함께 사용하려면 Red Hat Single Sign-On 측에서 사용하는 것이 좋습니다. 예를 들어 -Djboss.node.name=node1 은 node1 을 사용하여 경로를 식별합니다. 이 경로는 노드가 특정 키의 소유자인 경우 Infinispan 캐시에서 사용되며 AUTH_SESSION_ID 쿠키 에 연결됩니다. 다음은 이 시스템 속성을 사용하는 시작 명령의 예입니다.

cd $RHSSO_NODE1
./standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=node1

일반적으로 프로덕션 환경에서 경로 이름은 백엔드 호스트와 동일한 이름을 사용해야 하지만 필수는 아닙니다. 다른 경로 이름을 사용할 수 있습니다. 예를 들어 사설 네트워크 내에서 Red Hat Single Sign-On 서버의 호스트 이름을 숨기려면 다음을 수행합니다.

<subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
  ...
    <spi name="stickySessionEncoder">
        <provider name="infinispan" enabled="true">
            <properties>
                <property name="shouldAttachRoute" value="false"/>
            </properties>
        </provider>
    </spi>

</subsystem>

기본적으로 클러스터링 지원에는 IP 멀티 캐스트가 필요합니다. 멀티 캐스트는 네트워크 브로드캐스트 프로토콜입니다. 이 프로토콜은 부팅 시 클러스터를 검색하고 참여하는데 사용됩니다. 또한 Red Hat Single Sign-On에서 사용하는 분산 캐시의 복제 및 무효화에 대한 메시지를 브로드캐스트하는 데도 사용됩니다.

Red Hat Single Sign-On의 클러스터링 하위 시스템은 Cryostat 스택에서 실행됩니다. 기본적으로 클러스터링의 바인딩 주소는 127.0.0.1을 기본 IP 주소로 사용하는 사설 네트워크 인터페이스에 바인딩됩니다. 주소 바인딩 장에 설명된 standalone-ha.xml 또는 domain.xml 섹션을 편집해야 합니다.

    <interfaces>
        ...
        <interface name="private">
            <inet-address value="${jboss.bind.address.private:127.0.0.1}"/>
        </interface>
    </interfaces>
    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        ...
        <socket-binding name="jgroups-mping" interface="private" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
        <socket-binding name="jgroups-tcp" interface="private" port="7600"/>
        <socket-binding name="jgroups-tcp-fd" interface="private" port="57600"/>
        <socket-binding name="jgroups-udp" interface="private" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
        <socket-binding name="jgroups-udp-fd" interface="private" port="54200"/>
        <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" multicast-port="23364"/>
        ...
    </socket-binding-group>

구성하려는 항목은 jboss.bind.address.private 및 jboss.default.multicast.address 및 클러스터링 스택의 서비스 포트입니다.

프라이빗 네트워크에서 클러스터 노드를 분리하면 클러스터에 참여하거나 클러스터의 통신을 볼 수 있도록 프라이빗 네트워크에 액세스해야 합니다. 또한 클러스터 통신에 대한 인증 및 암호화를 활성화할 수도 있습니다. 사설 네트워크가 보안되는 한 인증 및 암호화를 활성화할 필요가 없습니다. Red Hat Single Sign-On은 어떠한 경우에도 클러스터에 대한 매우 민감한 정보를 보내지 않습니다.

클러스터링 통신에 대한 인증 및 암호화를 활성화하려면 JBoss EAP 구성 가이드 의 클러스터 보안 을 참조하십시오.

Red Hat Single Sign-On 클러스터 노드는 동시에 부팅할 수 있습니다. Red Hat Single Sign-On 서버 인스턴스가 부팅되면 일부 데이터베이스 마이그레이션, 가져오기 또는 초기화를 수행할 수 있습니다. DB 잠금은 클러스터 노드를 동시에 부팅할 때 시작 작업이 서로 충돌하지 않도록 하는 데 사용됩니다.

기본적으로 이 잠금의 최대 시간 초과는 900초입니다. 노드가 시간 초과보다 이 잠금에서 대기 중인 경우 부팅에 실패합니다. 일반적으로 기본값을 증가/분리할 필요는 없지만 배포에서 standalone.xml,standalone-ha.xml 또는 domain.xml 파일에서 구성할 수 있는 경우에만 기본값을 늘릴 수 있습니다. 이 파일의 위치는 작동 모드에 따라 다릅니다.

<spi name="dblock">
    <provider name="jpa" enabled="true">
        <properties>
            <property name="lockWaitTimeout" value="900"/>
        </properties>
    </provider>
</spi>

클러스터에서 Red Hat Single Sign-On 부팅은 운영 모드에따라 다릅니다.

$ bin/standalone.sh --server-config=standalone-ha.xml

$ bin/domain.sh --host-config=host-master.xml
$ bin/domain.sh --host-config=host-slave.xml

추가 매개변수 또는 시스템 속성을 사용해야 할 수도 있습니다. 예를 들어 바인딩 호스트 또는 시스템 속성 jboss.node.name 의 매개 변수 -b 는 세션 섹션에 설명된 대로 경로 이름을 지정합니다.

Red Hat Single Sign-On에 대해 여러 다른 캐시가 구성되어 있습니다. 보안 애플리케이션, 일반 보안 데이터 및 구성 옵션에 대한 정보를 보유하는 영역 캐시가 있습니다. 사용자 메타데이터를 포함하는 사용자 캐시도 있습니다. 둘 다 기본값을 최대 10000개의 항목으로 캐시하고 최근에 사용된 제거 전략을 사용합니다. 또한 각 오브젝트는 클러스터형 설정의 제거를 제어하는 오브젝트 리버전 캐시에도 연결됩니다. 이 캐시는 암시적으로 생성되며 구성된 크기가 두 배입니다. 권한 부여 데이터를 보유하는 권한 부여 캐시에도 동일하게 적용됩니다. 키 캐시는 외부 키에 대한 데이터를 보유하고 있으며 전용 버전 캐시가 필요하지 않습니다. 대신 명시적으로 선언된 만료 가 있으므로 키가 주기적으로 만료되고 외부 클라이언트 또는 ID 공급자에서 주기적으로 다운로드해야 합니다.

이러한 캐시의 제거 정책 및 max 항목은 운영 모드에 따라 standalone.xml,standalone-ha.xml 또는 domain.xml 에서 구성할 수 있습니다. 구성 파일에는 다음과 유사한 infinispan 하위 시스템이 있는 부분이 있습니다.

<subsystem xmlns="urn:jboss:domain:infinispan:9.0">
    <cache-container name="keycloak">
        <local-cache name="realms">
            <object-memory size="10000"/>
        </local-cache>
        <local-cache name="users">
            <object-memory size="10000"/>
        </local-cache>
        ...
        <local-cache name="keys">
            <object-memory size="1000"/>
            <expiration max-idle="3600000"/>
        </local-cache>
        ...
    </cache-container>

허용된 항목 수를 제한하거나 확장하려면 오브젝트 요소 또는 특정 캐시 구성의 expiration 요소를 추가하거나 편집합니다.

또한 별도의 캐시 세션,clientSessions,offlineSessions,offlineClientSessions,loginFailures 및 actionTokens 도 있습니다. 이러한 캐시는 클러스터 환경에 배포되며 기본적으로 크기가 바인딩되지 않습니다. 바인딩된 경우 일부 세션이 손실될 수 있습니다. 만료된 세션은 Red Hat Single Sign-On 자체에서 내부적으로 지워지므로 제한 없이 이러한 캐시의 크기가 늘어나는 것을 방지할 수 있습니다. 많은 세션으로 인해 메모리 문제가 표시되는 경우 다음을 시도할 수 있습니다.

클러스터 노드 간에 메시지를 보내는 데 주로 사용되는 추가 복제 캐시인 work 가 있습니다. 이 캐시는 기본적으로 바인딩되지 않습니다. 그러나 이 캐시의 항목이 매우 짧은 경우 메모리 문제가 발생하지 않아야 합니다.

클러스터형 설정을 사용할 때 분산 캐시로 구성된 세션,authenticationSessions,offlineSessions, loginFailure 및 몇 가지 다른 캐시(자세한 내용은 10.1절. “제거 및 만료” 참조)와 같은 캐시가 있습니다. 항목이 모든 단일 노드에 복제되지는 않지만 대신 하나 이상의 노드가 해당 데이터의 소유자로 선택됩니다. 노드가 특정 캐시 항목의 소유자가 아닌 경우 해당 노드를 가져오도록 클러스터를 쿼리합니다. 즉, 장애 조치의 의미는 데이터를 소유한 모든 노드가 다운되면 해당 데이터가 영구적으로 손실된다는 것입니다. 기본적으로 Red Hat Single Sign-On은 데이터에 대해 하나의 소유자만 지정합니다. 따라서 하나의 노드가 해당 데이터를 중단하면 손실됩니다. 이는 일반적으로 사용자가 로그아웃되고 다시 로그인해야 함을 의미합니다.

distributed-cache 선언의 owners 속성을 변경하여 데이터를 복제하는 노드 수를 변경할 수 있습니다.

<subsystem xmlns="urn:jboss:domain:infinispan:9.0">
   <cache-container name="keycloak">
       <distributed-cache name="sessions" owners="2"/>
...

여기에서 두 개 이상의 노드가 하나의 특정 사용자 로그인 세션을 복제합니다.

영역 또는 사용자 캐시를 비활성화하려면 배포에서 standalone.xml,standalone-ha.xml 또는 domain.xml 파일을 편집해야 합니다. 이 파일의 위치는 작동 모드에 따라 다릅니다. 처음에 구성의 모양은 다음과 같습니다.

    <spi name="userCache">
        <provider name="default" enabled="true"/>
    </spi>

    <spi name="realmCache">
        <provider name="default" enabled="true"/>
    </spi>

비활성화하려는 캐시에 대해 캐시를 비활성화하려면 enabled 속성을 false로 설정합니다. 이 변경 사항을 적용하려면 서버를 재부팅해야 합니다.

영역 또는 사용자 캐시를 지우려면 Red Hat Single Sign-On 관리자 콘솔 settings으로 이동하여Cache Config 페이지로 이동합니다. 이 페이지에서는 영역 캐시, 사용자 캐시 또는 외부 공개 키의 캐시를 지울 수 있습니다.

Red Hat Single Sign-On Operator를 설치하려면 다음을 사용합니다.

Operator를 사용하여 Keycloak 사용자 정의 리소스를 생성하여 Red Hat Single Sign-On 설치를 자동화할 수 있습니다. 사용자 지정 리소스를 사용하여 Red Hat Single Sign-On을 설치할 때 여기에 설명된 구성 요소 및 서비스를 생성하고 다음 그래픽에 설명되어 있습니다.

apiVersion: keycloak.org/v1alpha1
kind: Keycloak
metadata:
  name: example-sso
  labels:
    app: sso
spec:
  instances: 1
  externalAccess:
    enabled: True

$ oc describe keycloak <CR-name>

Name:         example-keycloak
Namespace:    keycloak
Labels:       app=sso
Annotations:  <none>
API Version:  keycloak.org/v1alpha1
Kind:         Keycloak
Spec:
  External Access:
    Enabled:  true
  Instances:  1
Status:
  Credential Secret:  credential-example-keycloak
  Internal URL:       https://<External URL to the deployed instance>
  Message:
  Phase:              reconciling
  Ready:              true
  Secondary Resources:
    Deployment:
      keycloak-postgresql
    Persistent Volume Claim:
      keycloak-postgresql-claim
    Prometheus Rule:
      keycloak
    Route:
      keycloak
    Secret:
      credential-example-keycloak
      keycloak-db-secret
    Service:
      keycloak-postgresql
      keycloak
      keycloak-discovery
    Service Monitor:
      keycloak
    Stateful Set:
      keycloak
  Version:
Events:

Operator를 사용하여 사용자 정의 리소스에서 정의한 대로 Red Hat Single Sign-On에서 영역을 생성할 수 있습니다. YAML 파일에서 realm 사용자 정의 리소스의 속성을 정의합니다.

apiVersion: keycloak.org/v1alpha1
kind: KeycloakRealm
metadata:
  name: test
  labels:
    app: sso
spec:
  realm:
    id: "basic"
    realm: "basic"
    enabled: True
    displayName: "Basic Realm"
  instanceSelector:
    matchLabels:
      app: sso

$ oc describe keycloak <CR-name>

Name:         example-keycloakrealm
Namespace:    keycloak
Labels:       app=sso
Annotations:  <none>
API Version:  keycloak.org/v1alpha1
Kind:         KeycloakRealm
Metadata:
  Creation Timestamp:  2019-12-03T09:46:02Z
  Finalizers:
    realm.cleanup
  Generation:        1
  Resource Version:  804596
  Self Link:         /apis/keycloak.org/v1alpha1/namespaces/keycloak/keycloakrealms/example-keycloakrealm
  UID:               b7b2f883-15b1-11ea-91e6-02cb885627a6
Spec:
  Instance Selector:
    Match Labels:
      App: sso
  Realm:
    Display Name:  Basic Realm
    Enabled:       true
    Id:            basic
    Realm:         basic
Status:
  Login URL:
  Message:
  Phase:      reconciling
  Ready:      true
Events:       <none>

추가 리소스

Operator를 사용하여 사용자 정의 리소스에서 정의한 대로 Red Hat Single Sign-On에서 클라이언트를 생성할 수 있습니다. YAML 파일에서 영역의 속성을 정의합니다.

apiVersion: keycloak.org/v1alpha1
kind: KeycloakClient
metadata:
  name: example-client
  labels:
    app: sso
spec:
  realmSelector:
     matchLabels:
      app: <matching labels for KeycloakRealm custom resource>
  client:
    # auto-generated if not supplied
    #id: 123
    clientId: client-secret
    secret: client-secret
    # ...
    # other properties of Keycloak Client

apiVersion: v1
data:
  CLIENT_ID: <base64 encoded Client ID>
  CLIENT_SECRET: <base64 encoded Client Secret>
kind: Secret

Operator에서 사용자 정의 리소스를 처리한 후 다음 명령으로 상태를 확인합니다.

$ oc describe keycloak <CR-name>

Name:         client-secret
Namespace:    keycloak
Labels:       app=sso
API Version:  keycloak.org/v1alpha1
Kind:         KeycloakClient
Spec:
  Client:
    Client Authenticator Type:     client-secret
    Client Id:                     client-secret
    Id:                            keycloak-client-secret
  Realm Selector:
    Match Labels:
      App:  sso
Status:
  Message:
  Phase:    reconciling
  Ready:    true
  Secondary Resources:
    Secret:
      keycloak-client-secret-client-secret
Events:  <none>

Operator를 사용하여 사용자 정의 리소스에서 정의한 대로 Red Hat Single Sign-On에서 사용자를 생성할 수 있습니다. YAML 파일에서 사용자 정의 리소스의 속성을 정의합니다.

apiVersion: keycloak.org/v1alpha1
kind: KeycloakUser
metadata:
  name: example-user
spec:
  user:
    username: "realm_user"
    firstName: "John"
    lastName: "Doe"
    email: "user@example.com"
    enabled: True
    emailVerified: False
    realmRoles:
      - "offline_access"
    clientRoles:
      account:
        - "manage-account"
      realm-management:
        - "manage-users"
  realmSelector:
    matchLabels:
      app: sso

kind: Secret
apiVersion: v1
data:
  password: <base64 encoded password>
  username: <base64 encoded username>
type: Opaque

Operator에서 사용자 정의 리소스를 처리하면 다음 명령으로 상태를 확인합니다.

$ oc describe keycloak <CR-name>

Name:         example-realm-user
Namespace:    keycloak
Labels:       app=sso
API Version:  keycloak.org/v1alpha1
Kind:         KeycloakUser
Spec:
  Realm Selector:
    Match Labels:
      App: sso
  User:
    Email:           realm_user@redhat.com
    Credentials:
      Type:          password
      Value:         <user password>
    Email Verified:  false
    Enabled:         true
    First Name:      John
    Last Name:       Doe
    Username:        realm_user
Status:
  Message:
  Phase:    reconciled
Events:     <none>

Operator를 사용하여 Keycloak 사용자 정의 리소스를 수정하고 keycloak-db-secret YAML 파일을 생성하여 외부 PostgreSQL 데이터베이스에 연결할 수 있습니다. 값은 Base64로 인코딩됩니다.

apiVersion: v1
kind: Secret
metadata:
    name: keycloak-db-secret
    namespace: keycloak
stringData:
    POSTGRES_DATABASE: <Database Name>
    POSTGRES_EXTERNAL_ADDRESS: <External Database IP or URL (resolvable by K8s)>
    POSTGRES_EXTERNAL_PORT: <External Database Port>
    # Strongly recommended to use <'Keycloak CR-Name'-postgresql>
    POSTGRES_HOST: <Database Service Name>
    POSTGRES_PASSWORD: <Database Password>
    # Required for AWS Backup functionality
    POSTGRES_SUPERUSER: true
    POSTGRES_USERNAME: <Database Username>
 type: Opaque

다음 속성은 데이터베이스의 호스트 이름 또는 IP 주소와 포트를 설정합니다.

다른 속성은 호스트 또는 외부 데이터베이스에 대해 동일한 방식으로 작동합니다. 다음과 같이 설정합니다.

Keycloak 사용자 정의 리소스에는 외부 데이터베이스 지원을 활성화하기 위해 업데이트가 필요합니다.

apiVersion: keycloak.org/v1alpha1
kind: Keycloak
metadata:
  labels:
      app: sso
  name: example-keycloak
  namespace: keycloak
spec:
  externalDatabase:
    enabled: true
  instances: 1

Operator를 사용하여 사용자 정의 리소스에서 정의한 대로 데이터베이스의 자동 백업을 예약할 수 있습니다. 사용자 정의 리소스는 백업 작업을 트리거하고 상태를 다시 보고합니다.

Operator를 사용하여 로컬 영구 볼륨에 대한 일회성 백업을 수행하는 백업 작업을 생성할 수 있습니다.

apiVersion: keycloak.org/v1alpha1
kind: KeycloakBackup
metadata:
  name: test-backup

Operator를 사용하여 회사 또는 조직에 필요한 확장 기능 및 테마를 설치할 수 있습니다. 확장 또는 주제는 Red Hat Single Sign-On에서 사용할 수 있는 모든 항목이 될 수 있습니다. 예를 들어 메트릭 확장을 추가할 수 있습니다. Keycloak 사용자 정의 리소스에 확장 또는 테마를 추가합니다.

apiVersion: keycloak.org/v1alpha1
kind: Keycloak
metadata:
  name: example-keycloak
  labels:
   app: sso
spec:
  instances: 1
  extensions:
   - <url_for_extension_or_theme>
  externalAccess:
    enabled: True

Operator는 확장 또는 주제를 다운로드하여 설치합니다.

사용자 지정 요청을 생성한 후 oc 명령을 사용하여 편집하거나 삭제할 수 있습니다.

예를 들어 test-realm 이라는 realm 사용자 지정 요청을 편집하려면 다음 명령을 사용합니다.

$ oc edit test-realm

변경할 수 있는 창이 열립니다.