2장. OpenID Connect를 사용하여 애플리케이션 및 서비스 보안

JBoss EAP는 동일한 JBoss EAP 인스턴스에 배포된 웹 애플리케이션에 대한 SSO(Single Sign-On)를 기본적으로 지원합니다. Red Hat Single Sign-On을 사용할 때는 이 기능을 활성화해서는 안 됩니다.

이 섹션에서는 WAR 패키지에 구성을 추가하고 파일을 편집하여 WAR를 직접 보호하는 방법을 설명합니다.

Red Hat Single Sign-On으로 보안을 위해 WAR를 수정할 필요는 없습니다. 대신 Red Hat SSO(Single Sign-On Adapter)를 통해 외부에서 보호할 수 있습니다. KEYCLOAK을 auth-method 로 지정할 필요는 없지만 web.xml 에서 security-constraints 를 정의해야 합니다. 그러나 WEB-INF/keycloak.json 파일을 만들 필요가 없습니다. 메타데이터는 Red Hat Single Sign-On 하위 시스템 정의의 서버 구성(standalone.xml) 내에 정의됩니다.

<extensions>
  <extension module="org.keycloak.keycloak-adapter-subsystem"/>
</extensions>

<profile>
  <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
     <secure-deployment name="WAR MODULE NAME.war">
        <realm>demo</realm>
        <auth-server-url>http://localhost:8081/auth</auth-server-url>
        <ssl-required>external</ssl-required>
        <resource>customer-portal</resource>
        <credential name="secret">password</credential>
     </secure-deployment>
  </subsystem>
</profile>

secure-deployment 이름 속성은 보안하려는 WAR를 식별합니다. 해당 값은 .war 가 추가된 web.xml 에 정의된 module-name 입니다. 나머지 구성은 Java 어댑터 구성에 정의된 keycloak.json 구성 옵션과 함께 1과 거의 일치합니다.

예외는 credential 요소입니다.

보다 쉽게 사용할 수 있도록 Red Hat Single Sign-On 관리 콘솔로 이동하여 이 WAR에 맞게 애플리케이션의 클라이언트/설치 탭으로 이동합니다. 잘라내고 붙여넣을 수 있는 XML 파일 예제를 제공합니다.

동일한 영역에서 보안된 여러 배포가 있는 경우 별도의 요소에서 영역 구성을 공유할 수 있습니다. 예를 들면 다음과 같습니다.

<subsystem xmlns="urn:jboss:domain:keycloak:1.1">
    <realm name="demo">
        <auth-server-url>http://localhost:8080/auth</auth-server-url>
        <ssl-required>external</ssl-required>
    </realm>
    <secure-deployment name="customer-portal.war">
        <realm>demo</realm>
        <resource>customer-portal</resource>
        <credential name="secret">password</credential>
    </secure-deployment>
    <secure-deployment name="product-portal.war">
        <realm>demo</realm>
        <resource>product-portal</resource>
        <credential name="secret">password</credential>
    </secure-deployment>
    <secure-deployment name="database.war">
        <realm>demo</realm>
        <resource>database-service</resource>
        <bearer-only>true</bearer-only>
    </secure-deployment>
</subsystem>

보안 컨텍스트는 Egress 계층으로 자동 전파됩니다.

먼저 Red Hat Single Sign-On Karaf 기능을 설치해야 합니다. 다음으로 보안하려는 애플리케이션 유형에 따라 단계를 수행해야 합니다. 참조된 모든 웹 애플리케이션에서는 Red Hat Single Sign-On Cryostatty 인증기를 기본 Cryostat 서버에 삽입해야 합니다. 이를 수행하는 단계는 애플리케이션 유형에 따라 다릅니다. 자세한 내용은 아래에 설명되어 있습니다.

먼저 JBoss Fuse 환경에 keycloak 기능을 설치해야 합니다. keycloak 기능에는 Fuse 어댑터와 모든 타사 종속 항목이 포함되어 있습니다. Maven 리포지토리 또는 아카이브에서 설치할 수 있습니다.

