서버 설치 및 구성 가이드

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

Red Hat Single Sign-On 서버를 설치하기 위한 사전 요구 사항은 다음과 같습니다.

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

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

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

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

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

subscription-manager repos --enable=jb-eap-7.4-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.sh

> ...\bin\standalone.bat

> ...\bin\standalone.bat

./bin/jboss-cli.sh --file=docs/examples/enable-elytron-se17.cli

$ ./bin/jboss-cli.sh --file=docs/examples/enable-elytron-se17.cli

> .\bin\jboss-cli.bat --file=docs\examples\enable-elytron-se17.cli

> .\bin\jboss-cli.bat --file=docs\examples\enable-elytron-se17.cli

독립 실행형 클러스터형 작업 모드는 클러스터 내에서 Red Hat Single Sign-On을 실행하려는 경우에 적용됩니다. 이 모드에서는 서버 인스턴스를 실행하려는 각 시스템에 Red Hat Single Sign-On 배포 사본이 있어야 합니다. 이 모드는 처음에 쉽게 배포할 수 있지만 다소 어려움을 겪을 수 있습니다. 구성을 변경하려면 각 머신의 각 배포를 수정합니다. 대규모 클러스터의 경우 이 모드는 시간이 오래 걸리며 오류가 발생할 수 있습니다.

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

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

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

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

./bin/jboss-cli.sh --file=docs/examples/enable-elytron-se17.cli -Dconfig=standalone-ha.xml

$ ./bin/jboss-cli.sh --file=docs/examples/enable-elytron-se17.cli -Dconfig=standalone-ha.xml

> .\bin\jboss-cli.bat --file=docs\examples\enable-elytron-se17.cli "-Dconfig=standalone-ha.xml"

> .\bin\jboss-cli.bat --file=docs\examples\enable-elytron-se17.cli "-Dconfig=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>

    <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>

    <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

$ 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>

    <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>
        <!-- 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>

    <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.sh --host-config=host-master.xml

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

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

./bin/jboss-cli.sh --file=docs/examples/enable-keycloak-se17-domain.cli

$ ./bin/jboss-cli.sh --file=docs/examples/enable-keycloak-se17-domain.cli

> .\bin\jboss-cli.bat --file=docs\examples\enable-keycloak-se17-domain.cli

> .\bin\jboss-cli.bat --file=docs\examples\enable-keycloak-se17-domain.cli

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

Red Hat SSO 8 대신 도입될 제품인 RHBK(Keycloak)의 향후 릴리스를 위해 교차 사이트 복제에 대한 새로운 솔루션이 논의되고 있습니다. 더 자세한 내용은 곧 제공될 예정입니다.

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

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

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

<spi name="myspi">
    <default-provider>myprovider</default-provider>
    <properties>
        <property name="spi-foo" value="spi-bar"/>
    </properties>
    <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 name="myspi">
    <default-provider>myprovider</default-provider>
    <properties>
        <property name="spi-foo" value="spi-bar"/>
    </properties>
    <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를 선택하는 데 도움이 될 수 있습니다.

SPI 속성을 사용하여 SPI별 구성 속성을 지정할 수 있습니다. 예를 들어 사용자,클라이언트 및 역할 SPI를 사용하면 다음과 같이 storageProviderTimeout 속성을 통해 스토리지 공급자 시간 초과를 밀리초 단위로 구성할 수 있습니다.

<spi name="user">
    <properties>
        <property name="storageProviderTimeout" value="10000"/>
    </properties>
</spi>

<spi name="user">
    <properties>
        <property name="storageProviderTimeout" value="10000"/>
    </properties>
</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>

<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.sh

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

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

그러면 다음과 같은 프롬프트가 표시됩니다.

[disconnected /]

[disconnected /]

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

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

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