기존 WAR 애플리케이션으로 배포되지 않은 OSGI 번들 프로젝트 내부에 서블릿 클래스가 있는 경우 이 방법을 사용할 수 있습니다. Fuse는 Pax Web whiteboard Extender를 사용하여 웹 애플리케이션과 같은 서블릿을 배포합니다.

KeycloakJettyAuthenticator 및 적절한 보안 제약 조건을 사용하여 securityHandler를 추가하여 camel-jetty 구성 요소로 구현된 Apache Camel 엔드포인트를 보호할 수 있습니다. 다음과 같은 구성으로 Camel 애플리케이션에 OSGI-INF/blueprint/blueprint.xml 파일을 추가할 수 있습니다. 역할, 보안 제약 조건 매핑 및 Red Hat Single Sign-On 어댑터 구성은 환경과 필요에 따라 약간 다를 수 있습니다.

예를 들면 다음과 같습니다.

<?xml version="1.0" encoding="UTF-8"?>

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:camel="http://camel.apache.org/schema/blueprint"
           xsi:schemaLocation="
       http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
       http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd">

    <bean id="kcAdapterConfig" class="org.keycloak.representations.adapters.config.AdapterConfig">
        <property name="realm" value="demo"/>
        <property name="resource" value="admin-camel-endpoint"/>
        <property name="bearerOnly" value="true"/>
        <property name="authServerUrl" value="http://localhost:8080/auth" />
        <property name="sslRequired" value="EXTERNAL"/>
    </bean>

    <bean id="keycloakAuthenticator" class="org.keycloak.adapters.jetty.KeycloakJettyAuthenticator">
        <property name="adapterConfig" ref="kcAdapterConfig"/>
    </bean>

    <bean id="constraint" class="org.eclipse.jetty.util.security.Constraint">
        <property name="name" value="Customers"/>
        <property name="roles">
            <list>
                <value>admin</value>
            </list>
        </property>
        <property name="authenticate" value="true"/>
        <property name="dataConstraint" value="0"/>
    </bean>

    <bean id="constraintMapping" class="org.eclipse.jetty.security.ConstraintMapping">
        <property name="constraint" ref="constraint"/>
        <property name="pathSpec" value="/*"/>
    </bean>

    <bean id="securityHandler" class="org.eclipse.jetty.security.ConstraintSecurityHandler">
        <property name="authenticator" ref="keycloakAuthenticator" />
        <property name="constraintMappings">
            <list>
                <ref component-id="constraintMapping" />
            </list>
        </property>
        <property name="authMethod" value="BASIC"/>
        <property name="realmName" value="does-not-matter"/>
    </bean>

    <bean id="sessionHandler" class="org.keycloak.adapters.jetty.spi.WrappingSessionHandler">
        <property name="handler" ref="securityHandler" />
    </bean>

    <bean id="helloProcessor" class="org.keycloak.example.CamelHelloProcessor" />

    <camelContext id="blueprintContext"
                  trace="false"
                  xmlns="http://camel.apache.org/schema/blueprint">
        <route id="httpBridge">
            <from uri="jetty:http://0.0.0.0:8383/admin-camel-endpoint?handlers=sessionHandler&amp;matchOnUriPrefix=true" />
            <process ref="helloProcessor" />
            <log message="The message from camel endpoint contains ${body}"/>
        </route>
    </camelContext>

</blueprint>

javax.servlet;version="[3,4)",
javax.servlet.http;version="[3,4)",
org.apache.camel.*,
org.apache.camel;version="[2.13,3)",
org.eclipse.jetty.security;version="[9,10)",
org.eclipse.jetty.server.nio;version="[9,10)",
org.eclipse.jetty.util.security;version="[9,10)",
org.keycloak.*;version="18.0.14.redhat-00001",
org.osgi.service.blueprint,
org.osgi.service.blueprint.container,
org.osgi.service.event,