"I did not enter in any username or password!" 자신을 생각할 수 있습니다. 실행 중인 독립 실행형 서버 또는 도메인 컨트롤러와 동일한 시스템에서 jboss-cli 를 실행하고 계정에 적절한 파일 권한이 있는 경우, 관리자 사용자 이름 및 암호를 설정하거나 입력할 필요가 없습니다. 해당 설정에 문제가 있을 경우 보다 안전하게 작업을 수행하는 방법에 대한 자세한 내용은 JBoss EAP 구성 가이드를 참조하십시오.

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

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

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

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

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

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

/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

$ .../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)

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

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

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

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

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

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

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

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

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

**/spi=mySPI/:map-put(name=properties, key=storageProviderTimeout, value=10000)

**/spi=mySPI/:map-put(name=properties, key=storageProviderTimeout, value=10000)

**/spi=mySPI/:map-remove(name=properties, key=storageProviderTimeout)

**/spi=mySPI/:map-remove(name=properties, key=storageProviderTimeout)

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

**/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-put(name=properties,key=lockWaitTimeout,value=3)

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

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

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

**/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을 정의합니다.

서버가 부팅될 때 로드되고 사용 가능하게 되도록 JDBC를 배포 프로필에 선언합니다.

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

  <subsystem xmlns="urn:jboss:domain:datasources:6.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>

  <subsystem xmlns="urn:jboss:domain:datasources:6.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>

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

<subsystem xmlns="urn:jboss:domain:keycloak-server:1.2">
    ...
    <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>

<subsystem xmlns="urn:jboss:domain:keycloak-server:1.2">
    ...
    <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 및ECDHE 필드에 대한 유니코드 문자 세트를 설정할 수 있는지 여부입니다. 그렇지 않으면 일반적으로 유니코드가 필드 길이를 대신할 가능성이 높습니다. NVARCHAR 및 NCHAR 필드에서 유니코드만 지원하는 경우 모든 텍스트 필드에 대한 유니코드 지원은 Keycloak 스키마에서 VARCHAR 및ECDHE 필드를 광범위하게 사용하므로 거의 없습니다.

show server_encoding;

show server_encoding;

create database keycloak with encoding 'UTF8';

create database keycloak with encoding 'UTF8';

기본 호스트 이름 공급자는 구성된 frontendUrl (사용자 에이전트에서 요청)의 기본 URL을 사용하고(클라이언트의 직접 요청) 요청 URL을 기반으로 사용합니다.

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

그러면 내부 클라이언트가 내부 도메인 이름 또는 IP 주소를 사용할 수 있는 반면 브라우저의 사용자는 공개 도메인 이름을 통해 Red Hat Single Sign-On에 요청을 보낼 수 있습니다.

이는 OpenID Connect 검색 끝점에 반영되며, 여기에는 authorization_endpoint 에서 프런트 엔드 URL을 사용하는 반면 token_endpoint 는 백엔드 URL을 사용합니다. 여기에서 인스턴스의 공용 클라이언트는 공용 끝점을 통해 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>

<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=default:write-attribute(name=properties.frontendUrl,value="https://auth.example.com")

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

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

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

공개 도메인에 관리자 끝점과 콘솔을 노출하지 않으려면 adminUrl 속성을 사용하여 admin 콘솔의 고정 URL을 설정합니다. 이 URL은 frontendUrl 과 다릅니다. 또한 서버 관리 가이드를 참조하는 방법에 대한 자세한 내용은 외부에서 /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 이외의 다른 항목에 바인딩하도록 네트워크 인터페이스를 설정해야 합니다.

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

standalone.sh -b 192.168.0.5

$ standalone.sh -b 192.168.0.5

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

또는 명령줄에서 바인딩 주소를 설정하지 않으려면 배포의 프로필 구성을 편집할 수 있습니다. 프로필 구성 파일(standalone.xml 또는 운영 모드에따라 domain.xml )을 열고 interfaces 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>

    <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

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

b는 이 명령에 대한 간단한 표기법입니다. 따라서 프로필 구성에서 직접 바인딩 주소 값을 변경하거나 부팅 시 명령줄에서 변경할 수 있습니다.