Camel RestDSL은 유창한 방식으로 REST 엔드포인트를 정의하는 데 사용되는 Camel 기능입니다. 그러나 특정 구현 클래스를 계속 사용하고 Red Hat Single Sign-On과 통합하는 방법에 대한 지침을 제공해야 합니다.

통합 메커니즘을 구성하는 방법은 RestDSL 정의 경로를 구성하는 Camel 구성 요소에 따라 다릅니다.

다음 예제에서는 이전 블루프린트 예제에 정의된 일부 빈에 대한 참조와 함께 Cryostat 구성 요소를 사용하여 통합을 구성하는 방법을 보여줍니다.

<bean id="securityHandlerRest" class="org.eclipse.jetty.security.ConstraintSecurityHandler">
    <property name="authenticator" ref="keycloakAuthenticator" />
    <property name="constraintMappings">
        <list>
            <ref component-id="constraintMapping" />
        </list>
    </property>
    <property name="authMethod" value="BASIC"/>
    <property name="realmName" value="does-not-matter"/>
</bean>

<bean id="sessionHandlerRest" class="org.keycloak.adapters.jetty.spi.WrappingSessionHandler">
    <property name="handler" ref="securityHandlerRest" />
</bean>


<camelContext id="blueprintContext"
              trace="false"
              xmlns="http://camel.apache.org/schema/blueprint">

    <restConfiguration component="jetty" contextPath="/restdsl"
                       port="8484">
        <!--the link with Keycloak security handlers happens here-->
        <endpointProperty key="handlers" value="sessionHandlerRest"></endpointProperty>
        <endpointProperty key="matchOnUriPrefix" value="true"></endpointProperty>
    </restConfiguration>

    <rest path="/hello" >
        <description>Hello rest service</description>
        <get uri="/{id}" outType="java.lang.String">
            <description>Just an helllo</description>
            <to uri="direct:justDirect" />
        </get>

    </rest>

    <route id="justDirect">
        <from uri="direct:justDirect"/>
        <process ref="helloProcessor" />
        <log message="RestDSL correctly invoked ${body}"/>
        <setBody>
            <constant>(__This second sentence is returned from a Camel RestDSL endpoint__)</constant>
        </setBody>
    </route>

</camelContext>

META-INF.cxf;version="[2.7,3.2)",
META-INF.cxf.osgi;version="[2.7,3.2)";resolution:=optional,
org.apache.cxf.bus;version="[2.7,3.2)",
org.apache.cxf.bus.spring;version="[2.7,3.2)",
org.apache.cxf.bus.resource;version="[2.7,3.2)",
org.apache.cxf.transport.http;version="[2.7,3.2)",
org.apache.cxf.*;version="[2.7,3.2)",
org.springframework.beans.factory.config,
org.eclipse.jetty.security;version="[9,10)",
org.eclipse.jetty.util.security;version="[9,10)",
org.keycloak.*;version="18.0.14.redhat-00001"

일부 서비스는 시작 시 배포된 서블릿과 함께 자동으로 제공됩니다. 이러한 서비스 중 하나는 http://localhost:8181/cxf 컨텍스트에서 실행되는 CXF 서블릿입니다. 이러한 끝점을 보호하는 것은 복잡할 수 있습니다. Red Hat Single Sign-On이 현재 사용 중인 한 가지 접근 방식은 시작 시 기본 제공 서블릿을 배포 취소하는 ServletReregistrationService로, Red Hat Single Sign-On이 보호하는 컨텍스트에 재배포할 수 있습니다.

애플리케이션 내의 구성 파일 OSGI-INF/blueprint/blueprint.xml 은 아래 파일과 유사할 수 있습니다. 애플리케이션에 고유한 엔드포인트인 Cryostat-RS customerservice 엔드포인트를 추가하지만 더 중요한 것은 전체 /cxf 컨텍스트를 보호합니다.

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs"
           xsi:schemaLocation="
		http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
		http://cxf.apache.org/blueprint/jaxrs http://cxf.apache.org/schemas/blueprint/jaxrs.xsd">

    <!-- JAXRS Application -->

    <bean id="customerBean" class="org.keycloak.example.rs.CxfCustomerService" />

    <jaxrs:server id="cxfJaxrsServer" address="/customerservice">
        <jaxrs:providers>
            <bean class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
        </jaxrs:providers>
        <jaxrs:serviceBeans>
            <ref component-id="customerBean" />
        </jaxrs:serviceBeans>
    </jaxrs:server>


    <!-- Securing of whole /cxf context by unregister default cxf servlet from paxweb and re-register with applied security constraints -->

    <bean id="cxfConstraintMapping" class="org.eclipse.jetty.security.ConstraintMapping">
        <property name="constraint">
            <bean class="org.eclipse.jetty.util.security.Constraint">
                <property name="name" value="cst1"/>
                <property name="roles">
                    <list>
                        <value>user</value>
                    </list>
                </property>
                <property name="authenticate" value="true"/>
                <property name="dataConstraint" value="0"/>
            </bean>
        </property>
        <property name="pathSpec" value="/cxf/*"/>
    </bean>

    <bean id="cxfKeycloakPaxWebIntegration" class="org.keycloak.adapters.osgi.PaxWebIntegrationService"
          init-method="start" destroy-method="stop">
        <property name="bundleContext" ref="blueprintBundleContext" />
        <property name="jettyWebXmlLocation" value="/WEB-INF/jetty-web.xml" />
        <property name="constraintMappings">
            <list>
                <ref component-id="cxfConstraintMapping" />
            </list>
        </property>
    </bean>

    <bean id="defaultCxfReregistration" class="org.keycloak.adapters.osgi.ServletReregistrationService" depends-on="cxfKeycloakPaxWebIntegration"
          init-method="start" destroy-method="stop">
        <property name="bundleContext" ref="blueprintBundleContext" />
        <property name="managedServiceReference">
            <reference interface="org.osgi.service.cm.ManagedService" filter="(service.pid=org.apache.cxf.osgi)" timeout="5000"  />
        </property>
    </bean>

</blueprint>

결과적으로 기본 CXF HTTP 대상에서 실행되는 다른 모든 CXF 서비스도 보호됩니다. 마찬가지로 애플리케이션이 배포 취소되면 전체 /cxf 컨텍스트도 안전하지 않습니다. 이러한 이유로 별도의 CXF 엔진의 Secure CXF Application에 설명된 대로 애플리케이션에 고유한 Cryostat 엔진 을 사용하면 각 개별 애플리케이션에 대한 보안을 보다 효과적으로 제어할 수 있습니다.

META-INF.cxf;version="[2.7,3.2)",
META-INF.cxf.osgi;version="[2.7,3.2)";resolution:=optional,
org.apache.cxf.transport.http;version="[2.7,3.2)",
org.apache.cxf.*;version="[2.7,3.2)",
com.fasterxml.jackson.jaxrs.json;version="[2.5,3)",
org.eclipse.jetty.security;version="[9,10)",
org.eclipse.jetty.util.security;version="[9,10)",
org.keycloak.*;version="18.0.14.redhat-00001",
org.keycloak.adapters.jetty;version="18.0.14.redhat-00001",
*;resolution:=optional

Red Hat Single Sign-On을 사용하여 Hawtio 관리 콘솔을 보호하려면 다음 절차를 수행합니다.

{
  "realm" : "demo",
  "resource" : "hawtio-client",
  "auth-server-url" : "http://localhost:8080/auth",
  "ssl-required" : "external",
  "public-client" : true
}

먼저 Red Hat Single Sign-On Karaf 기능을 설치해야 합니다. 다음으로 보안하려는 애플리케이션 유형에 따라 단계를 수행해야 합니다. 참조된 모든 웹 애플리케이션에서는 Red Hat Single Sign-On Cryostat 인증 메커니즘을 기본 웹 서버에 삽입해야 합니다. 이를 수행하는 단계는 애플리케이션 유형에 따라 다릅니다. 자세한 내용은 아래에 설명되어 있습니다.