각 소켓에 대해 열린 포트에는 명령줄 또는 구성 내에서 재정의할 수 있는 사전 정의된 기본값이 있습니다. 이 구성을 설명하기 위해 독립 실행형 모드에서 실행 중인 것으로 가정하고 …​/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-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>

    <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 관리 콘솔에서 구성할 수 있습니다.

역방향 프록시 또는 로드 밸런서를 사용하여 HTTPS 트래픽을 처리하지 않는 경우 Red Hat Single Sign-On 서버에 대해 HTTPS를 활성화해야 합니다. 여기에는 다음이 포함됩니다.

keytool -genkey -alias localhost -keyalg RSA -keystore keycloak.jks -validity 10950

$ 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

Red Hat Single Sign-On 서버는 보호되는 애플리케이션 및 서비스에 대해 브라우저 이외의 HTTP 요청을 수행해야 하는 경우가 많습니다. auth 서버는 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>

<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://www-proxy.acme.com:8080

.*\.(google|googleapis)\.com;http://user01:pas2w0rd@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
All requests to internal systems should use no proxy
All other requests should use http://fallback:8080 as proxy

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

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>

<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>

HTTPS_PROXY=https://www-proxy.acme.com:8080
NO_PROXY=google.com,login.facebook.com

HTTPS_PROXY=https://www-proxy.acme.com:8080
NO_PROXY=google.com,login.facebook.com

<spi name="connectionsHttpClient">
    <provider name="default" enabled="true">
        <properties>
            <property name="proxy-mappings" value=".*;NO_PROXY"/>
        </properties>
    </provider>
</spi>

<spi name="connectionsHttpClient">
    <provider name="default" enabled="true">
        <properties>
            <property name="proxy-mappings" value=".*;NO_PROXY"/>
        </properties>
    </provider>
</spi>

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

$ 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"/>
        </properties>
    </provider>
</spi>

<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>

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:12.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:12.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:12.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:12.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:12.0">
    ...
    <http-listener name="default" socket-binding="http"
        proxy-address-forwarding="true" redirect-socket="proxy-https"/>
    ...
</subsystem>

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

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-master.xml -Djboss.bind.address=192.168.0.2 -Djboss.bind.address.management=192.168.0.2

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

$ 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)와 2개 이상의 Red Hat Single Sign-On 서버로 구성됩니다. 성능을 위해 로드 밸런서가 특정 브라우저 세션과 관련된 모든 요청을 동일한 Red Hat Single Sign-On 백엔드 노드로 전달하는 경우 유용할 수 있습니다.

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

예를 들어 ID 10.0.0.1을 사용하여 인증 세션을 node1 의 Infinispan 캐시에 저장한 다음 node2 에서 이 세션을 조회해야 하는 경우 특정 세션 엔티티를 반환하기 위해 네트워크를 통해 node1 에 요청을 보내야 합니다.

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

이 시점에서 로드 밸런서가 모든 다음 요청을 node2 로 전달하는 것이 좋습니다. 이 경우 ID 10.0.0.1이 있는 인증 세션의 소유자이므로 Infinispan이 이 세션을 로컬로 조회할 수 있습니다. 인증이 완료되면 인증 세션이 사용자 세션으로 변환되며 ID가 동일하기 때문에 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

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.2">
  ...
    <spi name="stickySessionEncoder">
        <provider name="infinispan" enabled="true">
            <properties>
                <property name="shouldAttachRoute" value="false"/>
            </properties>
        </provider>
    </spi>

</subsystem>

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

</subsystem>

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

Red Hat Single Sign-On의 클러스터링 하위 시스템은 10.0.0.1 스택에서 실행됩니다. 기본적으로 클러스터링에 대한 바인딩 주소는 기본 IP 주소로 127.0.0.1을 사용하는 개인 네트워크 인터페이스에 바인딩됩니다.

클러스터 노드가 프라이빗 네트워크에서 격리된 경우 클러스터에 참여하거나 클러스터에서 통신을 보려면 사설 네트워크에 액세스해야 합니다. 또한 클러스터 통신에 대해 인증 및 암호화를 활성화할 수도 있습니다. 개인 네트워크가 안전한 경우 인증 및 암호화를 활성화할 필요가 없습니다. 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>