먼저 JBoss Fuse 환경에서 keycloak-pax-http-undertow 및 keycloak-jaas 기능을 설치해야 합니다. keycloak-pax-http-undertow 기능에는 Fuse 어댑터 및 모든 타사 종속 항목이 포함되어 있습니다. keycloak-jaas 에는 SSH 및 Cryostat 인증에 사용되는 JAAS 모듈이 포함되어 있습니다. Maven 리포지토리 또는 아카이브에서 설치할 수 있습니다.

기존 WAR 애플리케이션으로 배포되지 않은 OSGI 번들 프로젝트 내부에 서블릿 클래스가 있는 경우 이 방법을 사용할 수 있습니다. Fuse는 Pax Web whiteboard Extender를 사용하여 웹 애플리케이션과 같은 서블릿을 배포합니다.

블루프린트를 통해 적절한 보안 제약 조건을 삽입하고 사용된 구성 요소를 undertow-keycloak 로 업데이트하여 camel-undertow 구성 요소로 구현된 Apache Camel 엔드포인트를 보호할 수 있습니다. 다음과 같은 구성으로 Camel 애플리케이션에 OSGI-INF/blueprint/blueprint.xml 파일을 추가해야 합니다. 역할, 보안 제약 조건 매핑 및 어댑터 구성은 환경과 필요에 따라 약간 다를 수 있습니다.

표준 undertow 구성 요소와 비교하여 undertow-keycloak 구성 요소는 두 가지 새 속성을 추가합니다.

예를 들면 다음과 같습니다.

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:camel="http://camel.apache.org/schema/blueprint"
           xsi:schemaLocation="
       http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
       http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint-2.17.1.xsd">

    <bean id="keycloakConfigResolver" class="org.keycloak.adapters.osgi.BundleBasedKeycloakConfigResolver" >
        <property name="bundleContext" ref="blueprintBundleContext" />
    </bean>

    <bean id="helloProcessor" class="org.keycloak.example.CamelHelloProcessor" />

    <camelContext id="blueprintContext"
                  trace="false"
                  xmlns="http://camel.apache.org/schema/blueprint">

        <route id="httpBridge">
            <from uri="undertow-keycloak:http://0.0.0.0:8383/admin-camel-endpoint?matchOnUriPrefix=true&amp;configResolver=#keycloakConfigResolver&amp;allowedRoles=admin" />
            <process ref="helloProcessor" />
            <log message="The message from camel endpoint contains ${body}"/>
        </route>

    </camelContext>

</blueprint>

javax.servlet;version="[3,4)",
javax.servlet.http;version="[3,4)",
javax.net.ssl,
org.apache.camel.*,
org.apache.camel;version="[2.13,3)",
io.undertow.*,
org.keycloak.*;version="18.0.14.redhat-00001",
org.osgi.service.blueprint,
org.osgi.service.blueprint.container

Camel RestDSL은 유창한 방식으로 REST 엔드포인트를 정의하는 데 사용되는 Camel 기능입니다. 그러나 특정 구현 클래스를 계속 사용하고 Red Hat Single Sign-On과 통합하는 방법에 대한 지침을 제공해야 합니다.

통합 메커니즘을 구성하는 방법은 RestDSL 정의 경로를 구성하는 Camel 구성 요소에 따라 다릅니다.

다음 예제에서는 undertow-keycloak 구성 요소를 사용하여 통합을 구성하는 방법과 이전 블루프린트 예제에 정의된 일부 빈에 대한 참조를 보여줍니다.

<camelContext id="blueprintContext"
              trace="false"
              xmlns="http://camel.apache.org/schema/blueprint">

    <!--the link with Keycloak security handlers happens by using undertow-keycloak component -->
    <restConfiguration apiComponent="undertow-keycloak" contextPath="/restdsl" port="8484">
        <endpointProperty key="configResolver" value="#keycloakConfigResolver" />
        <endpointProperty key="allowedRoles" value="admin,superadmin" />
    </restConfiguration>

    <rest path="/hello" >
        <description>Hello rest service</description>
        <get uri="/{id}" outType="java.lang.String">
            <description>Just a hello</description>
            <to uri="direct:justDirect" />
        </get>

    </rest>

    <route id="justDirect">
        <from uri="direct:justDirect"/>
        <process ref="helloProcessor" />
        <log message="RestDSL correctly invoked ${body}"/>
        <setBody>
            <constant>(__This second sentence is returned from a Camel RestDSL endpoint__)</constant>
        </setBody>
    </route>

</camelContext>

별도의 Cryostat 엔진에서 Red Hat Single Sign-On에서 보안한 CXF 엔드포인트를 실행하려면 다음 절차를 수행합니다.

META-INF.cxf;version="[2.7,3.3)",
META-INF.cxf.osgi;version="[2.7,3.3)";resolution:=optional,
org.apache.cxf.bus;version="[2.7,3.3)",
org.apache.cxf.bus.spring;version="[2.7,3.3)",
org.apache.cxf.bus.resource;version="[2.7,3.3)",
org.apache.cxf.transport.http;version="[2.7,3.3)",
org.apache.cxf.*;version="[2.7,3.3)",
org.springframework.beans.factory.config,
org.keycloak.*;version="18.0.14.redhat-00001"

일부 서비스는 시작 시 배포된 서블릿과 함께 자동으로 제공됩니다. 이러한 서비스 중 하나는 http://localhost:8181/cxf 컨텍스트에서 실행되는 CXF 서블릿입니다. Fuse의 Pax Web은 구성 관리자를 통해 기존 컨텍스트 변경을 지원합니다. 이는 Red Hat Single Sign-On의 엔드포인트를 보호하는 데 사용할 수 있습니다.

애플리케이션 내의 구성 파일 OSGI-INF/blueprint/blueprint.xml 은 아래 파일과 유사할 수 있습니다. 애플리케이션 관련 엔드포인트인 Cryostat-RS customerservice 엔드포인트를 추가합니다.

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs"
           xsi:schemaLocation="
		http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
		http://cxf.apache.org/blueprint/jaxrs http://cxf.apache.org/schemas/blueprint/jaxrs.xsd">

    <!-- JAXRS Application -->
    <bean id="customerBean" class="org.keycloak.example.rs.CxfCustomerService" />

    <jaxrs:server id="cxfJaxrsServer" address="/customerservice">
        <jaxrs:providers>
            <bean class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
        </jaxrs:providers>
        <jaxrs:serviceBeans>
            <ref component-id="customerBean" />
        </jaxrs:serviceBeans>
    </jaxrs:server>
</blueprint>

또한 ${karaf.etc}/org.ops4j.pax.web.context-anyName.cfg 파일을 생성해야 합니다. pax-web-runtime 번들에 의해 추적되는 팩토리 PID 구성으로 처리됩니다. 이러한 구성에는 표준 web.xml 의 일부 속성에 해당하는 다음 속성이 포함될 수 있습니다.

bundle.symbolicName = org.apache.cxf.cxf-rt-transports-http
context.id = default

context.param.keycloak.config.resolver = org.keycloak.adapters.osgi.HierarchicalPathBasedKeycloakConfigResolver

login.config.authMethod = KEYCLOAK