<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/standalone.sh --server-config=standalone-ha.xml

bin/domain.sh --host-config=host-master.xml
bin/domain.sh --host-config=host-slave.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:12.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>

<subsystem xmlns="urn:jboss:domain:infinispan:12.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 가 있습니다. 이 캐시는 기본적으로 바인딩되지 않습니다. 그러나 이 캐시는 이 캐시의 항목이 매우 수명이 짧기 때문에 메모리 문제가 발생하지 않아야 합니다.

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

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

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

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

여기서는 두 개 이상의 노드가 하나의 특정 사용자 로그인 세션을 복제하도록 변경되었습니다.

영역 또는 사용자 캐시를 비활성화할 수 있습니다.

영역 캐시, 사용자 캐시 또는 외부 공개 키를 지울 수 있습니다.

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

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

oc describe keycloak <CR-name>

$ 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:

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

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>

$ 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>

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: 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

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

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

oc describe keycloak <CR-name>

$ 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>

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
    credentials:
      - type: "password"
        value: "12345"
    realmRoles:
      - "offline_access"
    clientRoles:
      account:
        - "manage-account"
      realm-management:
        - "manage-users"
  realmSelector:
    matchLabels:
      app: sso

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
    credentials:
      - type: "password"
        value: "12345"
    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

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

Operator가 사용자 정의 리소스를 처리한 후 다음 명령으로 상태를 봅니다.

oc describe keycloak <CR-name>

$ 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>

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-db-secret YAML 파일을 생성하고 Keycloak CR externalDatabase 속성을 enabled로 설정하여 외부 PostgreSQL 데이터베이스에 연결할 수 있습니다. 값은 Base64로 인코딩됩니다.

apiVersion: v1
kind: Secret
metadata:
    name: keycloak-db-secret
    namespace: keycloak
stringData:
    POSTGRES_DATABASE: <Database Name>
    POSTGRES_EXTERNAL_ADDRESS: <External Database URL (resolvable by K8s)>
    POSTGRES_EXTERNAL_PORT: <External Database Port>
    POSTGRES_PASSWORD: <Database Password>
    # Required for AWS Backup functionality
    POSTGRES_SUPERUSER: "true"
    POSTGRES_USERNAME: <Database Username>
    SSLMODE: <TLS configuration for the Database connection>
type: Opaque

apiVersion: v1
kind: Secret
metadata:
    name: keycloak-db-secret
    namespace: keycloak
stringData:
    POSTGRES_DATABASE: <Database Name>
    POSTGRES_EXTERNAL_ADDRESS: <External Database URL (resolvable by K8s)>
    POSTGRES_EXTERNAL_PORT: <External Database Port>
    POSTGRES_PASSWORD: <Database Password>
    # Required for AWS Backup functionality
    POSTGRES_SUPERUSER: "true"
    POSTGRES_USERNAME: <Database Username>
    SSLMODE: <TLS configuration for the Database connection>
type: Opaque

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

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

SSLMODE 가 활성화되면 Operator는 PostgreSQL 데이터베이스에서 사용한 root.crt 가 포함된 keycloak-db-ssl-cert-secret 이라는 시크릿을 검색합니다. 보안 생성은 선택 사항이며 데이터베이스의 인증서를 확인하려는 경우에만 시크릿이 사용됩니다(예: SSLMODE: verify-ca). 예를 들면 다음과 같습니다.

apiVersion: v1
kind: Secret
metadata:
  name: keycloak-db-ssl-cert-secret
  namespace: keycloak
type: Opaque
data:
  root.crt: {root.crt base64}

apiVersion: v1
kind: Secret
metadata:
  name: keycloak-db-ssl-cert-secret
  namespace: keycloak
type: Opaque
data:
  root.crt: {root.crt base64}