security.cxf.url = /cxf/customerservice/*
security.cxf.roles = admin, user

구성 관리자 파일에서 사용 가능한 속성에 대한 자세한 내용은 Fuse 설명서를 참조하십시오. 위의 속성에는 다음과 같은 의미가 있습니다.

META-INF/MANIFEST.MF 의 Import-Package 에는 최소한 다음 가져오기가 포함되어야 합니다.

javax.ws.rs;version="[2,3)",
META-INF.cxf;version="[2.7,3.3)",
META-INF.cxf.osgi;version="[2.7,3.3)";resolution:=optional,
org.apache.cxf.transport.http;version="[2.7,3.3)",
org.apache.cxf.*;version="[2.7,3.3)",
com.fasterxml.jackson.jaxrs.json;version="${jackson.version}"

Red Hat Single Sign-On을 사용하여 Hawtio 관리 콘솔을 보호하려면 다음 절차를 수행합니다.

Spring Boot 앱을 보호하려면 앱에 Keycloak Spring Boot 어댑터 JAR을 추가해야 합니다. 그런 다음 일반 Spring Boot 구성 (application.properties)을 통해 추가 구성을 제공해야 합니다.

Keycloak Spring Boot 어댑터는 Spring Boot의 자동 구성을 사용하므로 이 어댑터 Keycloak Spring Boot Starter를 프로젝트에 추가하는 것입니다.

현재 다음 포함 컨테이너는 지원되며 Starter를 사용하는 경우 추가 종속 항목이 필요하지 않습니다.

Red Hat Single Sign-On을 사용하도록 Spring Boot 앱을 구성하려면 절차를 사용하십시오.

OAuth2 사양에 설명된 기존 방법입니다. 클라이언트에는 시크릿이 있으며 어댑터(애플리케이션)와 Red Hat Single Sign-On 서버 둘 다에 알려야 합니다. Red Hat Single Sign-On Admin Console에서 특정 클라이언트에 대한 시크릿을 생성한 다음 애플리케이션 측의 keycloak.json 파일에 이 시크릿을 붙여넣을 수 있습니다.

"credentials": {
    "secret": "19666a4f-32dd-4049-b082-684c74115f28"
}

이는 RFC7523 사양을 기반으로 합니다. 이 방법은 다음과 같습니다.

어댑터 측에 설정하려면 keycloak.json 파일에 다음과 같은 내용이 있어야 합니다.

"credentials": {
  "jwt": {
    "client-keystore-file": "classpath:keystore-client.jks",
    "client-keystore-type": "JKS",
    "client-keystore-password": "storepass",
    "client-key-password": "keypass",
    "client-key-alias": "clientkey",
    "algorithm": "RS256",
    "token-expiration": 10
  }
}

이 구성을 사용하면 WAR의 classpath에서 키 저장소 파일 keystore-client.jks 를 사용할 수 있어야 합니다. 접두사 classpath 를 사용하지 않는 경우 클라이언트 애플리케이션이 실행 중인 파일 시스템에서 파일을 가리킬 수 있습니다.

algorithm 필드는 Signed JWT에 사용되는 알고리즘을 지정하고 기본값은 RS256 입니다. 이 필드는 키 쌍과 동기화되어야 합니다. 예를 들어, RS256 알고리즘에는 ES256 알고리즘에 EC 키 쌍이 필요한 반면 RSA 키 쌍이 필요합니다. 자세한 내용은 디지털 서명 및 MAC에 대한 IRQ 그래픽 알고리즘 을 참조하십시오.

기본적으로 Red Hat Single Sign-On에서 보호하는 웹 애플리케이션은 HTTP 세션을 사용하여 보안 컨텍스트를 저장합니다. 즉, 고정 세션을 활성화하거나 HTTP 세션을 복제해야 합니다.

HTTP 세션에 보안 컨텍스트를 저장하는 대안으로 어댑터를 구성할 수 있습니다. 대신 이를 쿠키 내에 저장하도록 어댑터를 구성할 수 있습니다. 이 기능은 애플리케이션을 상태 비저장으로 설정하거나 HTTP 세션에 보안 컨텍스트를 저장하지 않으려면 유용합니다.

보안 컨텍스트를 저장하기 위해 쿠키 저장소를 사용하려면, 애플리케이션 ^ -INF/keycloak.json 을 편집하고 다음을 추가합니다.

"token-store": "cookie"

쿠키 저장소 사용의 한 가지 제한은 전체 보안 컨텍스트가 모든 HTTP 요청에 대해 쿠키로 전달된다는 것입니다. 이는 성능에 영향을 미칠 수 있습니다.

또 다른 작은 제한은 Single-Sign Out에 대한 지원이 제한됩니다. 어댑터가 KEYCLOAK_ADAPTER_STATE 쿠키를 삭제하므로 애플리케이션 자체에서 서블릿 logout(HttpServletRequest.logout)을 초기화하면 문제 없이 작동합니다. 그러나 다른 애플리케이션에서 초기화된 백 채널 로그는 Red Hat Single Sign-On에서 쿠키 저장소를 사용하는 애플리케이션에 전파되지 않습니다. 따라서 액세스 토큰 시간 초과에 짧은 값을 사용하는 것이 좋습니다(예: 1분).

Red Hat Single Sign-On과 애플리케이션이 동일한 도메인에서 호스팅되는 배포 시나리오에서는 클라이언트 구성에서 상대 URI 옵션을 사용하는 것이 편리합니다.

상대 URI를 사용하면 Red Hat Single Sign-On에 액세스하는 데 사용되는 URL에 상대적으로 URI가 확인됩니다.

예를 들어 애플리케이션의 URL이 https://acme.org/myapp 이고 Red Hat Single Sign-On의 URL이 https://acme.org/auth 인 경우 https://acme.org/myapp 대신 redirect-uri /myapp 을 사용할 수 있습니다.

특정 클라이언트의 관리자 URL은 Red Hat Single Sign-On 관리 콘솔에서 구성할 수 있습니다. Red Hat Single Sign-On 서버에서는 로그아웃 사용자 또는 해지 정책과 같은 다양한 작업의 백엔드 요청을 애플리케이션에 보내는 데 사용됩니다.

예를 들어 backchannel logout 작동 방식은 다음과 같습니다.

관리자 URL에 ${application.session.host} 가 포함된 경우 HTTP 세션과 연결된 노드의 URL로 교체됩니다.

이전 섹션에서는 Red Hat Single Sign-On이 특정 HTTP 세션과 연결된 노드에 로그 아웃 요청을 보내는 방법을 설명합니다. 그러나 경우에 따라 admin은 둘 중 하나만이 아닌 등록된 모든 클러스터 노드에 관리 작업을 전파할 수 있습니다. 예를 들어 정책 이전의 새 정책을 애플리케이션에 내보내거나 애플리케이션에서 모든 사용자를 로그아웃하는 경우입니다.

이 경우 Red Hat Single Sign-On은 모든 애플리케이션 클러스터 노드를 알고 있어야 하므로 이벤트를 모든 사용자에게 보낼 수 있습니다. 이를 위해 자동 검색 메커니즘을 지원합니다.

시작 등록 및 정기적인 재등록 전송은 일부 클러스터된 애플리케이션에만 필요하므로 기본적으로 비활성화됩니다.

기능 편집을 활성화하려면 애플리케이션에 대해 WEB-INF/keycloak.json 파일을 추가하고 다음을 추가합니다.

"register-node-at-startup": true,
"register-node-period": 600,

즉 어댑터는 시작시 등록 요청을 보내고 10분마다 다시 등록합니다.

Red Hat Single Sign-On 관리 콘솔에서 최대 노드 재등록 시간 초과를 지정할 수 있습니다( 어댑터 구성에서 register-node-period 보다 커야 함). 자동 등록 기능을 사용하지 않거나 자동 등록 기능을 사용하지 않는 경우 유용한 관리 콘솔을 통해 클러스터 노드를 수동으로 추가하고 삭제할 수도 있습니다.

기본적으로 애플리케이션 어댑터는 만료된 경우에만 액세스 토큰을 새로 고칩니다. 그러나 모든 요청에서 토큰을 새로 고치도록 어댑터를 구성할 수도 있습니다. 애플리케이션이 Red Hat Single Sign-On 서버에 더 많은 요청을 전송하므로 성능에 영향을 미칠 수 있습니다.

기능 편집을 활성화하려면 애플리케이션에 대해 WEB-INF/keycloak.json 파일을 추가하고 다음을 추가합니다.

"always-refresh-token": true