Operator는 keycloak-postgresql 이라는 서비스를 생성합니다. 이 서비스는 POSTGRES_EXTERNAL_ADDRESS 의 콘텐츠에 따라 외부 데이터베이스를 노출하도록 Operator에 의해 구성됩니다. Red Hat Single Sign-On은 이 서비스를 사용하여 데이터베이스에 연결하므로 이 서비스를 통해 데이터베이스에 직접 연결하지 않습니다.

Keycloak 사용자 정의 리소스를 사용하려면 외부 데이터베이스 지원을 활성화하기 위해 업데이트해야 합니다.

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

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

이 Operator는 외부 Red Hat Single Sign-On 인스턴스를 부분적으로 관리하는 데 사용할 수도 있습니다. 현재 상태에서는 클라이언트만 생성할 수 있습니다.

이렇게 하려면 대상 및 구성에 사용할 Keycloak 및 KeycloakRealm CRD의 관리되지 않는 버전을 생성해야 합니다.

apiVersion: keycloak.org/v1alpha1
kind: Keycloak
metadata:
  name: external-ref
  labels:
    app: external-sso
spec:
  unmanaged: true
  external:
    enabled: true
    url: https://some.external.url

apiVersion: keycloak.org/v1alpha1
kind: Keycloak
metadata:
  name: external-ref
  labels:
    app: external-sso
spec:
  unmanaged: true
  external:
    enabled: true
    url: https://some.external.url

이 keycloak에 대해 인증하기 위해 Operator는 CRD 이름 앞에 credential- 을 접두사로 지정하여 CRD에서 보안 이름을 유추합니다.

apiVersion: v1
kind: Secret
metadata:
  name: credential-external-ref
type: Opaque
data:
  ADMIN_USERNAME: YWRtaW4=
  ADMIN_PASSWORD: cGFzcw==

apiVersion: v1
kind: Secret
metadata:
  name: credential-external-ref
type: Opaque
data:
  ADMIN_USERNAME: YWRtaW4=
  ADMIN_PASSWORD: cGFzcw==

apiVersion: keycloak.org/v1alpha1
kind: KeycloakRealm
metadata:
  name: external-realm
  labels:
    app: external-sso
spec:
  unmanaged: true
  realm:
    id: "basic"
    realm: "basic"
  instanceSelector:
    matchLabels:
      app: external-sso

apiVersion: keycloak.org/v1alpha1
kind: KeycloakRealm
metadata:
  name: external-realm
  labels:
    app: external-sso
spec:
  unmanaged: true
  realm:
    id: "basic"
    realm: "basic"
  instanceSelector:
    matchLabels:
      app: external-sso

이제 클라이언트에서 정상적으로 영역 참조를 사용할 수 있으며 외부 Red Hat Single Sign-On 인스턴스에 클라이언트를 생성합니다.

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

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

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

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

운영자를 사용하여 회사 또는 조직에 필요한 확장 기능 및 주제를 설치할 수 있습니다. 확장 또는 주제는 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

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

주제를 다른 확장 프로그램과 동일한 방식으로 패키징하고 배포할 수 있습니다. 자세한 내용은 Themes 수동 항목 배포를 참조하십시오.

Operator는 확장 또는me을 다운로드하여 설치합니다.

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

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

oc edit test-realm

$ oc edit test-realm

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

Operator가 Red Hat Single Sign-On 업그레이드를 수행하는 방법을 구성할 수 있습니다. 다음 업그레이드 전략 중에서 선택할 수 있습니다.

apiVersion: keycloak.org/v1alpha1
kind: Keycloak
metadata:
  name: example-keycloak
  labels:
   app: sso
spec:
  instances: 2
  migration:
    strategy: recreate
    backups:
      enabled: True
  externalAccess:
    enabled: True

apiVersion: keycloak.org/v1alpha1
kind: Keycloak
metadata:
  name: example-keycloak
  labels:
   app: sso
spec:
  instances: 2
  migration:
    strategy: recreate
    backups:
      enabled: True
  externalAccess:
    enabled: True