로그 메시지 앞에 메시지를 보고하는 하위 시스템의 프로젝트 코드 앞에 추가합니다. 모든 로그 메시지의 접두사가 JBoss EAP 7에서 변경되었습니다.

JBoss EAP 7에서 사용되는 새 로그 메시지 프로젝트 코드 접두사의 전체 목록은 JBoss EAP 개발 가이드 의 JBoss EAP에 사용된 프로젝트 코드를 참조하십시오.

JBoss EAP 7.0 루트 로거에는 모든 도메인 서버 프로필과 standalone -full-ha 프로필을 제외한 모든 기본 독립 실행형 프로필에 대한 콘솔 로그 핸들러가 포함되어 있습니다. JBoss EAP 7.1부터 루트 로거에는 관리형 도메인 프로필에 대한 콘솔 로그 핸들러가 더 이상 포함되지 않습니다. 호스트 컨트롤러 및 프로세스 컨트롤러는 기본적으로 콘솔에 기록합니다. JBoss EAP 7.0에서 제공된 동일한 기능을 수행하려면 JBoss EAP 의 구성 가이드에서 콘솔 로그 핸들러 구성을 참조하십시오.

Undertow는 JBoss EAP 7에서 웹 서버로 JBoss Web을 대체합니다. 즉, 레거시 웹 하위 시스템 구성을 새 JBoss EAP 7 undertow 하위 시스템 구성으로 마이그레이션해야 합니다.

관리 CLI migrate 작업을 사용하여 서버 구성 파일에서 웹 하위 시스템을 마이그레이션할 수 있습니다. 그러나 이 작업은 모든 JBoss Web 하위 시스템 구성을 마이그레이션할 수 없습니다. "migration-warning" 항목이 표시되면 추가 관리 CLI 명령을 실행하여 해당 구성을 Undertow로 마이그레이션해야 합니다. 관리 CLI 마이그레이션 작업에 대한 자세한 내용은 Management CLI Migration Operation 을 참조하십시오.

다음은 JBoss EAP 6.4의 기본 웹 하위 시스템 구성의 예입니다.

<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" native="false">
    <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
    <virtual-server name="default-host" enable-welcome-root="true">
        <alias name="localhost"/>
        <alias name="example.com"/>
    </virtual-server>
</subsystem>

다음은 JBoss EAP 7.4의 default undertow 하위 시스템 구성의 예입니다.

<subsystem xmlns="urn:jboss:domain:undertow:10.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
        <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <http-invoker security-realm="ApplicationRealm"/>
        </host>
    </server>
    ...
</subsystem>

관리 CLI 마이그레이션 작업은 재작성 조건을 자동으로 마이그레이션할 수 없습니다. 해당 이미지는 "마이그레이션 경고"로 보고되며 수동으로 마이그레이션해야 합니다. Undertow Predicates Attributes 및 Handlers 를 사용하여 JBoss EAP 7에서 동등한 구성을 생성할 수 있습니다.

다음은 재작성 구성을 포함하는 JBoss EAP 6의 웹 하위 시스템 구성의 예입니다.

<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default" native="false">
    <virtual-server name="default" enable-welcome-root="true">
        <alias name="localhost"/>
        <rewrite name="test" pattern="(.*)/toberewritten/(.*)" substitution="$1/rewritten/$2" flags="NC"/>
        <rewrite name="test2" pattern="(.*)" substitution="-" flags="F">
            <condition name="get" test="%{REQUEST_METHOD}" pattern="GET"/>
            <condition name="andCond" test="%{REQUEST_URI}" pattern=".*index.html" flags="NC"/>
        </rewrite>
    </virtual-server>
</subsystem>

관리 CLI 마이그레이션 작업 지침에 따라 서버와 관리 CLI를 시작한 다음 다음 명령을 사용하여 웹 하위 시스템 구성 파일을 마이그레이션합니다.

/subsystem=web:migrate

위의 구성에서 마이그레이션 작업을 실행할 때 다음 "migration-warnings"가 보고됩니다.

/subsystem=web:migrate
{
    "outcome" => "success",
    "result" => {"migration-warnings" => [
        "WFLYWEB0002: Could not migrate resource {
    \"pattern\" => \"(.*)\",
    \"substitution\" => \"-\",
    \"flags\" => \"F\",
    \"operation\" => \"add\",
    \"address\" => [
        (\"subsystem\" => \"web\"),
        (\"virtual-server\" => \"default-host\"),
        (\"rewrite\" => \"test2\")
    ]
}",
        "WFLYWEB0002: Could not migrate resource {
    \"test\" => \"%{REQUEST_METHOD}\",
    \"pattern\" => \"GET\",
    \"flags\" => undefined,
    \"operation\" => \"add\",
    \"address\" => [
        (\"subsystem\" => \"web\"),
        (\"virtual-server\" => \"default-host\"),
        (\"rewrite\" => \"test2\"),
        (\"condition\" => \"get\")
    ]
}",
        "WFLYWEB0002: Could not migrate resource {
    \"test\" => \"%{REQUEST_URI}\",
    \"pattern\" => \".*index.html\",
    \"flags\" => \"NC\",
    \"operation\" => \"add\",
    \"address\" => [
        (\"subsystem\" => \"web\"),
        (\"virtual-server\" => \"default-host\"),
        (\"rewrite\" => \"test2\"),
        (\"condition\" => \"andCond\")
    ]
}"
    ]}
}

서버 구성 파일을 검토하고 undertow 하위 시스템에 대한 다음 구성이 표시됩니다.

<subsystem xmlns="urn:jboss:domain:undertow:10.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
     <buffer-cache name="default"/>
     <server name="default-server">
         <http-listener name="http" socket-binding="http"/>
         <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
         <host name="default-host" alias="localhost, example.com">
             <location name="/" handler="welcome-content"/>
         </host>
     </server>
     <servlet-container name="default">
         <jsp-config/>
     </servlet-container>
     <handlers>
         <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
     </handlers>
 </subsystem>

관리 CLI를 사용하여 필터를 생성하여 undertow 하위 시스템에서 재작성 구성을 대체합니다. 각 명령에 "{"outcome" ✓ "success"}"가 표시되어야 합니다.

# Create the filters
/subsystem=undertow/configuration=filter/expression-filter="test1":add(expression="path('(.*)/toberewritten/(.*)') -> rewrite('$1/rewritten/$2')")
/subsystem=undertow/configuration=filter/expression-filter="test2":add(expression="method('GET') and path('.*index.html') -> response-code(403)")

# Add the filters to the default server
/subsystem=undertow/server=default-server/host=default-host/filter-ref="test1":add
/subsystem=undertow/server=default-server/host=default-host/filter-ref="test2":add

업데이트된 서버 구성 파일을 검토합니다. 이제 JBoss Web 하위 시스템이 undertow 하위 시스템에서 완전히 마이그레이션되고 구성됩니다.

<subsystem xmlns="urn:jboss:domain:undertow:10.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="http" socket-binding="http"/>
        <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
        <host name="default-host" alias="localhost, example.com">
            <location name="/" handler="welcome-content"/>
            <filter-ref name="test1"/>
            <filter-ref name="test2"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
    <filters>
        <expression-filter name="test1" expression="path('(.*)/toberewritten/(.*)') -> rewrite('$1/rewritten/$2')"/>
        <expression-filter name="test2" expression="method('GET') and path('.*index.html') -> response-code(403)"/>
    </filters>
</subsystem>

관리 CLI를 사용하여 필터 및 핸들러를 구성하는 방법에 대한 자세한 내용은 JBoss EAP 7 구성 가이드에서 웹 서버 구성을 참조하십시오.

이전 JBoss EAP 릴리스에서는 시스템 속성을 사용하여 기본 JBoss Web 동작을 수정할 수 있습니다. Undertow에서 동일한 동작을 구성하는 방법에 대한 자세한 내용은 JBoss Web System Properties Migration Reference를 참조하십시오.

JBoss EAP 6.4에서 JBoss EAP 7로 마이그레이션하는 경우 액세스 로그에서 더 이상 예상 "참조자" 및 "사용자 에이전트" 값을 작성하지 않는 것을 알 수 있습니다. 이는 JBoss EAP 6.4에 포함된 JBoss Web에서 access-log 에서 %{headername}i 패턴을 사용하여 들어오는 헤더를 기록했기 때문입니다.

<access-log pattern="%h %l %u %t &quot;%T sec&quot; &quot;%r&quot; %s %b &quot;%{Referer}i&quot; &quot;%{User-agent}i&quot;"/>

JBoss EAP 7에서 Undertow를 사용하도록 변경하면 수신 헤더의 패턴이 %{i,headername} 으로 변경되었습니다.

<access-log pattern="%h %l %u %t &quot;%T sec&quot; &quot;%r&quot; %s %b &quot;%{i,Referer}&quot; &quot;%{i,User-Agent}&quot;"/>

JBoss EAP의 이전 릴리스에서는 센서가 지원되었습니다. 센서는 요청을 변경하거나 추가 처리를 수행하기 위해 서블릿 필터 전에 애플리케이션의 요청 처리 파이프라인에 삽입된 사용자 지정 클래스입니다.

이 섹션에서는 글로벌 센서를 마이그레이션하는 방법에 대해 설명합니다. 사용자 지정 및 인증 센서의 마이그레이션에 대해서는 본 가이드의 Migrate Custom Application(사용자 정의 애플리케이션 마이그레이션) 섹션에서 설명합니다.

JBoss EAP 7의 JBoss Web을 대체하는 Undertow는 전역 센서를 지원하지 않지만 Undertow 핸들러를 사용하여 유사한 기능을 수행할 수 있어야 합니다. Undertow에는 공통 기능을 제공하는 여러 기본 제공 핸들러가 포함되어 있습니다. 또한 사용자 지정 게이지 기능을 교체하는 데 사용할 수 있는 사용자 지정 핸들러를 생성하는 기능을 제공합니다.

애플리케이션에서 센서를 사용하는 경우 JBoss EAP 7로 마이그레이션할 때 동일한 기능을 수행하기 위해 적절한 Undertow 핸들러 코드로 교체해야 합니다.

핸들러 구성 방법에 대한 자세한 내용은 JBoss EAP 7 구성 가이드에서 핸들러 구성을 참조하십시오.

필터 구성 방법에 대한 자세한 내용은 JBoss EAP 7 구성 가이드에서 필터 구성을 참조하십시오.

JBoss 웹 사이트 마이그레이션

다음 표에는 JBoss Web에서 이전 릴리스의 JBoss EAP 릴리스와 해당 Undertow 기본 제공 핸들러가 나열되어 있습니다. JBoss 웹 센서는 org.apache.catalina.valves 패키지에 있습니다.

관리 CLI 마이그레이션 작업을 사용하여 다음 기준을 충족하는 글로벌 센서를 자동으로 마이그레이션할 수 있습니다.

관리 CLI 마이그레이션 작업에 대한 자세한 내용은 Management CLI Migration Operation 을 참조하십시오.

JDBCAccessLogValve 수동 마이그레이션 절차

org.apache.catalina.valve.JDBCAccessLogValve 브릿지는 규칙에 대한 예외이며 자동으로 마이그레이션할 수 없습니다. Undertow .server.handlers.JDBCLogHandler. 다음 예제를 마이그레이션하려면 아래 단계를 수행하십시오.

<valve name="jdbc" module="org.jboss.as.web" class-name="org.apache.catalina.valves.JDBCAccessLogValve">
    <param param-name="driverName" param-value="com.mysql.jdbc.Driver" />
    <param param-name="connectionName" param-value="root" />
    <param param-name="connectionPassword" param-value="password" />
    <param param-name="connectionURL" param-value="jdbc:mysql://localhost:3306/wildfly?zeroDateTimeBehavior=convertToNull" />
    <param param-name="format" param-value="combined" />
</valve>

Set-Cookie HTTP 응답 헤더 구문(예: RFC2109 및 RFC2965)에 대한 이전 사양은 쿠키 값을 인용할 때 쿠키 값에 공백 및 기타 구분 기호 문자를 허용합니다. JBoss EAP 6.4의 JBoss Web은 이전 사양을 준수하고 구분 기호 문자가 포함된 경우 쿠키 값을 자동으로 인용했습니다.

Set-Cookie HTTP 응답 헤더 구문에 대한 RFC6265 사양은 Set-Cookie 응답 헤더의 쿠키 값이 특정 제약 조건을 준수해야 한다고 명시합니다. 예를 들어 US-ASCII 문자여야 하지만 CTRL(controls), 공백, 큰따옴표, 쉼표, 세미콜론 또는 백슬래시 문자를 포함할 수 없습니다.

JBoss EAP 7.0에서 누적 패치 Red Hat JBoss Enterprise Application Platform 7.0 업데이트 08 이전에 Undertow는 이러한 잘못된 문자를 제한하지 않으며 제외된 문자가 포함된 쿠키를 따옴표로 묶지 않습니다. 이 누적 패치 또는 최신 누적 패치를 적용하면 the io.undertow.cookie.DEFAULT_ENABLE_RFC6265_COOKIE_VALIDATION 시스템 속성을 true 로 설정하여 RFC6265 규격 쿠키 검증을 활성화할 수 있습니다.

기본적으로 Undertow는 JBoss EAP 7.1부터 RFC6265 준수 쿠키 검증을 활성화하지 않습니다. 제외된 문자가 포함된 쿠키를 따옴표로 지정합니다. JBoss EAP 7.1부터는 io.undertow.cookie.DEFAULT_ENABLE_RFC6265_COOKIE_VALIDATION 시스템 속성을 사용하여 RFC6265 준수 쿠키 검증을 활성화할 수 없습니다. 대신 rfc6265-cookie-validation 리스너 특성을 true 로 설정하여 HTTP, HTTPS 또는 AJP 리스너에 대한 RFC6265 호환 쿠키 검증을 활성화합니다. 이 속성의 기본값은 false 입니다. 다음 예제에서는 HTTP 리스너에 대해 RFC6265 호환 쿠키 검증을 활성화합니다.

/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=rfc6265-cookie-validation,value=true)

JBoss Web을 웹 서버로 포함하는 JBoss EAP 6.4에서는 기본적으로 HTTP TRACE 메서드 호출이 허용되었습니다.

JBoss EAP 7에서 JBoss Web을 웹 서버로 대체하는 Undertow는 기본적으로 HTTP TRACE 메서드 호출을 허용하지 않습니다. 이 설정은 undertow 하위 시스템에서 http -listener 요소의 disallowed- methods 특성을 사용하여 구성됩니다. 다음 read-resource 명령의 출력을 검토하여 확인할 수 있습니다. disallowed-methods 속성의 값은 ["TRACE"] 입니다.

/subsystem=undertow/server=default-server/http-listener=default:read-resource
{
    "outcome" => "success",
    "result" => {
        "allow-encoded-slash" => false,
        "allow-equals-in-cookie-value" => false,
        "allow-unescaped-characters-in-url" => false,
        "always-set-keep-alive" => true,
        "buffer-pipelined-data" => false,
        "buffer-pool" => "default",
        "certificate-forwarding" => false,
        "decode-url" => true,
        "disallowed-methods" => ["TRACE"],
         ...
    }
}

JBoss EAP 7 이상에서 HTTP TRACE 메서드 호출을 활성화하려면 다음 명령을 실행하여 disallowed-methods 특성 목록에서 "TRACE" 항목을 제거해야 합니다.

/subsystem=undertow/server=default-server/http-listener=default:list-remove(name=disallowed-methods,value="TRACE")

read-resource 명령을 다시 실행하면 TRACE 메서드 호출이 더 이상 허용되지 않는 메서드 목록에 표시되지 않습니다.

/subsystem=undertow/server=default-server/http-listener=default:read-resource
{
    "outcome" => "success",
    "result" => {
        "allow-encoded-slash" => false,
        "allow-equals-in-cookie-value" => false,
        "allow-unescaped-characters-in-url" => false,
        "always-set-keep-alive" => true,
        "buffer-pipelined-data" => false,
        "buffer-pool" => "default",
        "certificate-forwarding" => false,
        "decode-url" => true,
        "disallowed-methods" => [],
         ...
    }
}

HTTP 메서드의 기본 동작에 대한 자세한 내용은 JBoss EAP 구성 가이드의 Default Behavior of HTTP Methods 를 참조하십시오.

JBoss EAP 7.0에서는 웹 애플리케이션의 루트 컨텍스트가 mod_cluster에서 기본적으로 비활성화되었습니다.

JBoss EAP 7.1부터는 더 이상 그렇지 않습니다. 루트 컨텍스트가 비활성화될 것으로 예상되는 경우 예기치 않은 결과가 발생할 수 있습니다. 예를 들어 요청이 바람직하지 않은 노드로 잘못 라우팅되거나 노출되지 않아야 하는 프라이빗 애플리케이션에 공용 프록시를 통해 실수로 액세스할 수 있습니다. 이제 명시적으로 제외되지 않는 한 Undertow 위치도 mod_cluster 로드 밸런서에 자동으로 등록됩니다.

다음 관리 CLI 명령을 사용하여 modcluster 하위 시스템 구성에서 ROOT를 제외합니다.

/subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=excluded-contexts,value=ROOT)

다음 관리 CLI 명령을 사용하여 기본 시작 웹 애플리케이션을 비활성화합니다.

/subsystem=undertow/server=default-server/host=default-host/location=\/:remove
/subsystem=undertow/configuration=handler/file=welcome-content:remove
reload

기본 시작 웹 애플리케이션을 구성하는 방법에 대한 자세한 내용은 JBoss EAP 의 개발 가이드에서 기본 시작 웹 애플리케이션 구성을 참조하십시오.

JBoss EAP 7.2 이전에는 default undertow 하위 시스템 구성에 default-host 에 의해 각 HTTP 응답에 추가된 두 개의 응답 헤더 필터가 포함되었습니다.

이러한 응답 헤더 필터는 사용 중인 서버에 대한 정보가 의도치 않게 공개되지 않도록 기본 JBoss EAP 7.2 구성에서 제거되었습니다.

다음은 JBoss EAP 7.1의 default undertow 하위 시스템 구성의 예입니다.

<subsystem xmlns="urn:jboss:domain:undertow:4.0">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https"/>
        <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <filter-ref name="server-header"/>
            <filter-ref name="x-powered-by-header"/>
            <http-invoker security-realm="ApplicationRealm"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
        <websockets/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
    <filters>
        <response-header name="server-header" header-name="Server" header-value="JBoss-EAP/7"/>
        <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
    </filters>
</subsystem>

다음은 JBoss EAP 7.4의 새 default undertow 하위 시스템 구성의 예입니다.

<subsystem xmlns="urn:jboss:domain:undertow:10.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
        <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <http-invoker security-realm="ApplicationRealm"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
        <websockets/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
</subsystem>

JBoss EAP 6 기본 구성에서 JGroups는 서버 구성 파일의 <interfaces> 섹션에 정의된 공용 인터페이스를 사용했습니다.

전용 네트워크 인터페이스를 사용하는 것이 좋습니다. JGroups는 이제 JBoss EAP 7에서 서버 구성 파일의 <interfaces> 섹션에 정의된 새 개인 인터페이스를 사용하도록 기본 설정되어 있습니다.

JGroups는 JGroups 채널 형식으로 HA 서비스에 대한 그룹 통신 지원을 제공합니다. JBoss EAP 7은 서버 구성 파일의 jgroups 하위 시스템에 <channel> 요소를 도입합니다. 관리 CLI를 사용하여 JGroups 채널 구성을 추가, 제거 또는 변경할 수 있습니다.

JGroups 구성 방법에 대한 자세한 내용은 JBoss EAP 구성 가이드에서 JGroups 클러스터 통신을 참조하십시오.

JBoss EAP 6에서는 웹 세션 복제 및 EJB 복제를 위한 기본 클러스터된 캐시가 ASYNC 캐시를 복제했습니다. 이는 JBoss EAP 7에서 변경되었습니다. 기본 클러스터된 캐시가 이제 ASYNC 캐시를 분산합니다. 복제된 캐시는 더 이상 기본적으로 구성되지 않습니다. 복제된 캐시를 추가하고 기본값으로 설정하는 방법에 대한 정보는 JBoss EAP 구성 가이드 의 캐시 모드 구성을 참조하십시오.

이는 새 JBoss EAP 7 기본 구성을 사용하는 경우에만 영향을 미칩니다. JBoss EAP 6에서 구성을 마이그레이션하는 경우 infinispan 하위 시스템의 구성이 유지됩니다.

JBoss EAP 7에서는 ASYNC 캐시 전략의 동작이 변경되었습니다.

JBoss EAP 6에서는 ASYNC 캐시 읽기가 가용되었습니다. 차단되지는 않지만, (예: 페일오버 시) 오래된 데이터를 더티 읽기가 쉽습니다. 이는 이전 요청이 완료되기 전에 동일한 사용자에 대한 후속 요청을 시작할 수 있기 때문입니다. 클러스터 토폴로지 변경이 세션 선호도에 영향을 미칠 수 있으므로 분산 모드를 사용할 때 이 허용은 허용되지 않습니다.

JBoss EAP 7에서 ASYNC 캐시 읽기에는 잠금이 필요합니다. 이전 복제가 완료될 때까지 동일한 사용자의 새 요청을 차단하므로 더티 읽기가 방지됩니다.

JBoss EAP 7.1 이상에서 비활성화를 위해 사용자 정의 SFSB(상태 저장 세션 빈) 캐시를 구성할 때 다음과 같은 제한 사항에 유의하십시오.

JBoss EAP 7.0과 이후 버전 간의 동작을 변경하려면 배치 모드에서 또는 특수 헤더를 사용하여 캐시 컨테이너 전송 프로토콜에 대한 업데이트를 수행해야 합니다. 이러한 동작 변경은 JBoss EAP 서버 관리에 사용되는 도구에도 영향을 미칩니다.

다음은 JBoss EAP 7.0에서 캐시 컨테이너 전송 프로토콜을 구성하는 데 사용되는 관리 CLI 명령의 예입니다.

/subsystem=infinispan/cache-container=my:add()
/subsystem=infinispan/cache-container=my/transport=jgroups:add()
/subsystem=infinispan/cache-container=my/invalidation-cache=mycache:add(mode=SYNC)

다음은 JBoss EAP 7.1에서 동일한 구성을 수행하는 데 필요한 관리 CLI 명령의 예입니다. 명령은 배치 모드에서 실행됩니다.

batch
/subsystem=infinispan/cache-container=my:add()
/subsystem=infinispan/cache-container=my/transport=jgroups:add()
/subsystem=infinispan/cache-container=my/invalidation-cache=mycache:add(mode=SYNC)
run-batch

배치 모드를 사용하지 않으려면 전송을 정의할 때 작업 헤더 allow-resource-service-restart=true 를 대신 지정할 수 있습니다. 이 경우 작업을 적용할 수 있도록 서비스를 다시 시작하고 일부 서비스는 서비스를 다시 시작할 때까지 작동을 중지할 수 있습니다.

스크립트를 사용하여 캐시 컨테이너 전송 프로토콜을 업데이트하는 경우 이를 검토하고 배치 모드를 추가합니다.

EAP_HOME/modules/system/layers/base/ 에 있는 org.jboss.as.messaging 모듈 확장 기능은 org.wildfly.extension.messaging-activemq 확장 모듈로 교체되었습니다.

urn:jboss:domain:messaging:3.0 하위 시스템 구성 네임스페이스가 urn:jboss:domain:messaging-activemq:4.0 네임스페이스로 교체되었습니다.

관리 모델

대부분의 경우 요소 및 특성 이름을 이전 릴리스에서 사용된 항목과 유사하게 유지하기 위해 노력했습니다. 다음 테이블에는 몇 가지 변경 사항이 나열되어 있습니다.

새 messaging-activemq 하위 시스템에서 호출된 관리 작업이 /subsystem=messaging/wonetq-server=에서 /subsystem= messaging-activemq/server= 로 변경되었습니다.

마이그레이션 작업을 호출하여 기존 JBoss EAP 6 메시징 하위 시스템 구성을 JBoss EAP 7 서버의 messaging-activemq 하위 시스템으로 마이그레이션할 수 있습니다.

/subsystem=messaging:migrate

마이그레이션 작업을 실행하기 전에 describe-migration 작업을 호출하여 기존 JBoss EAP 6 메시징 하위 시스템 구성에서 JBoss EAP 7 서버의 messaging-activemq 하위 시스템으로 마이그레이션하는 데 수행할 관리 작업 목록을 검토할 수 있습니다.

/subsystem=messaging:describe-migration

마이그레이션 및 describe-migration 작업에서는 자동으로 마이그레이션할 수 없는 리소스 또는 속성에 대한 마이그레이션 경고 목록도 표시합니다.

메시징 하위 시스템 마이그레이션 및 전달 호환성

메시징 하위 시스템에 대한 describe-migration 및 마이그레이션 작업은 추가 구성 인수를 제공합니다. 레거시 JBoss EAP 6 클라이언트가 JBoss EAP 7 서버에 연결할 수 있도록 메시징을 구성하려면 다음과 같이 부울 add-legacy-entries 인수를 describe- migration 또는 마이그레이션 작업에 추가할 수 있습니다.

/subsystem=messaging:describe-migration(add-legacy-entries=true)
/subsystem=messaging:migrate(add-legacy-entries=true)

부울 인수 add-legacy-entries 가 true 로 설정된 경우 messaging-activemq 하위 시스템은 legacy-connection-factory 리소스를 생성하고 legacy-entries 를 jms-queue 및 jms-topic 리소스에 추가합니다.

부울 인수 add-legacy-entries 가 false 로 설정된 경우 messaging-activemq 하위 시스템에서 레거시 리소스가 생성되지 않으며 레거시 메시징 클라이언트는 JBoss EAP 7 서버와 통신할 수 없습니다. 이는 기본값입니다.

앞뒤의 호환성 및 이전 버전과의 호환성에 대한 자세한 내용은 JBoss EAP에 대한 메시징 구성의 Backward 및 Forward Compatibility 를 참조하십시오.

관리 CLI 마이그레이션 및 마이그레이션 작업에 대한 자세한 내용은 Management CLI Migration Operation 을 참조하십시오.

forward-when-no-consumers 속성 동작에서 변경

forward-when-no-consumers 속성의 동작은 JBoss EAP 7에서 변경되었습니다.

JBoss EAP 6에서는 forward-when-no-consumers 가 false 로 설정되어 클러스터에 소비자가 없는 경우 메시지가 클러스터의 모든 노드에 재배포되었습니다.

이 동작은 JBoss EAP 7에서 변경되었습니다. forward-when-no-consumers 가 false 로 설정되어 있고 클러스터에 소비자가 없는 경우 메시지가 재배포되지 않습니다. 대신 해당 노드는 전송된 원래 노드에 보관됩니다.

기본 클러스터 로드 밸런싱 정책 변경

JBoss EAP 7에서는 기본 클러스터 로드 밸런싱 정책이 변경되었습니다.

JBoss EAP 6에서는 기본 클러스터 로드 밸런싱 정책이 STRICT 과 유사했습니다. 이 정책은 레거시 forward-when-no-consumers 매개 변수를 true 로 설정하는 것과 같습니다. JBoss EAP 7에서 기본값은 이제 ON_DEMAND 로, 레거시 forward-when-no-consumers 매개 변수를 false로 설정하는 것과 같습니다. 이러한 설정에 대한 자세한 내용은 Configuring Messaging for JBoss EAP에서 Cluster Connection Attributes 를 참조하십시오.

메시징 하위 시스템 XML 구성

새로운 messaging-activemq 하위 시스템에서 XML 구성은 크게 변경되었으며 이제 다른 JBoss EAP 하위 시스템과 더 일관된 XML 체계를 제공합니다.

새 messaging-activemq 하위 시스템을 준수하도록 JBoss EAP 메시징 하위 시스템 XML 구성을 수정하지 않는 것이 좋습니다. 대신 레거시 하위 시스템 마이그레이션 작업을 호출합니다. 이 작업은 새 messaging-activemq 하위 시스템의 XML 구성을 실행의 일부로 작성합니다.

다음 접근 방식 중 하나를 사용하여 이전 릴리스에서 JBoss EAP의 현재 릴리스로 메시징 데이터를 마이그레이션할 수 있습니다.

Jakarta Messaging 지원 공급자로서 HornetQ에서 ActiveMQ Artemis로의 변경으로 인해 메시징 데이터의 형식과 위치가 JBoss EAP 7.0 이상에서 변경되었습니다. 6.4 에서 7.x 릴리스 사이의 메시징 데이터 폴더 이름과 위치에 대한 변경 내용은 메시징 폴더 이름 매핑 을 참조하십시오.

$ java -jar -mp MODULE_PATH org.hornetq.exporter MESSAGING_BINDINGS_DIRECTORY MESSAGING_JOURNAL_DIRECTORY MESSAGING_PAGING_DIRECTORY MESSAGING_LARGE_MESSAGES_DIRECTORY > OUTPUT_DATA.xml

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="org.hornetq.exporter">
    <main-class name="org.hornetq.jms.persistence.impl.journal.XmlDataExporter"/>
    <properties>
        <property name="jboss.api" value="deprecated"/>
    </properties>
    <dependencies>
        <module name="org.hornetq"/>
    </dependencies>
</module>

/subsystem=messaging-activemq/server=default/path=journal-directory:resolve-path
/subsystem=messaging-activemq/server=default/path=paging-directory:resolve-path
/subsystem=messaging-activemq/server=default/path=bindings-directory:resolve-path
/subsystem=messaging-activemq/server=default/path=large-messages-directory:resolve-path

JBoss EAP 6에서는 메시징 대상 대기열이 메시징 하위 시스템의 <copet q-server> 요소 아래 <jms-destinations > 요소에서 구성되었습니다.

<hornetq-server>
  ...
  <jms-destinations>
     <jms-queue name="testQueue">
        <entry name="queue/test"/>
         <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
  </jms-destinations>
  ...
</hornetq-server>

JBoss EAP 7에서 Jakarta Messaging 대상 대기열은 messaging-activemq 하위 시스템의 기본 <server> 요소에 구성됩니다.

<server name="default">
  ...
  <jms-queue name="testQueue" entries="queue/test java:jboss/exported/jms/queue/test"/>
  ...
</server>

메시징 인터셉터는 JBoss EAP 7에서 Jakarta Messaging 공급업체인 ActiveMQ Artemis와 HornetQ를 대체하여 크게 변경되었습니다.

이전 릴리스의 JBoss EAP에 포함된 HornetQ 메시징 하위 시스템에는 JAR에 추가한 다음 HornetQ module.xml 파일을 수정하여 HornetQ 인터셉터를 설치해야 했습니다.

JBoss EAP 7에 포함된 messaging-activemq 하위 시스템은 module.xml 파일을 수정할 필요가 없습니다. 이제 Apache ActiveMQ Artemis Interceptor 인터페이스를 구현하는 사용자 인터셉터 클래스는 이제 모든 서버 모듈에서 로드할 수 있습니다. 서버 구성 파일의 messaging-activemq 하위 시스템에서 인터셉터를 로드해야 하는 모듈을 지정합니다.

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <incoming-interceptors>
      <class name="com.mycompany.incoming.myInterceptor" module="com.mycompany" />
      <class name="com.othercompany.incoming.myOtherInterceptor" module="com.othercompany" />
    </incoming-interceptors>
    <outgoing-interceptors>
      <class name="com.mycompany.outgoing.myInterceptor" module="com.mycompany" />
      <class name="com.othercompany.outgoing.myOtherInterceptor" module="com.othercompany" />
    </outgoing-interceptors>
  </server>
</subsystem>

JBoss EAP 6에서는 Netty Servlet 전송을 사용하도록 서블릿 엔진을 구성할 수 있습니다. ActiveMQ Artemis는 JBoss EAP 7에서 HornetQ를 기본 제공 메시징 프로바이더로 교체하므로 이 구성을 더 이상 사용할 수 없습니다. 대신 새로운 기본 제공 메시징 HTTP 커넥터 및 HTTP 어셉터를 사용하려면 서블릿 구성을 교체해야 합니다.

타사 Jakarta Messaging 공급자와 함께 사용할 일반 Jakarta Messaging 리소스 어댑터를 구성하는 방법은 JBoss EAP 7에서 변경되었습니다. 자세한 내용은 JBoss EAP 에 대한 메시징에서 일반 자카르타 메시징 리소스 어댑터 배포를 참조하십시오.

JBoss EAP 7.0에서 check-for -live-server 특성을 지정하지 않고 replication- master 정책을 구성한 경우 기본값은 false입니다. 이는 JBoss EAP 7.1 이상에서 변경되었습니다. check-for-live-server 특성의 기본값은 이제 true 입니다.

다음은 check-for-live-server 특성을 지정하지 않고 replication-master 정책을 구성하는 관리 CLI 명령의 예입니다.

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:add(cluster-name=my-cluster,group-name=group1)

관리 CLI를 사용하여 리소스를 읽는 경우 check-for-live-server 특성 값이 true 로 설정되어 있는지 확인합니다.

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        "check-for-live-server" => true,
        "cluster-name" => "my-cluster",
        "group-name" => "group1",
        "initial-replication-sync-timeout" => 30000L
    },
    "response-headers" => {"process-state" => "reload-required"}
}

javax.jms.JMSException 의 serialVersionUID 가 JMS 1.1과 JMS 2.0.0 간에 변경되었습니다. 즉, JMSException 의 인스턴스 또는 하위 클래스 중 일부가 JMS 1.1을 사용하여 직렬화되면 JMS 2.0.0을 사용하여 역직렬화할 수 없습니다. 그 반대도 마찬가지입니다. JMS 2.0.0을 사용하여 JMSException 의 인스턴스를 직렬화하면 JMS 1.1을 사용하여 역직렬화할 수 없습니다. 이 두 경우 모두 다음과 유사한 예외가 발생합니다.

javax.jms.JMSException: javax.jms.JMSException; local class incompatible: stream classdesc serialVersionUID = 8951994251593378324, local class serialVersionUID = 2368476267211489441

이 문제는 Jakarta Messaging 2.0.1 유지 관리 릴리스에서 해결되었습니다.

다음 표는 각 JBoss EAP 릴리스에 대한 세부적인 구현입니다.

serialVersionUID 비호환성으로 인해 마이그레이션 문제가 발생할 수 있습니다.

JBoss EAP 6.4 클라이언트를 사용하여 JMSException 이 포함된 메시지를 보내는 경우 메시징 데이터를 JBoss EAP 7.1 이상으로 마이그레이션한 다음 JBoss EAP 7.1 이상 클라이언트를 사용하여 해당 메시지를 역직렬화하려고 하면 JMS 1.1의 serialVersionUID 가 자카르타 메시징 2.0.3 이상에서와 호환되므로 직렬화가 성공합니다.

JBoss EAP의 이전 릴리스에서 데이터 소스를 구성하면 드라이버 이름에 지정된 값이 JDBC 드라이버 JAR에 포함된 META-INF/services/java.sql.Driver 파일에 나열된 클래스 수에 따라 달라집니다.

단일 클래스를 포함하는 드라이버

META-INF/services/java.sql.Driver 파일이 하나의 클래스만 지정한 경우 드라이버 이름 값은 단순히 JDBC 드라이버 JAR의 이름이었습니다. 이는 JBoss EAP 7에서 변경되지 않았습니다.

여러 클래스를 포함하는 드라이버

JBoss EAP 6에서 META-INF/services/java.sql.Driver 파일에 두 개 이상의 클래스가 나열된 경우 다음 형식으로 주 버전 및 부 버전과 함께 JAR 이름에 해당 이름을 추가하여 드라이버 클래스가 어떤 클래스를 지정했는지 지정합니다.

JAR_NAME + DRIVER_CLASS_NAME + "_" + MAJOR_VERSION + "_" + MINOR_VERSION

JBoss EAP 7에서는 다음과 같이 변경되었습니다. 이제 다음 형식을 사용하여 드라이버 이름을 지정합니다.

JAR_NAME + "_" + DRIVER_CLASS_NAME + "_" + MAJOR_VERSION + "_" + MINOR_VERSION

MySQL 5.1.31 JDBC 드라이버는 두 개의 클래스가 포함된 드라이버의 예입니다. 드라이버 클래스 이름은 com.mysql.jdbc.Driver 입니다. 다음 예제에서는 이전 릴리스에서 드라이버 이름을 지정하는 방법과 JBoss EAP의 현재 릴리스 간의 차이점을 보여줍니다.

mysql-connector-java-5.1.31-bin.jarcom.mysql.jdbc.Driver_5_1

mysql-connector-java-5.1.31-bin.jar_com.mysql.jdbc.Driver_5_1

FIPS 모드에서 실행 중인 경우 기본 동작이 JBoss EAP 7.0과 JBoss EAP 7.1 간에 변경되었습니다.

레거시 보안 영역을 사용하는 경우 JBoss EAP 7.1 이상에서는 개발을 위해 자체 서명된 인증서의 자동 생성을 제공합니다. JBoss EAP 7.0에서 사용할 수 없는 이 기능은 기본적으로 활성화되어 있습니다. 즉, FIPS 모드에서 실행 중인 경우 자동 자체 서명 인증서 생성을 비활성화하도록 서버를 구성해야 합니다. 그렇지 않으면 서버를 시작할 때 다음과 같은 오류가 표시될 수 있습니다.

ERROR [org.xnio.listener] (default I/O-6) XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException: WFLYDM0114: Failed to lazily initialize SSL context
...
Caused by: java.lang.RuntimeException: WFLYDM0112: Failed to generate self signed certificate
...
Caused by: java.security.KeyStoreException: Cannot get key bytes, not PKCS#8 encoded

자체 서명된 자동 인증서 생성에 대한 자세한 내용은 JBoss EAP 용 서버 보안 구성 방법의 애플리케이션 자동 자체 서명 인증서 생성을 참조하십시오.

JAX-RPC(Java API for XML-based RPC)는 Java EE 6에서 더 이상 사용되지 않으며 Java EE 7에서는 선택 사항이었습니다. JBoss EAP 7에서 더 이상 사용 가능하거나 지원되지 않습니다. JAX-RPC를 사용하는 애플리케이션은 현재 Jakarta EE 표준 웹 서비스 프레임워크인 Jakarta XML Web Services 를 사용하도록 마이그레이션해야 합니다.

JAX-RPC 웹 서비스는 다음 방법 중 하나로 식별할 수 있습니다.

JBoss EAP의 이전 릴리스에서는 엔드포인트 배포 아카이브에 jbossws-cxf.xml 구성 파일을 포함하여 JBossWS 및 Apache CXF 통합을 사용자 지정할 수 있습니다. 이에 대한 한 가지 사용 사례는 Apache CXF 버스에서 웹 서비스 클라이언트 및 서버 엔드포인트에 대한 인터셉터 체인을 구성하는 것이었습니다. 이러한 통합에는 Spring을 JBoss EAP 서버에 배포해야 했습니다.

Spring 통합은 JBoss EAP 7에서 더 이상 지원되지 않습니다. jbossws-cxf.xml 설명자 구성 파일이 포함된 애플리케이션을 수정하여 해당 파일에 정의된 사용자 지정 구성을 교체해야 합니다. Apache CXF API에 직접 액세스할 수는 있지만 애플리케이션은 이식할 수 없습니다.

권장되는 접근 방식은 Spring 사용자 지정 구성을 가능한 새로운 JBossWS 설명자 구성 옵션으로 교체하는 것입니다. JBossWS 설명자 기반 접근 방식은 클라이언트 엔드포인트 코드를 수정할 필요 없이 유사한 기능을 제공합니다. 경우에 따라 Spring을 CDI(Context Dependency Injection)로 바꿀 수 있습니다.

Apache CXF 인터셉터

JBossWS 설명자는 클라이언트 엔드포인트 코드를 수정하지 않고 인터셉터를 선언할 수 있는 새로운 구성 옵션을 제공합니다. 대신 cxf.interceptors. in 및 cxf.interceptors. out 속성에 대해 인터셉터 클래스 이름 목록을 지정하여 사전 정의된 클라이언트 및 끝점 구성 내에서 인터셉터를 선언합니다.

다음은 이러한 속성을 사용하여 인터셉터를 선언하는 jaxws-endpoint-config.xml 파일의 예입니다.

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
  <endpoint-config>
    <config-name>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointImpl</config-name>
    <property>
      <property-name>cxf.interceptors.in</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointInterceptor,org.jboss.test.ws.jaxws.cxf.interceptors.FooInterceptor</property-value>
    </property>
    <property>
      <property-name>cxf.interceptors.out</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointCounterInterceptor</property-value>
    </property>
  </endpoint-config>
</jaxws-config>

Apache CXF 기능

JBossWS 설명자를 사용하면 cxf.features 속성에 대한 기능 클래스 이름 목록을 지정하여 사전 정의된 클라이언트 및 엔드포인트 구성 내에서 기능을 선언할 수 있습니다.

다음은 이 속성을 사용하여 기능을 선언하는 jaxws-endpoint-config.xml 파일의 예입니다.

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
  <endpoint-config>
    <config-name>Custom FI Config</config-name>
    <property>
      <property-name>cxf.features</property-name>
      <property-value>org.apache.cxf.feature.FastInfosetFeature</property-value>
    </property>
  </endpoint-config>
</jaxws-config>

Apache CXF HTTP 전송

Apache CXF에서 HTTP 전송 구성은 org.apache.cxf.transport.http.HTTPConduit 옵션을 지정하여 수행합니다. JBossWS 통합을 통해 다음과 같이 Apache CXF API를 프로그래밍 방식으로 수정할 수 있습니다.

import org.apache.cxf.frontend.ClientProxy;
import org.apache.cxf.transport.http.HTTPConduit;
import org.apache.cxf.transports.http.configuration.HTTPClientPolicy;

// Set chunking threshold before using a JAX-WS port client
...
HTTPConduit conduit = (HTTPConduit)ClientProxy.getClient(port).getConduit();
HTTPClientPolicy client = conduit.getClient();

client.setChunkingThreshold(8192);
...

시스템 속성을 설정하여 Apache CXF HTTPConduit 기본값을 제어하고 재정의할 수도 있습니다.

cxf-api 및 cxf-rt-core JAR이 하나의 cxf-core JAR로 병합되었습니다. 그 결과 JBoss EAP의 org.apache.cxf 모듈에 이제 cxf-core JAR이 포함되어 이전 릴리스보다 더 많은 클래스를 노출합니다.

XML/WS-Security에서 대칭 암호화에 GCM(Galulators/Counter Mode)을 사용하여 AES 암호화를 사용하려면 Bouncy-le Security Provider가 필요합니다.

JBoss EAP 7은 org.bouncycastle 모듈과 함께 제공되고 JBossWS는 이제 클래스 로더를 활용하여 Bouncy-le Security Provider를 가져오고 사용할 수 있게 되었습니다. 따라서 현재 JVM에서 더 이상 Bouncy를 정적으로 설치할 필요가 없습니다. 컨테이너 외부에서 실행되는 애플리케이션의 경우 클래스 경로에 Bouncy-le 라이브러리를 추가하여 보안 공급자를 JBossWS에서 사용할 수 있습니다.

서버의 jaxws -endpoint-config .xml 배포 설명자 파일 또는 클라이언트의 jaxws-client-config.xml 설명자 파일에서 org.jboss.ws.cxf.noLocalBC 속성 값을 true 로 설정하여 이 동작을 비활성화할 수 있습니다.

JBoss EAP와 함께 제공되는 버전과 다른 버전을 사용하려는 경우 여전히 JVM에 Bouenciesle을 정적으로 설치할 수 있습니다. 이 경우 정적으로 설치된 Bouncy-le Security Provider가 클래스 경로에 있는 공급자를 통해 선택됩니다. 문제를 방지하려면 Bouncyle 1.49, 1.51 이상을 사용해야 합니다.

컨테이너에서 실행되는 클라이언트에 대한 기본 버스 선택 전략이 THREAD_BUS에서 TCCL_BUS 로 변경되었습니다. 컨테이너 외부를 실행하는 클라이언트의 경우 기본 전략은 여전히 THREAD_BUS 입니다. 다음 방법 중 하나를 사용하여 이전 릴리스의 동작을 복원할 수 있습니다.

컨테이너는 웹 서비스 참조에 삽입되는 클라이언트를 구축자에서 WebServiceFeature 클래스를 인수로 포함하는 Jakarta XML Web Services 2.2 스타일 생성자를 사용해야 합니다. JBossWS 4와 함께 제공되는 JBoss EAP 6.4는 해당 요구 사항을 숨깁니다. JBoss EAP 7에는 이 요구 사항을 더 이상 숨기지 않는 JBossWS 5가 포함되어 있습니다. 즉, 컨테이너에서 주입한 사용자 제공 서비스 클래스는 하나 이상의 WebService Feature 인수를 포함하는 javax.xml.ws.Service 생성자를 사용하도록 기존 코드를 업데이트하여 Jakarta XML Web Services 2.2 이상을 구현해야 합니다.

protected Service(URL wsdlDocumentLocation,
       QName serviceName,
       WebServiceFeature... features)

이전 릴리스에서는 시스템 속성 org.jboss.security.ignoreHttpsHost 를 true 로 설정하여 인증서에 제공된 서비스의 CN(Common Name)에 대해 HTTPS URL 호스트 이름 확인을 비활성화할 수 있습니다. 이 시스템 속성 이름은 cxf.tls-client.disableCNCheck 로 교체되었습니다.

서비스 엔드포인트 및 서비스 클라이언트 핸들러에 주입을 활성화한 결과 더 이상 org.jboss.as.webservices.server.integration JBoss 모듈에서 핸들러 클래스를 자동으로 로드할 수 없습니다. 애플리케이션이 지정된 사전 정의된 구성에 의존하는 경우 배포에 대한 새 모듈 종속성을 명시적으로 정의해야 할 수 있습니다. 자세한 내용은 Migrate Explicit Module Dependencies에서 참조하십시오.

Java 지원 표준 재정의 메커니즘 은 JDK 1.8_40에서 더 이상 사용되지 않으며 JDK 9에서 이를 제거하지 않습니다. 이 메커니즘을 통해 개발자는 JAR을 JRE 내의 추천된 디렉토리에 배치하여 배포된 모든 애플리케이션에서 라이브러리를 사용할 수 있습니다.

애플리케이션이 Apache CXF의 JBossWS 구현을 사용하는 경우 JBoss EAP 7은 필요한 종속성을 올바른 순서로 추가하며 이러한 변경의 영향을 받지 않아야 합니다. 애플리케이션이 Apache CXF에 직접 액세스하는 경우 이제 애플리케이션 배포의 일부로 JBossWS 종속 항목 다음에 Apache CXF 종속성을 제공해야 합니다.

JBoss EAP의 이전 릴리스에서는 JAR 아카이브의 META -INF/ 디렉터리에 또는 POJO 웹 서비스 배포를 위한 WEB-INF/ 디렉터리에 대한 jboss- webservices.xml 배포 설명자 파일을 구성할 수 있습니다.

JBoss EAP 7에서는 EAR 아카이브의 META -INF/ 디렉터리에 jboss-webservices.xml 배포 설명자 파일을 구성할 수 있습니다. jboss-webservices.xml 파일이 EAR 아카이브와 JAR 또는 WAR 아카이브에 모두 있는 경우 JAR 또는 WAR에 대한 jboss-webservices.xml 파일의 구성 데이터가 EAR 설명자 파일의 해당 데이터를 재정의합니다.

명명 패턴 -jms.xml로 식별된 독점적인 HornetQ 메시징 리소스 배포 설명자 파일은 더 이상 JBoss EAP 7에서 작동하지 않습니다. 다음은 JBoss EAP 6의 Jakarta Messaging 리소스 배포 설명자 파일의 예입니다.

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-deployment:1.0">
  <hornetq-server>
    <jms-destinations>
      <jms-queue name="testQueue">
        <entry name="queue/test"/>
        <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
      <jms-topic name="testTopic">
        <entry name="topic/test"/>
        <entry name="java:jboss/exported/jms/topic/test"/>
      </jms-topic>
    </jms-destinations>
  </hornetq-server>
</messaging-deployment>

이전 릴리스에서 애플리케이션에 -jms.xml Jakarta Messaging 배포 설명자를 사용한 경우 애플리케이션을 변환하여 Jakarta EE 플랫폼의 EE.5.18 섹션에 지정된 표준 배포 설명자를 사용하거나 messaging-activemq-deployment 스키마를 사용하도록 배포 설명자를 업데이트할 수 있습니다. 설명자를 업데이트하도록 선택하는 경우 다음과 같이 수정해야 합니다.

수정된 파일은 다음 예와 같이 표시됩니다.

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-activemq-deployment:1.0">
  <server>
    <jms-destinations>
      <jms-queue name="testQueue">
        <entry name="queue/test"/>
        <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
      <jms-topic name="testTopic">
        <entry name="topic/test"/>
        <entry name="java:jboss/exported/jms/topic/test"/>
      </jms-topic>
    </jms-destinations>
  </server>
</messaging-deployment>

메시징과 관련된 서버 구성 변경에 대한 자세한 내용은 Messaging Server Configuration Changes 를 참조하십시오.

JBoss EAP 7은 자카르타 메시징 1.1 API를 계속 지원하므로 코드를 수정할 필요가 없습니다.

JBoss EAP 7에서는 기본 원격 커넥터와 포트가 변경되었습니다. 이 변경 사항에 대한 자세한 내용은 원격 URL 커넥터 및 포트 업데이트를 참조하십시오.

마이그레이션 작업을 사용하여 서버 구성을 마이그레이션하는 경우 이전 설정이 유지되며 PROVIDER_URL 을 업데이트할 필요가 없습니다. 그러나 새 JBoss EAP 7 기본 구성으로 실행하는 경우 새 http-remoting://localhost:8080 설정을 사용하도록 클라이언트 코드에서 PROVIDER_URL 을 변경해야 합니다. 자세한 내용은 Migrate Remote Naming Client Code 에서 참조하십시오.

Jakarta Messaging 2.0 API를 사용하도록 코드를 마이그레이션하려면 작동 예제는 helloworld-jms 빠른 시작을 참조하십시오.

JBoss EAP 6에는 org. ticketsetq 모듈이 포함되어 있어 애플리케이션 소스 코드에서 HornetQ API 를 사용할 수 있었습니다.

Apache ActiveMQ Artemis는 JBoss EAP 7에서 HornetQ를 교체하므로 Apache ActiveMQ Artemis API를 사용하기 위해 HornetQ API를 사용하는 모든 코드를 마이그레이션해야 합니다. 이 API의 라이브러리는 org.apache.activemq.artemis 모듈에 포함되어 있습니다.

ActiveMQ Artemis는 HornetQ의 진화이므로 많은 개념이 계속 적용됩니다.

auto-create-jms-queues, auto-delete-jms- queues, auto-create-jms-topics,auto-delete-jms-topics 및auto-delete-jms-topics 특성을 사용하여 auto-delete-jms-topics 특성이 부분적으로만 구현되고 JBoss EAP 7에서 완전히 구성 가능한 것은 아닙니다. 더 이상 사용되지 않는 이러한 속성은 기술 프리뷰 기능으로 만 제공되었으며 지원되지 않았습니다.

더 이상 사용되지 않는 이러한 속성의 용도를 다음 대체 특성으로 교체해야 합니다.

JBoss EAP 6에서는 기본 주소 설정 특성이 false 로 설정되었습니다. JBoss EAP 7의 대체 속성은 기본적으로 true입니다.

JBoss EAP 6 동작을 유지하려면 대체 특성을 false 로 설정해야 합니다.

이러한 교체 속성에 대한 자세한 내용은 Configuring Messaging 에서 Address Setting Attributes 를 참조하십시오.

JBoss EAP 7.2부터 클라이언트 애플리케이션이 Artemis 클라이언트 JAR(예: artemis-jms-client, artemis- commons, artemis- core-client 또는 artemis- selector )에 직접 의존하는 경우, pom.xml 파일에 다음 종속성을 for wildfly-client-properties 에 추가해야 합니다.

<dependency>
  <groupId>org.jboss.eap</groupId>
  <artifactId>wildfly-client-properties</artifactId>
</dependency>

이는 JBEAP-15889 에 설명된 대로 이전 JBoss EAP 7 클라이언트에서 message.getJMSReplyTo() 를 호출할 때 JMSRuntimeException 을 방지하기 위한 것입니다.

인터셉터 및 MessageBody 클래스

JSR 311: JAX-RS: RESTful Web Services 용 Java™ API에 인터셉터 프레임워크가 포함되지 않았으므로 RESTEasy 2에서 인터셉터 프레임워크를 제공했습니다. JSR 339: JAX-RS 2.0: RESTful Web Services 용 Java API는 공식 인터셉터 및 필터 프레임워크를 도입하여 RESTEasy 2에 포함된 인터셉터 프레임워크가 더 이상 사용되지 않으며 RESTEasy 3.x의 JAX-RS 호환 인터셉터 기능으로 대체되었습니다. 관련 인터페이스는 jaxrs-api 모듈의 javax.ws.rs.ext 패키지에 정의되어 있습니다.

인터셉터에 대한 자세한 내용은 JBoss EAP용 웹 서비스 애플리케이션 개발의 RESTEasy 인터셉터 를 참조하십시오.

새로운 교체 API에 대한 자세한 내용은 RESTEasy JAX-RS 3.9.0.Final API 를 참조하십시오.

클라이언트 API

resteasy-jaxrs 의 RESTEasy 클라이언트 프레임워크는 JBoss EAP 7.0에서 JAX-RS 2.0 호환 resteasy-client 모듈로 교체되었습니다. 결과적으로 일부 RESTEasy 클라이언트 API 클래스 및 메서드는 더 이상 사용되지 않습니다.

StringConverter

RESTEasy 3.x에서는 org.jboss.resteasy.spi.StringConverter 클래스가 더 이상 사용되지 않습니다. 이 기능은 JAX-RS jax.ws.rs.ext.ParamConverterProvider 클래스를 사용하여 교체할 수 있습니다.

ResteasyProviderFactory Add 방법

대부분의 org.jboss.resteasy.spi.ResteasyProviderFactory add() 메서드가 제거되었거나 RESTEasy 3.0에서 보호되었습니다. 예를 들어 addBuiltInMessageBodyReader() 및 addBuiltInMessageBodyWriter() 메서드가 제거되고 addMessageBodyReader() 및 addMessageBodyWriter() 메서드가 보호되었습니다.

이제 register Provider() 및 registerProviderInstance() 메서드를 사용해야 합니다.

RESTEasy 3에서 제거된 추가 클래스

서버에 캐시해야 하는 JAX-RS 메서드에 대한 응답을 지정한 @org.jboss.resteasy.annotations.cache.ServerCached 주석은 RESTEasy 3에서 제거되었으며 애플리케이션 코드에서 제거해야 합니다.

SignedInput 및 SignedOuput

보안 필터

@RolesAllowed, @ PermitAll 및 @DenyAll 에 대한 보안 필터는 이제 "401 Unauthorized" 대신 "403 Forbidden"을 반환합니다.

클라이언트측 필터

RESTEasy 3.0 이전 릴리스에서 RESTEasy 클라이언트 API를 사용할 때 JAX-RS 2.0에서 도입된 클라이언트 측 필터는 바인딩 및 실행되지 않습니다.

비동기 HTTP 지원

JAX-RS 2.0 사양은 @ Suspended 주석 과 AsynResponse 인터페이스를 사용하여 비동기 HTTP 지원을 추가했기 때문에 비동기 HTTP에 대한 RESTEasy 독점 API는 더 이상 사용되지 않으며 향후 RESTEasy 릴리스에서 제거될 수 있습니다. 비동기 Tomcat 및 비동기 JBoss Web 모듈도 서버 설치에서 제거되었습니다. 서블릿 3.0 컨테이너를 사용하지 않는 경우 비동기 HTTP 서버 측 처리가 동일한 요청 스레드에서 동기적으로 시뮬레이션되고 실행됩니다.

서버 측 캐시

서버 측 캐시 설정이 변경되었습니다. 자세한 내용은 RESTEasy 문서를 참조하십시오.

YAML 공급자 설정 변경

JBoss EAP의 이전 릴리스에서는 기본적으로 RESTEasy YAML 프로바이더 설정이 활성화되었습니다. 이는 JBoss EAP 7에서 변경되었습니다. YAML 공급자는 기본적으로 비활성화되어 있습니다. RESTEasy에서 매핑 해제를 위해 사용하는 SnakeYAML 라이브러리의 보안 문제로 인해 해당 사용은 지원되지 않으며 애플리케이션에서 명시적으로 활성화해야 합니다. 애플리케이션에서 YAML 프로바이더를 활성화하고 Maven 종속성을 추가하는 방법에 대한 자세한 내용은 JBoss EAP용 웹 서비스 애플리케이션 개발에서 YAML 공급자를 참조하십시오.

Content-Type 헤더의 기본 Charset UTF-8

JBoss EAP 7.1부터 resteasy.add.charset 매개 변수는 기본적으로 true 로 설정됩니다. RESTEasy가 명시적 문자 집합 없이 text/* 또는 application/xml* 미디어 유형을 반환할 때 반환된 content-type 헤더에 charactersset=UTF-8 을 추가하지 않도록 하려면 resteasy.add.charset 매개변수를 false 로 설정할 수 있습니다.

텍스트 미디어 유형 및 문자 세트에 대한 자세한 내용은 JBoss EAP용 웹 서비스 애플리케이션 개발에서 텍스트 미디어 유형 및 문자 집합을 참조하십시오.

SerializableProvider

신뢰할 수 없는 소스에서 Java 오브젝트를 역직렬화하는 것은 안전하지 않습니다. 이러한 이유로 JBoss EAP 7에서 org.jboss.resteasy.plugins.providers.SerializableProvider 클래스는 기본적으로 비활성화되어 있으므로 이 공급업체를 사용하지 않는 것이 좋습니다.

리소스 메서드에 요청 일치

RESTEasy 3에서는 JAX-RS 사양에 정의된 대로 일치 규칙 구현에 개선 및 수정 사항이 적용되었습니다. 특히 하위 리소스 메서드의 모호한 URI와 하위 리소스 검색기를 처리하는 방법에 대한 변경 사항이 발생했습니다.

RESTEasy 2에서는 동일한 URI를 사용하는 다른 하위 리소스가 있는 경우에도 하위 리소스 검색기를 실행할 수 있었습니다. 이 동작은 사양에 따라 올바르지 않았습니다.

RESTEasy 3에서 하위 리소스 및 하위 리소스의 모호한 URI가 있는 경우 하위 리소스를 호출하는 데 성공하지만 하위 리소스 위치를 호출하면 HTTP 상태 405 Method Not Allowed 오류가 발생합니다.

다음 예제에는 하위 리소스 메서드 및 하위 리소스 검색 도구에 모호한 @Path 주석이 포함되어 있습니다. 엔드포인트의 URI, another Resource Locator 및 anotherResourceLocator 가 모두 동일합니다. 두 엔드포인트의 차이점은 anotherResource 메서드가 REST 동사 POST 와 연결되어 있다는 점입니다. anotherResourceLocator 메서드는 REST 동사와 연결되어 있지 않습니다. 사양에 따라 REST 동사가 있는 엔드포인트(이 경우 anotherResource 메서드)가 항상 선택됩니다.

@Path("myResource")
public class ExampleSubResources {
    @POST
    @Path("items")
    @Produces("text/plain")
    public Response anotherResource(String text) {
        return Response.ok("ok").build();
    }

    @Path("items")
    @Produces("text/plain")
    public SubResource anotherResourceLocator() {
        return new SubResource();
    }
}

리소스 방법 알고리즘 스위치

3.0.25.Final 이전의 RESTEasy 3.0.x 버전에서 사용된 리소스 메서드 일치 알고리즘에서 발견된 버그로 인해 요청에 응답할 때 RESTEasy가 너무 많은 리소스 메서드를 반환했습니다.

일치하는 알고리즘에는 세 가지 단계가 있습니다.

JAX-RS 2.0 사양에 따라 잠재적인 리소스 메서드 집합을 정렬한 후 최대 요소만 3단계로 전달해야 합니다. 그러나 RESTEasy 3.0.x 이전의 RESTEasy 3.0.x 구현은 모든 메서드를 3단계로 전달했습니다. JBoss EAP 7.1.0에 포함된 RESTEasy 3.0.24는 이러한 잘못된 동작을 보여줍니다.

JBoss EAP 7.1.1에 포함된 RESTEasy 3.0.25에서는 JAX-RS 2.0 사양을 준수하도록 3단계로 전달되는 메서드를 제한하는 수정 사항을 제공합니다. 느슨한 동작이 선호될 수 있기 때문에 RESTEasy 3.0.25에는 컨텍스트 매개 변수 옵션 인 resteasy.loose.step2.request.matching 이 도입되어 이전 동작을 활성화하도록 구성할 수 있습니다.

7.1.0에서 7.1.1으로 JBoss EAP 서버를 업데이트하고 이전 동작을 유지하고 모든 잠재적 리소스 메서드를 3단계로 전달하려면 resteasy.loose.step2.request.matching 옵션을 true 로 설정합니다.

일치하는 모든 리소스 메서드를 단계 3으로 전달하도록 JAX-RS 2.1 사양에서 일치 알고리즘이 변경되었습니다. JBoss EAP 7.4에 포함된 RESTEasy 3.9.0은 JAX-RS 2.0 사양에 정의된 대로 엄격한 동작을 유지하기 위해 jaxrs.2.0.request.matching 옵션을 제공합니다.

애플리케이션을 7.1.0에서 7.2.x로 마이그레이션하는 경우 리소스 메서드 일치 알고리즘의 동작이 변경되지 않아야 합니다. 애플리케이션을 7.1.1에서 7.2.x 이상으로 마이그레이션하고 JAX-RS 2.0 사양에 정의된 대로 엄격한 동작을 유지하려면 jaxrs.2.0.request.matching 옵션을 true 로 설정합니다.

SPI 예외

모든 SPI 오류 예외는 더 이상 사용되지 않으며 더 이상 내부적으로 사용되지 않습니다. 해당 JAX-RS 예외로 교체되었습니다.

InjectorFactory 및 Registry

InjectorFactory 및 레지스트리 SPI가 변경되었습니다. 문서화 및 지원되는 대로 RESTEasy를 사용하는 경우에는 문제가 되지 않아야 합니다.

JBoss EAP에 포함된 jackson의 버전이 변경되었습니다. 이전 버전의 JBoss EAP에는 jackson 1.✓이 포함되었습니다. JBoss EAP 7에는 이제 jackson 2.6.3 이상이 포함됩니다. 결과적으로jackson 공급자는 resteasy-jackson-provider에서 resteasy-jackson2-provider 로 변경되었습니다.

resteasy-jackson2-provider 로 업그레이드하려면 패키지를 변경해야 합니다. 예를 들어, jackson 주석 패키지는 org.codehaus.jackson.annotate에서 com. fasterxml.jackson.annotation 으로 변경되었습니다.

JBoss EAP의 이전 릴리스에 포함된 기본 프로바이더를 사용하도록 애플리케이션을 전환하려면 JBoss EAP용 웹 서비스 애플리케이션 개발에서 기본 jackson 공급자 전환을 참조하십시오.

Spring 4.0 프레임워크는 Java 8에 대한 지원을 도입했습니다. Spring과의 RESTEasy 3.x 통합을 사용하려는 경우 JBoss EAP 7에서 지원하는 가장 빠른 안정적인 버전이므로 4.2.x를 배포의 최소 Spring 버전으로 지정해야 합니다.

RESTEasy Hardtison JSON 프로바이더는 JBoss EAP 7에서 더 이상 사용되지 않으며 더 이상 기본적으로 배포에 추가되지 않습니다. 권장되는 RESTEasyjackson 공급업체로 전환하는 것이 좋습니다. rpmtison 공급자를 계속 사용하려면 다음 예에 설명된 대로 jboss-deployment-descriptor.xml 파일에서 명시적 종속성을 정의해야 합니다.

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
  <deployment>
    <exclusions>
      <module name="org.jboss.resteasy.resteasy-jackson2-provider"/>
      <module name="org.jboss.resteasy.resteasy-jackson-provider"/>
    </exclusions>
    <dependencies>
      <module name="org.jboss.resteasy.resteasy-jettison-provider" services="import"/>
    </dependencies>
  </deployment>
</jboss-deployment-structure>

명시적 종속성을 정의하는 방법에 대한 자세한 내용은 JBoss EAP 개발 가이드 의 배포에 명시적 모듈 종속성 추가를 참조하십시오.

JBoss EAP 7.3은 MicroProfile REST 클라이언트의 버전 1.3.x를 지원합니다. 이전 버전의 MicroProfile REST 클라이언트를 사용하는 경우 코드에서 일부 업데이트를 수행해야 합니다.

org.jboss.resteasy.client.microprofile.MicroprofileClientBuilderResolver 클래스는 org.eclipse.microprofile.rest.client.RestClientBuilder 로 교체됩니다. 예를 들면 다음과 같습니다.

@Path("resource")
public interface TestResourceIntf {

   @Path("test")
   @GET
   public String test();
}

TestResourceIntf service = RestClientBuilder.newBuilder()
                              .baseUrl("http://localhost:8081/")
                              .build(TestResourceIntf.class);
String s = service.test();

MicroProfile REST 클라이언트에 대한 자세한 내용은 JBoss EAP Developing Web Services Applications 가이드 의 MicroProfile REST 클라이언트를 참조하십시오.

MicroProfile Config 는 개발자가 해당 앱을 수정하거나 다시 패키징하지 않고도 여러 환경에서 실행하도록 애플리케이션 및 마이크로 서비스를 구성하는 데 사용할 수 있는 사양의 이름입니다. 이전에는 JBoss EAP에서 MicroProfile Config를 기술 프리뷰로 사용할 수 있었지만 이후 제거되었습니다. MicroProfile Config는 이제 JBoss EAP XP에서만 사용할 수 있습니다.

JBoss EAP 6.4에서 Hibernate ORM 3을 더 쉽게 사용할 수 있는 통합 클래스는 JBoss EAP 7에서 제거되었습니다. 애플리케이션에서 여전히 Hibernate ORM 3 라이브러리를 사용하는 경우 Hibernate ORM 5를 사용하도록 애플리케이션을 마이그레이션하는 것이 좋습니다. Hibernate ORM 3은 더 이상 많은 노력 없이 JBoss EAP에서 작동하지 않기 때문입니다. Hibernate ORM 5로 마이그레이션할 수 없는 경우 Hibernate ORM 3 JAR에 대한 맞춤형 JBoss 모듈을 정의하고 애플리케이션에서 Hibernate ORM 5 클래스를 제외해야 합니다.

애플리케이션에 두 번째 수준의 캐시가 활성화된 경우 Infinispan 8.x가 Hibernate ORM 5.0과 통합되었습니다. 그런 다음 Infinispan을 Hibernate 2 레벨 캐시 공급자로 사용하는 지원이 Hibernate ORM 5.3의 Infinispan 프로젝트로 이동되어 해당 릴리스에서 hibernate-infinispan 모듈이 삭제되었습니다.

Hibernate ORM 4.x로 작성된 애플리케이션은 여전히 Hibernate ORM 4.x를 사용할 수 있습니다. Hibernate ORM 4.x JAR에 대한 맞춤형 JBoss 모듈을 정의하고 애플리케이션에서 Hibernate ORM 5 클래스를 제외해야 합니다. 그러나 Hibernate ORM 5를 사용하도록 애플리케이션 코드를 다시 작성하는 것이 좋습니다. Hibernate ORM 5로의 마이그레이션에 대한 자세한 내용은 Hibernate ORM 5로 마이그레이션을 참조하십시오.

JBoss EAP 7.0에는 Hibernate ORM 5.0이 포함되어 있습니다. 이 섹션에서는 Hibernate ORM 버전 4.3에서 버전 5로 마이그레이션할 때 필요한 변경 사항을 중점적으로 설명합니다. Hibernate ORM 4와 Hibernate ORM 5 간에 구현된 변경 사항에 대한 자세한 내용은 Hibernate ORM 5.0 마이그레이션 가이드를 참조하십시오.

제거 및 사용되지 않는 클래스

더 이상 사용되지 않는 다음 클래스는 Hibernate ORM 5에서 제거되었습니다.

클래스 및 패키지의 기타 변경 사항

유형 처리

트랜잭션 관리

기타 Hibernate ORM 5 변경 사항

JBoss EAP 7.1에는 Hibernate ORM 5.1이 포함되어 있습니다. 이 섹션에서는 Hibernate ORM 버전 5.0에서 버전 5.1로 마이그레이션할 때 필요한 차이점과 변경 사항을 중점적으로 설명합니다.

Hibernate ORM 5.1 기능

이 Hibernate 릴리스에는 JBoss EAP 7.1.0 릴리스 노트 의 Hibernate ORM 5.1 기능에 자세히 설명된 여러 성능 개선 사항 및 버그 수정이 포함되어 있습니다. Hibernate ORM 5.0과 Hibernate ORM 5.1 간에 구현된 변경 사항에 대한 자세한 내용은 Hibernate ORM 5.1 마이그레이션 가이드를 참조하십시오.

스키마 관리 툴링 변경

JBoss EAP 7의 스키마 관리 툴링 변경

Hibernate ORM 5.1의 스키마 관리 툴링 변경은 주로 다음 영역에 중점을 둡니다.

스키마 관리 툴링 변경은 다음 클래스 중 하나를 직접 사용하는 애플리케이션의 마이그레이션 문제만 고려해야 합니다.

JBoss EAP 7.1의 스키마 관리 툴링 변경

JBoss EAP 7.1에 포함된 Hibernate ORM 5.1.10은 스키마Migrator 및 Schema Validator 성능을 향상시키는 데이터베이스 테이블을 검색하는 새로운 전략을 도입했습니다. 이 전략은 단일 java.sql.DatabaseMetaData#getTables(String, String, String, String[]) 호출을 실행하여 각 javax.persistence.Entity 에 매핑된 데이터베이스 테이블이 있는지 확인합니다. 기본 전략이며 hibernate.hbm2ddl.jdbc_metadata_extraction_strategy=grouped 속성 설정을 사용합니다. 이 전략을 사용하려면 hibernate.default_schema 및/or hibernate.default_catalog 가 제공되어야 할 수 있습니다.

각 javax.persistence.Entity 에 대해 java.sql.DatabaseMetaData#getTables(String, String, String, String[]) 호출을 실행하는 이전 전략을 사용하려면 hibernate.hbm2ddl.jdbc_metadata_extraction_strategy=individually 속성 설정을 사용합니다.

JBoss EAP 7.4에는 Hibernate ORM 5.3이 포함되어 있습니다. 이 섹션에서는 Hibernate ORM 5.1에서 Hibernate ORM 5.3으로 마이그레이션할 때 필요한 일부 변경 사항을 중점적으로 설명합니다.

Hibernate ORM 5.2 기능

Hibernate ORM 5.2는 Java 8 JDK를 사용하여 빌드되며 런타임 시 Java 8 JRE가 필요합니다. 다음은 이 릴리스에서 수행된 몇 가지 변경 사항 목록입니다.

Hibernate 5.2에 구현된 변경 사항 전체 목록은 Hibernate ORM 5.2 마이그레이션 가이드를 참조하십시오.

Hibernate ORM 5.3 기능

Hibernate ORM 5.3은 Jakarta Persistence 2.2 사양에 대한 지원을 추가합니다. 이 릴리스에는 다른 개선 사항과 함께 이 사양을 준수하기 위한 변경 사항이 포함되어 있습니다. 다음은 이러한 변경 사항 중 일부입니다.

이들 및 Hibernate 5.3에 구현된 기타 변경 사항의 전체 목록은 Hibernate ORM 5.3 마이그레이션 가이드를 참조하십시오.

JBoss EAP 7에서는 기본 원격 커넥터와 포트가 변경되었습니다. 이 변경 사항에 대한 자세한 내용은 원격 URL 커넥터 및 포트 업데이트를 참조하십시오.

migrate 작업을 사용하여 서버 구성을 마이그레이션한 경우 이전 설정이 유지되며 여기에서 자세히 설명하지 않아도 됩니다. 그러나 새로운 JBoss EAP 7 기본 구성을 사용하는 경우 다음과 같이 변경해야 합니다.

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=8080
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

새로운 기본 JBoss EAP 7 구성으로 실행 중인 경우 새 기본 원격 포트 및 커넥터를 사용하도록 클라이언트 코드를 수정해야 합니다.

다음은 JBoss EAP 6의 클라이언트 코드에 원격 이름 지정 속성을 지정하는 방법의 예입니다.

java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
java.naming.provider.url=remote://localhost:4447

다음은 JBoss EAP 7의 클라이언트 코드에서 원격 이름 지정 속성을 지정하는 방법의 예입니다.

java.naming.factory.initial=org.wildfly.naming.client.WildFlyInitialContextFactory
java.naming.provider.url=http-remoting://localhost:8080

JBoss EAP 7.0은 JBoss EJB 클라이언트 2.1.4와 함께 제공되지만 JBoss EAP 7.1 이상에서는 API에 대한 여러 변경 사항이 포함된 JBoss EJB 클라이언트 4.0.x와 함께 제공됩니다.

JBoss EAP 7.2의 2.0.8에서 2.1.1로 org.apache.santuario.xmlsec 모듈의 업그레이드로 인해 PicketLinkSTS 에서 리모팅하는 것과 관련된 회귀 문제가 발생했습니다. 문제는 다음 런타임 예외로 표시됩니다.

java.lang.IllegalArgumentException: ELY05131: Invalid ASCII control "0xA"

이는 어설션에서 생성된 SignatureValue 의 형식 변경으로 인해 발생합니다. 이전 릴리스에서 생성된 값은 다음 예와 유사했습니다.

<dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">cUNpFJIZlLYrBDZtQSTDrq2K6PbnAHyg2qbx/D5FuB4XMjdQ5oxQjkMejLyelnA7s4GFusoLhahlqlTOT8UrOyxrR4yYAmJ/e5s+f4gys926+tbiraT/3/wG8wM/Lvcjvk5Ap69zODuRYpypsWfA4jrI7TTBXVPGy8g4KUdnFviUiTuFTc2Ghgxp53AmUuLis/THyP28jE7+28//q8bi/bQrFwHC6tWX67+NK1duFCOcQ6IPIKeVrePZz55Ivgl+WWdkF6uYCz5IdMzurhzmeQ3K8DAMIxz/MG67VWJIOnuGNWF7nmdye5zd9AFcRsr1XadvZJCbGNfuc89AL5inCg==</dsig:SignatureValue>

JBoss EAP 7.2에서 생성된 문자열 값에는 이제 잘못된 숨겨진 ASCII 0xD 캐리지 리턴 인스턴스와 0 xA 라인 피드 제어 문자의 인스턴스가 포함됩니다.

<dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">cUNpFJIZlLYrBDZtQSTDrq2K6PbnAHyg2qbx/D5FuB4XMjdQ5oxQjkMejLyelnA7s4GFusoLhahl&#13;
qlTOT8UrOyxrR4yYAmJ/e5s+f4gys926+tbiraT/3/wG8wM/Lvcjvk5Ap69zODuRYpypsWfA4jrI&#13;
7TTBXVPGy8g4KUdnFviUiTuFTc2Ghgxp53AmUuLis/THyP28jE7+28//q8bi/bQrFwHC6tWX67+N&#13;
K1duFCOcQ6IPIKeVrePZz55Ivgl+WWdkF6uYCz5IdMzurhzmeQ3K8DAMIxz/MG67VWJIOnuGNWF7&#13;
nmdye5zd9AFcRsr1XadvZJCbGNfuc89AL5inCg==</dsig:SignatureValue>

설명된 런타임 예외가 발생하면 반환된 어설션 문자열에서 숨겨진 ASCII 문자 발생을 제거하도록 클라이언트 코드를 업데이트합니다. 예를 들어 현재 코드가 다음 예와 유사하다고 가정합니다.

WSTrustClient client = new WSTrustClient("PicketLinkSTS", "PicketLinkSTSPort",
                "http://localhost:8080/picketlink-sts/PicketLinkSTS", new WSTrustClient.SecurityInfo(username, password));
Element assertion = client.issueToken(SAMLUtil.SAML2_TOKEN_TYPE);

// Return the assertion as a string
String assertionString = DocumentUtil.getNodeAsString(assertion);
...
properties.put("remote.connection.main.password", assertionString);

잘못된 숨겨진 ASCII 0xD 캐리지 리턴 및 0 xA 줄 피드 문자의 발생을 제거하려면 코드 행을 추가해야 합니다. 예를 들면 다음과 같습니다.

WSTrustClient client = new WSTrustClient("PicketLinkSTS", "PicketLinkSTSPort",
                "http://localhost:8080/picketlink-sts/PicketLinkSTS", new WSTrustClient.SecurityInfo(username, password));
Element assertion = client.issueToken(SAMLUtil.SAML2_TOKEN_TYPE);

// Return the assertion as a string, stripping the invalid hidden ASCII characters
String assertionString = DocumentUtil.getNodeAsString(assertion).replace(String.valueOf((char) 0xA), "").replace(String.valueOf((char) 0xD), "");
...
properties.put("remote.connection.main.password", assertionString);

JBoss EAP 6.4에서 AuthenticatorBase 를 확장한 사용자 지정 인증 노드를 생성한 경우 JBoss EAP 7에서 사용자 지정 HTTP 인증 구현으로 수동으로 교체해야 합니다. HTTP 인증 메커니즘은 elytron 하위 시스템에서 생성된 다음 undertow 하위 시스템에 등록됩니다. 사용자 지정 HTTP 인증 메커니즘을 구현하는 방법에 대한 자세한 내용은 JBoss EAP 의 개발 가이드에서 사용자 지정 HTTP 메커니즘 개발을 참조하십시오.

SAML v2 구성을 사용한 SSO에 필요한 변경 사항에 대한 자세한 내용은 JBoss EAP에 대한 SAML v2로 SSO를 설정하는 방법의 변경 사항을 참조하십시오.

Kerberos를 사용한 SSO 구성 차이점에 대한 자세한 내용은 JBoss EAP용 Kerberos로 SSO를 설정하는 방법에서 이전 버전 구성의 차이점을 참조하십시오.

다음 목록에서는 애플리케이션을 JBoss EAP 6에서 JBoss EAP 7로 마이그레이션할 때 인식할 새 클러스터링 기능 일부를 설명합니다.

이 섹션의 나머지 부분에서는 클러스터링 변경 사항이 애플리케이션을 JBoss EAP 7로 마이그레이션하는 데 어떤 영향을 줄 수 있는지 설명합니다.

JBoss EAP 7에는 새 웹 세션 클러스터링 구현이 도입되었습니다. 기존 JBoss Web 하위 시스템 소스 코드와 긴밀하게 연결된 이전 구현을 대체합니다.

새 웹 세션 클러스터링 구현은 jboss-web.xml JBoss EAP 독점 웹 애플리케이션 XML 설명자 파일에서 애플리케이션을 구성하는 방식에 영향을 미칩니다. 다음은 이 파일에 남아 있는 클러스터링 구성 요소뿐입니다.

<jboss-web>
  ...
  <max-active-sessions>...</max-active-sessions>
  ...
  <replication-config>
    <replication-granularity>...</replication-granularity>
    <cache-name>...</cache-name>
  </replication-config>
  ...
</jboss-web>

distributable-web 하위 시스템은 jboss-web.xml 의 <replication-config> 요소를 사용하지 않습니다. 애드혹 배포 가능한 웹 세션 프로필을 생성하여 <replication-config> 의 사용을 향상시킵니다.

이름별로 세션 관리 프로필을 참조하거나 배포별 세션 관리 구성을 제공하여 기본 배포 가능한 세션 관리 동작을 재정의할 수 있습니다. 자세한 내용은 Overide Default Distributable Session Management Behavior 를 참조하십시오.

다음 표는 더 이상 사용되지 않는 jboss-web.xml 파일의 요소에 대해 유사한 동작을 수행하는 방법을 설명합니다.

또한 이 새로운 구현에서는 동시 쓰기 캐시 저장소와 패시베이션 전용 캐시 저장소를 지원합니다. 일반적으로 동시 쓰기 캐시 저장소는 무효화 캐시와 함께 사용됩니다. 무효화 캐시와 함께 사용할 때 JBoss EAP 6의 웹 세션 클러스터링 구현이 제대로 작동하지 않았습니다.

다음 방법 중 하나로 배포 가능한 기본 세션 관리 동작을 재정의할 수 있습니다.

기존 세션 관리 프로파일 참조

/WEB-INF/distributable-web.xml

<?xml version="1.0" encoding="UTF-8"?>
<distributable-web xmlns="urn:jboss:distributable-web:1.0">
    <session-management name="foo"/>
</distributable-web>

/META-INF/jboss-all.xml

<?xml version="1.0" encoding="UTF-8"?>
<jboss xmlns="urn:jboss:1.0">
    <distributable-web xmlns="urn:jboss:distributable-web:1.0">
        <session-management name="foo"/>
    </distributable-web>
</jboss>

배포별 세션 관리 프로필 사용

단일 웹 애플리케이션만 사용자 지정 세션 관리 구성을 사용하는 경우 배포 설명자 자체 내에서 구성을 정의할 수 있습니다. 애드혹 구성은 distributable-web 하위 시스템에서 사용하는 구성과 동일합니다.

<?xml version="1.0" encoding="UTF-8"?>
<distributable-web xmlns="urn:jboss:distributable-web:1.0">
    <infinispan-session-management cache-container="foo" cache="bar" granularity="SESSION">
        <primary-owner-affinity/>
    </infinispan-session-management>
</distributable-web>

/META-INF/jboss-all.xml

<?xml version="1.0" encoding="UTF-8"?>
<jboss xmlns="urn:jboss:1.0">
    <distributable-web xmlns="urn:jboss:distributable-web:1.0">
        <infinispan-session-management cache-container="foo" cache="bar" granularity="ATTRIBUTE">
            <local-affinity/>
        </infinispan-session-management>
    </distributable-web>
</jboss>

JBoss EAP 6에서는 다음 방법 중 하나로 상태 저장 세션 빈(SFSB)에 대한 클러스터링 동작을 활성화해야 했습니다.

JBoss EAP 7에서는 더 이상 클러스터링 동작을 활성화할 필요가 없습니다. 기본적으로 서버가 HA 프로필을 사용하여 시작된 경우 SFSB의 상태가 자동으로 복제됩니다. 다음 방법 중 하나로 이 기본 동작을 비활성화할 수 있습니다.

JBoss EAP 6에서는 클러스터링 서비스의 API가 프라이빗 모듈에 있었지만 지원되지 않았습니다.

JBoss EAP 7은 애플리케이션에서 사용할 공용 클러스터링 서비스 API를 도입했습니다. 새 서비스는 가볍고 주입이 용이하도록 설계되었으며 외부 종속성이 필요하지 않습니다.

이러한 서비스는 JBoss EAP 5의 HAPartition 및 GroupCommunicationService, GroupMembershipNotifier 및 JBoss EAP 6의 Group RpcDispatcher 라는 이전 릴리스에서 사용 가능한 유사한 API를 대체합니다.

자세한 내용은 JBoss EAP 개발 가이드 의 클러스터링 서비스를 위한 공용 API 를 참조하십시오.

JBoss EAP 6에서는 클러스터 전체 HA Singleton 서비스에 사용할 수 있는 공용 API가 없었습니다. 비공개 org.jboss.as.clustering.singleton.* 클래스를 사용한 경우 애플리케이션을 JBoss EAP 7로 마이그레이션할 때 새 공용 org.wildfly.clustering.singleton.* 패키지를 사용하도록 코드를 변경해야 합니다.

HA Singleton 서비스에 대한 자세한 내용은 JBoss EAP 의 개발 가이드에서 HA Singleton 서비스를 참조하십시오. HA Singleton 배포에 대한 자세한 내용은 JBoss EAP의 개발 가이드에서 HA Singleton 배포를 참조하십시오.

JBoss EAP 7.0의 레거시 보안 하위 시스템에서 일반 텍스트 문자열 암호화를 저장하는 데 사용된 자격 증명 모음은 새로 설계된 자격 증명 저장소를 사용하여 문자열을 저장하는 JBoss EAP 7.1 이상에서 Elytron과 호환되지 않습니다. 자격 증명은 JBoss EAP 구성 파일 외부의 스토리지 파일에 자격 증명을 안전하게 암호화합니다. Elytron에서 제공하는 구현을 사용하거나 인증 정보 저장소 API 및 SPI를 사용하여 구성을 사용자 지정할 수 있습니다. 각 JBoss EAP 서버에는 여러 자격 증명 저장소가 포함될 수 있습니다.

레거시 보안 하위 시스템을 계속 사용하는 경우 자격 증명 모음 데이터를 수정하거나 업데이트할 필요가 없습니다. 그러나 Elytron을 사용하도록 애플리케이션을 마이그레이션하려면 기존 자격 증명 저장소를 자격 증명 저장소로 변환하여 elytron 하위 시스템에서 처리할 수 있어야 합니다. 자격 증명 저장소에 대한 자세한 내용은 JBoss EAP용 서버 보안 구성 방법의 자격 증명 저장소 를 참조하십시오.

WildFly Elytron 도구를 사용하여 Vault 데이터 마이그레이션

WildFly Elytron 툴은 자격 증명 저장소로 자격 증명 모음 콘텐츠를 마이그레이션하는 데 도움이 되는 자격 증명 모음 명령을 제공합니다. EAP_HOME/bin 디렉터리에 있는 elytron-tool 스크립트를 실행하여 툴을 실행합니다.

$ EAP_HOME/bin/elytron-tool.sh vault VAULT_ARGUMENTS

원하는 경우 java -jar 명령을 실행하여 툴을 실행할 수 있습니다.

$ java -jar EAP_HOME/bin/wildfly-elytron-tool.jar vault VAULT_ARGUMENTS

다음 명령을 사용하여 사용 가능한 모든 인수에 대한 설명을 얻을 수 있습니다.

$ EAP_HOME/bin/elytron-tool.sh vault --help

다음 마이그레이션 옵션 중 하나를 선택합니다.

단일 보안 Vault를 자격 증명 저장소로 마이그레이션

다음은 단일 보안 자격 증명 모음을 자격 증명 저장소로 변환하는 데 사용되는 명령의 예입니다.

$ EAP_HOME/bin/elytron-tool.sh vault --enc-dir vault_data/ --keystore vault-jceks.keystore --keystore-password MASK-2hKo56F1a3jYGnJwhPmiF5 --iteration 34 --salt 12345678 --alias test --location cs-v1.store --summary

이 명령은 보안 자격 증명 저장소로 변환하고, 출력에서 변환하는 데 사용된 관리 CLI 명령 요약을 출력합니다.

Vault (enc-dir="vault_data/";keystore="vault-jceks.keystore") converted to credential store "cs-v1.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="cs-v1.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"})

여러 보안 Vault를 대량의 자격 증명 저장소로 마이그레이션

--bulk-convert 인수를 사용하여 자격 증명 저장소로 여러 개의 자격 증명 저장소를 변환하고 대규모 변환 설명자 파일을 가리킬 수 있습니다.

이 섹션의 예제에서는 다음 대규모 변환 설명자 파일을 사용합니다.

keystore:vault-v1/vault-jceks.keystore
keystore-password:MASK-2hKo56F1a3jYGnJwhPmiF5
enc-dir:vault-v1/vault_data/
salt:12345678
iteration:34
location:v1-cs-1.store
alias:test

keystore:vault-v1/vault-jceks.keystore
keystore-password:secretsecret
enc-dir:vault-v1/vault_data/
location:v1-cs-2.store
alias:test

# different vault vault-v1-more
keystore:vault-v1-more/vault-jceks.keystore
keystore-password:MASK-2hKo56F1a3jYGnJwhPmiF5
enc-dir:vault-v1-more/vault_data/
salt:12345678
iteration:34
location:v1-cs-more.store
alias:test

새 키 저장소: 행이 발생할 때마다 새 변환이 시작됩니다. salt,반복 및 속성을 제외하고 모든 옵션이 필수입니다.

대규모 변환을 수행하고 관리 CLI 명령을 포맷하는 출력을 생성하려면 다음 명령을 실행합니다.

$ EAP_HOME/bin/elytron-tool.sh vault --bulk-convert path/to/bulk-vault-conversion-descriptor.txt --summary

이 명령은 파일에 지정된 모든 보안 자격 증명 모음을 자격 증명 저장소로 변환하고 출력에서 이를 변환하는 데 사용된 관리 CLI 명령 요약을 출력합니다.

Vault (enc-dir="vault-v1/vault_data/";keystore="vault-v1/vault-jceks.keystore") converted to credential store "v1-cs-1.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-1.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"})
--------------------------------------

Vault (enc-dir="vault-v1/vault_data/";keystore="vault-v1/vault-jceks.keystore") converted to credential store "v1-cs-2.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-2.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="secretsecret"})
--------------------------------------

Vault (enc-dir="vault-v1-more/vault_data/";keystore="vault-v1-more/vault-jceks.keystore") converted to credential store "v1-cs-more.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-more.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"})
--------------------------------------

이 섹션의 예제에서는 다음과 같이 레거시 보안 하위 시스템에서 group .name 및 encoding.algorithm 보안 속성이 security-properties 로 정의되었다고 가정합니다.

<subsystem xmlns="urn:jboss:domain:security:2.0">
    ...
    <security-properties>
        <property name="group.name" value="engineering-group" />
        <property name="encoding.algorithm" value="BASE64" />
    </security-properties>
</subsystem>

elytron 하위 시스템에서 동일한 보안 속성을 정의하려면 다음 관리 CLI 명령을 사용하여 elytron 하위 시스템의 security-properties 특성을 설정합니다.

/subsystem=elytron:write-attribute(name=security-properties, value={ group.name = "engineering-group", encoding.algorithm = "BASE64" })

이렇게 하면 서버 구성 파일의 elytron 하위 시스템에서 다음 security-properties 가 구성됩니다.

<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
    <security-properties>
        <security-property name="group.name" value="engineering-group"/>
        <security-property name="encoding.algorithm" value="BASE64"/>
    </security-properties>
    ...
</subsystem>

이전 명령에서 사용된 write-attribute 작업은 기존 속성을 덮어씁니다. 다른 보안 속성에 영향을 주지 않고 보안 속성을 추가하거나 변경하려면 관리 CLI 명령에서 map 작업을 사용합니다.

/subsystem=elytron:map-put(name=security-properties, key=group.name, value=technical-support)

마찬가지로 map-remove 작업을 사용하여 특정 보안 속성을 제거할 수 있습니다.

/subsystem=elytron:map-remove(name=security-properties, key=group.name)

이 섹션에서는 elytron.sh 툴의 filesystem-realm 명령을 사용하여 레거시 속성 기반 보안 영역을 Elytron의 파일 시스템 기반 영역으로 마이그레이션하는 방법에 대해 설명합니다.

파일 시스템 기반 영역은 Elytron에서 사용자 ID를 저장하는 데 사용하는 파일 시스템 기반 ID 저장소입니다. filesystem-realm 명령은 properties-realm 파일을 filesystem-realm 으로 변환합니다. 또한 이 영역과 보안 도메인을 elytron 하위 시스템에 추가하는 명령을 생성합니다.

속성 기반 인증을 파일 시스템 기반 인증으로 마이그레이션하는 단계는 다음과 같습니다.

이 섹션에서는 정보를 ID 속성으로 관리할 수 있도록 레거시 LDAP 인증을 Elytron으로 마이그레이션하는 방법에 대해 설명합니다. Migrate Properties-based Authentication and Authorization to Elytron(속성 기반 인증 및 권한 부여 ) 섹션에 제공된 대부분의 정보는 특히 보안 도메인 및 인증 팩토리를 정의하는 방법과 인증에 사용할 매핑 방법에 대해 여기에 적용됩니다. 이 섹션에서는 해당 지침을 반복하지 않으므로 계속하기 전에 해당 섹션을 읽어 보십시오.

다음 예제에서는 그룹 또는 역할 정보가 LDAP에서 직접 로드되고 레거시 LDAP 인증이 다음과 같이 구성되어 있다고 가정합니다.

<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-realms>
    ...
    <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true">
      <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org">
        <attribute-mapping>
          <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
        </attribute-mapping>
      </identity-mapping>
    </ldap-realm>
  </security-realms>
  ...
  <dir-contexts>
    <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system">
      <credential-reference clear-text="secret"/>
    </dir-context>
  </dir-contexts>
</subsystem>

이 섹션에서는 JDBC 데이터 소스 기반 PicketBox 인증을 Elytron으로 마이그레이션하는 방법에 대해 설명합니다. Migrate Properties-based Authentication and Authorization to Elytron(속성 기반 인증 및 권한 부여 ) 섹션에 제공된 대부분의 정보는 특히 보안 도메인 및 인증 팩토리를 정의하는 방법과 인증에 사용할 매핑 방법에 대해 여기에 적용됩니다. 이 섹션에서는 해당 지침을 반복하지 않으므로 계속하기 전에 해당 섹션을 읽어 보십시오.

다음 예제에서는 사용자 인증 데이터가 다음 예제와 유사한 구문을 사용하여 생성된 데이터베이스 테이블에 저장되어 있다고 가정합니다.

CREATE TABLE User (
    id BIGINT NOT NULL,
    username VARCHAR(255),
    password VARCHAR(255),
    role ENUM('admin', 'manager', 'user'),
    PRIMARY KEY (id),
    UNIQUE (username)
)

인증을 위해 사용자 이름은 사용자 이름 열에 저장된 데이터와 일치하며 암호는 password 열에 16진수로 인코딩된 MD5 해시로 저장되고 권한 부여 목적으로 사용자 역할은 역할 열에 저장됩니다.

PicketBox 보안 도메인은 JBDC 데이터 소스를 사용하여 데이터베이스 테이블에서 데이터를 검색한 다음, 사용자 이름과 암호를 확인하고 역할을 할당하도록 구성됩니다. PicketBox 보안 도메인이 다음 관리 CLI 명령을 사용하여 구성되었다고 가정합니다.

/subsystem=security/security-domain=application-security:add
/subsystem=security/security-domain=application-security/authentication=classic:add( login-modules=[ { code=Database, flag=Required, module-options={ dsJndiName="java:jboss/datasources/ExampleDS", principalsQuery="SELECT password FROM User WHERE username = ?", rolesQuery="SELECT role, 'Roles' FROM User WHERE username = ?", hashAlgorithm=MD5, hashEncoding=base64 } } ] )

그러면 레거시 보안 하위 시스템에서 다음과 같은 로그인 모듈 구성이 생성됩니다.

<subsystem xmlns="urn:jboss:domain:security:2.0">
  <security-domains>
    ...
    <security-domain name="application-security">
      <authentication>
        <login-module code="Database" flag="required">
          <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/>
          <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/>
          <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/>
          <module-option name="hashAlgorithm" value="MD5"/>
          <module-option name="hashEncoding" value="base64"/>
        </login-module>
      </authentication>
    </security-domain>
  </security-domains>
</subsystem>

/subsystem=elytron/jdbc-realm=jdbc-realm:add(principal-query=[ { data-source=ExampleDS, sql="SELECT role, password FROM User WHERE username = ?", attribute-mapping=[{index=1, to=Roles } ] simple-digest-mapper={algorithm=simple-digest-md5, password-index=2} } ] )

<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-realms>
    ...
    <jdbc-realm name="jdbc-realm">
      <principal-query sql="SELECT role, password FROM User WHERE username = ?" data-source="ExampleDS">
        <attribute-mapping>
          <attribute to="Roles" index="1"/>
        </attribute-mapping>
        <simple-digest-mapper password-index="2"/>
      </principal-query>
    </jdbc-realm>
    ...
  </security-realms>
  ...
</subsystem>

Kerberos 구성으로 작업하는 경우 JBoss EAP 서버는 환경의 구성 정보를 사용하거나 시스템 속성을 사용하여 키 구성을 지정할 수 있습니다. 이 섹션에서는 Kerberos HTTP 및 Kerberos SASL 인증을 마이그레이션하는 방법에 대해 설명합니다.

다음 예제에서는 다음 시스템 속성을 사용하여 Kerberos가 구성되어 있다고 가정합니다. 이러한 시스템 속성은 레거시 구성과 마이그레이션된 Elytron 구성에 모두 적용할 수 있습니다.

# Enable debugging
/system-property=sun.security.krb5.debug:add(value=true)
# Identify the Kerberos realm to use
/system-property=java.security.krb5.realm:add(value=ELYTRON.ORG)
# Identify the address of the KDC
/system-property=java.security.krb5.kdc:add(value=kdc.elytron.org)

<system-properties>
  <property name="sun.security.krb5.debug" value="true"/>
  <property name="java.security.krb5.realm" value="ELYTRON.ORG"/>
  <property name="java.security.krb5.kdc" value="kdc.elytron.org"/>
</system-properties>

다음 마이그레이션 옵션 중 하나를 선택합니다.

Kerberos HTTP 인증 마이그레이션

레거시 보안 구성에서는 다음과 같이 HTTP 관리 인터페이스에 대해 SPNEGO 인증을 활성화하도록 보안 영역을 정의할 수 있습니다.

/core-service=management/security-realm=Kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos/keytab=HTTP\/test-server.elytron.org@ELYTRON.ORG:add(path=/path/to/test-server.keytab, debug=true)
/core-service=management/security-realm=Kerberos/authentication=kerberos:add(remove-realm=true)

<security-realms>
  ...
  <security-realm name="Kerberos">
    <server-identities>
      <kerberos>
        <keytab principal="HTTP/test-server.elytron.org@ELYTRON.ORG" path="/path/to/test-server.keytab" debug="true"/>
      </kerberos>
    </server-identities>
    <authentication>
      <kerberos remove-realm="true"/>
    </authentication>
  </security-realm>
</security-realms>

애플리케이션이 Kerberos HTTP 인증을 사용할 수 있도록 레거시 보안 도메인 쌍을 정의할 수도 있습니다.

# Define the first security domain
/subsystem=security/security-domain=host:add
/subsystem=security/security-domain=host/authentication=classic:add
/subsystem=security/security-domain=host/authentication=classic/login-module=1:add(code=Kerberos, flag=Required, module-options={storeKey=true, useKeyTab=true, principal=HTTP/test-server.elytron.org@ELYTRON.ORG, keyTab=path/to/test-server.keytab, debug=true}

# Define the second SPNEGO security domain
/subsystem=security/security-domain=SPNEGO:add
/subsystem=security/security-domain=SPNEGO/authentication=classic:add
/subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=1:add(code=SPNEGO, flag=requisite,  module-options={password-stacking=useFirstPass, serverSecurityDomain=host})
/subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=1:write-attribute(name=module, value=org.jboss.security.negotiation)
/subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=2:add(code=UsersRoles, flag=required, module-options={password-stacking=useFirstPass, usersProperties=  /path/to/kerberos/spnego-users.properties, rolesProperties=  /path/to/kerberos/spnego-roles.properties, defaultUsersProperties=  /path/to/kerberos/spnego-users.properties, defaultRolesProperties=  /path/to/kerberos/spnego-roles.properties})

<subsystem xmlns="urn:jboss:domain:security:2.0">
  <security-domains>
    ...
    <security-domain name="host">
      <authentication>
        <login-module name="1" code="Kerberos" flag="required">
          <module-option name="storeKey" value="true"/>
          <module-option name="useKeyTab" value="true"/>
          <module-option name="principal" value="HTTP/test-server.elytron.org@ELYTRON.ORG"/>
          <module-option name="keyTab" value="/path/to/test-server.keytab"/>
          <module-option name="debug" value="true"/>
        </login-module>
      </authentication>
    </security-domain>
    <security-domain name="SPNEGO">
      <authentication>
        <login-module name="1" code="SPNEGO" flag="requisite" module="org.jboss.security.negotiation">
          <module-option name="password-stacking" value="useFirstPass"/>
          <module-option name="serverSecurityDomain" value="host"/>
        </login-module>
        <login-module name="2" code="UsersRoles" flag="required">
          <module-option name="password-stacking" value="useFirstPass"/>
          <module-option name="usersProperties" value="path/to/kerberos/spnego-users.properties"/>
          <module-option name="rolesProperties" value="  /path/to/kerberos/spnego-roles.properties"/>
          <module-option name="defaultUsersProperties" value="  /path/to/kerberos/spnego-users.properties"/>
          <module-option name="defaultRolesProperties" value="  /path/to/kerberos/spnego-roles.properties"/>
        </login-module>
      </authentication>
    </security-domain>
  </security-domains>
</subsystem>

그런 다음 레거시 애플리케이션은 SPNEGO 보안 도메인을 참조하고 SPNEGO 메커니즘으로 보호됩니다.

Kerberos HTTP 인증을 Elytron으로 마이그레이션

보안 영역과 Kerberos 보안 팩토리를 사용하여 관리 인터페이스와 애플리케이션 모두를 Elytron에서 보호할 수 있습니다.

Kerberos Remoting SASL 인증 마이그레이션

Kerberos/GSSAPI SASL 인증에 대한 레거시 보안 영역을 기본 관리 인터페이스와 같은 인증 원격에 정의할 수 있습니다.

/core-service=management/security-realm=Kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos/keytab=remote\/test-server.elytron.org@ELYTRON.ORG:add(path=path/to/remote-test-server.keytab, debug=true)
/core-service=management/security-realm=Kerberos/authentication=kerberos:add(remove-realm=true)

<management>
  <security-realms>
    ...
    <security-realm name="Kerberos">
      <server-identities>
        <kerberos>
          <keytab principal="remote/test-server.elytron.org@ELYTRON.ORG" path="path/to/remote-test-server.keytab" debug="true"/>
        </kerberos>
      </server-identities>
      <authentication>
        <kerberos remove-realm="true"/>
      </authentication>
    </security-realm>
  </security-realms>
  ...
</management>

Kerberos Remoting SASL 인증에서 Elytron으로 마이그레이션

동등한 Elytron 구성을 정의하는 단계는 Kerberos HTTP 인증 마이그레이션에 설명된 것과 매우 유사합니다.

이렇게 하면 서버 구성 파일의 elytron 하위 시스템에서 다음 구성이 생성됩니다.

<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="KerberosDomain" default-realm="kerberos-properties" permission-mapper="default-permission-mapper">
      <realm name="kerberos-properties" role-decoder="groups-to-roles"/>
    </security-domain>
  </security-domains>
  <security-realms>
   ...
     <properties-realm name="kerberos-properties">
       <users-properties path="kerberos-users.properties" relative-to="kerberos" digest-realm-name="ELYTRON.ORG"/>
       <groups-properties path="kerberos-groups.properties" relative-to="kerberos"/>
     </properties-realm>
   </security-realms>
   <credential-security-factories>
     <kerberos-security-factory name="test-server" principal="remote/test-server.elytron.org@ELYTRON.ORG" path="remote-test-server.keytab" relative-to="kerberos"/>
   </credential-security-factories>
   ...
   <sasl>
     ...
     <sasl-authentication-factory name="gssapi-authentication-factory" sasl-server-factory="elytron" security-domain="KerberosDomain">
       <mechanism-configuration>
         <mechanism mechanism-name="GSSAPI" credential-security-factory="test-server"/>
       </mechanism-configuration>
     </sasl-authentication-factory>
     ...
   </sasl>
 </subsystem>

이제 관리 인터페이스 또는 원격 커넥터를 SASL 인증 팩토리를 참조하도록 업데이트할 수 있습니다.

여기에 정의된 두 개의 Elytron 예제를 결합하여 공유 보안 도메인과 보안 영역을 사용할 수 있으며 프로토콜별 인증 팩토리를 사용하면 각각 자체 Kerberos 보안 팩토리를 참조할 수 있습니다.

이 섹션에서는 여러 ID 저장소를 Elytron 에 사용하는 PicketBox 또는 레거시 보안 영역 구성을 마이그레이션하는 방법에 대해 설명합니다. PicketBox 또는 레거시 보안 영역을 사용하는 경우 권한 부여에 사용되는 정보가 다른 저장소에서 로드되는 동안 인증이 하나의 ID 저장소에 대해 수행되는 구성을 정의할 수 있습니다. Elytron으로 마이그레이션하는 경우 집계 보안 영역을 사용하여 이 목표를 달성할 수 있습니다.

다음 예제에서는 example-users.properties 속성 파일을 사용하여 사용자 인증을 수행한 다음 LDAP를 쿼리하여 그룹 및 역할 정보를 로드합니다.

Picketbox Composite 저장소 구성

이 시나리오의 PicketBox 보안 도메인은 다음 관리 CLI 명령을 사용하여 구성됩니다.

/subsystem=security/security-domain=application-security:add

/subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[ {code=UsersRoles, flag=Required, module-options={ password-stacking=useFirstPass, usersProperties=file://${jboss.server.config.dir}/example-users.properties}} {code=LdapExtended, flag=Required, module-options={ password-stacking=useFirstPass, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.authentication=simple, bindDN="uid=admin,ou=system", bindCredential=secret, baseCtxDN="ou=users,dc=group-to-principal,dc=wildfly,dc=org", baseFilter="(uid={0})", rolesCtxDN="ou=groups,dc=group-to-principal,dc=wildfly,dc=org",roleFilter="(uniqueMember={1})", roleAttributeID="uid" }}])

이렇게 하면 다음과 같은 서버 구성이 생성됩니다.

<security-domain name="application-security">
  <authentication>
    <login-module code="UsersRoles" flag="required">
      <module-option name="password-stacking" value="useFirstPass"/>
      <module-option name="usersProperties" value="file://${jboss.server.config.dir}/example-users.properties"/>
    </login-module>
    <login-module code="LdapExtended" flag="required">
      <module-option name="password-stacking" value="useFirstPass"/>
      <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
      <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
      <module-option name="java.naming.security.authentication" value="simple"/>
      <module-option name="bindDN" value="uid=admin,ou=system"/>
      <module-option name="bindCredential" value="secret"/>
      <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/>
      <module-option name="baseFilter" value="(uid={0})"/>
      <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
      <module-option name="roleFilter" value="(uniqueMember={1})"/>
      <module-option name="roleAttributeID" value="uid"/>
    </login-module>
  </authentication>
</security-domain>

이를 수행하기 위해 ely tron 하위 시스템에서 집계 보안 영역을 구성하는 방법은 Elytron Aggregate Security Realm Configuration 을 참조하십시오.

레거시 보안 Realm Composite 저장소 구성

이 시나리오의 레거시 보안 영역 구성은 다음 관리 CLI 명령을 사용하여 구성됩니다.

/core-service=management/ldap-connection=MyLdapConnection:add(url="ldap://localhost:10389", search-dn="uid=admin,ou=system", search-credential="secret")

/core-service=management/security-realm=ApplicationSecurity:add
/core-service=management/security-realm=ApplicationSecurity/authentication=properties:add(path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true)

batch
/core-service=management/security-realm=ApplicationSecurity/authorization=ldap:add(connection=MyLdapConnection)
/core-service=management/security-realm=ApplicationSecurity/authorization=ldap/username-to-dn=username-filter:add(attribute=uid, base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org")
/core-service=management/security-realm=ApplicationSecurity/authorization=ldap/group-search=group-to-principal:add(base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", iterative=true, prefer-original-connection=true, principal-attribute=uniqueMember, search-by=DISTINGUISHED_NAME, group-name=SIMPLE, group-name-attribute=uid)
run-batch

이렇게 하면 다음과 같은 서버 구성이 생성됩니다.

<security-realms>
  ...
  <security-realm name="ApplicationSecurity">
    <authentication>
      <properties path="example-users.properties" relative-to="jboss.server.config.dir" plain-text="true"/>
    </authentication>
    <authorization>
      <ldap connection="MyLdapConnection">
        <username-to-dn>
          <username-filter base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org" attribute="uid"/>
        </username-to-dn>
        <group-search group-name="SIMPLE" iterative="true" group-name-attribute="uid">
          <group-to-principal search-by="DISTINGUISHED_NAME" base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org" prefer-original-connection="true">
            <membership-filter principal-attribute="uniqueMember"/>
          </group-to-principal>
        </group-search>
      </ldap>
    </authorization>
  </security-realm>
</security-realms>
<outbound-connections>
  <ldap name="MyLdapConnection" url="ldap://localhost:10389" search-dn="uid=admin,ou=system" search-credential="secret"/>
</outbound-connections>

이를 수행하기 위해 ely tron 하위 시스템에서 집계 보안 영역을 구성하는 방법은 Elytron Aggregate Security Realm Configuration 을 참조하십시오.

Elytron Aggregate 보안 영역 구성

이 시나리오에 상응하는 Elytron 구성은 다음 관리 CLI 명령을 사용하여 구성됩니다.

/subsystem=elytron/dir-context=ldap-connection:add(url=ldap://localhost:10389, principal="uid=admin,ou=system", credential-reference={clear-text=secret})

/subsystem=elytron/ldap-realm=ldap-realm:add(dir-context=ldap-connection, direct-verification=true, identity-mapping={search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org", rdn-identifier="uid", attribute-mapping=[{filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org",filter="(uniqueMember={1})",from="uid",to="Roles"}]})

/subsystem=elytron/properties-realm=application-properties:add(users-properties={path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true, digest-realm-name="Application Security"})

/subsystem=elytron/aggregate-realm=combined-realm:add(authentication-realm=application-properties, authorization-realm=ldap-realm)

/subsystem=elytron/security-domain=application-security:add(realms=[{realm=combined-realm}], default-realm=combined-realm, permission-mapper=default-permission-mapper)
/subsystem=elytron/http-authentication-factory=application-security-http:add(http-server-mechanism-factory=global, security-domain=application-security, mechanism-configurations=[{mechanism-name=BASIC}])

이렇게 하면 다음과 같은 서버 구성이 생성됩니다.

<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="application-security" default-realm="combined-realm" permission-mapper="default-permission-mapper">
      <realm name="combined-realm"/>
    </security-domain>
  </security-domains>
  <security-realms>
    <aggregate-realm name="combined-realm" authentication-realm="application-properties" authorization-realm="ldap-realm"/>
      ...
      <properties-realm name="application-properties">
        <users-properties path="example-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="Application Security" plain-text="true"/>
      </properties-realm>
      <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true">
        <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org">
          <attribute-mapping>
            <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
          </attribute-mapping>
        </identity-mapping>
      </ldap-realm>
  </security-realms>
  ...
  <http>
    ...
    <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security">
      <mechanism-configuration>
        <mechanism mechanism-name="BASIC"/>
      </mechanism-configuration>
    </http-authentication-factory>
    ...
  </http>
  ...
  <dir-contexts>
    <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system">
      <credential-reference clear-text="secret"/>
    </dir-context>
  </dir-contexts>
</subsystem>

elytron 하위 시스템에서는 인증에 사용할 보안 영역과 권한 부여 결정에 사용할 을 지정하는 aggregate-realm 이 정의되었습니다.

PicketBox를 사용하는 경우 보안 도메인을 정의하고 액세스를 위한 인메모리 캐싱을 활성화할 수 있습니다. 이를 통해 메모리의 ID 데이터에 액세스하고 ID 저장소에 대한 추가 직접 액세스를 방지할 수 있습니다. Elytron과 유사한 구성을 달성할 수 있습니다. 이 섹션에서는 Elytron을 사용할 때 보안 도메인 캐싱을 구성하는 방법에 대해 설명합니다.

Picketbox 캐시된 보안 도메인 구성

다음 명령은 캐싱을 활성화하는 PicketBox 보안 도메인을 구성하는 방법을 보여줍니다.

/subsystem=security/security-domain=application-security:add(cache-type=default)
/subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[{code=LdapExtended, flag=Required, module-options={ java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.authentication=simple, bindDN="uid=admin,ou=system", bindCredential=secret, baseCtxDN="ou=users,dc=group-to-principal,dc=wildfly,dc=org", baseFilter="(uid={0})", rolesCtxDN="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", roleFilter="(uniqueMember={1})", roleAttributeID="uid" }}])

이렇게 하면 다음과 같은 서버 구성이 생성됩니다.

<subsystem xmlns="urn:jboss:domain:security:2.0">
  <security-domains>
    ...
    <security-domain name="application-security" cache-type="default">
      <authentication>
        <login-module code="LdapExtended" flag="required">
          <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
          <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
          <module-option name="java.naming.security.authentication" value="simple"/>
          <module-option name="bindDN" value="uid=admin,ou=system"/>
          <module-option name="bindCredential" value="secret"/>
          <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/>
          <module-option name="baseFilter" value="(uid={0})"/>
          <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
          <module-option name="roleFilter" value="(uniqueMember={1})"/>
          <module-option name="roleAttributeID" value="uid"/>
        </login-module>
      </authentication>
    </security-domain>
  </security-domains>
</subsystem>

Elytron 캐시된 보안 도메인 구성

Elytron을 사용할 때 보안 도메인을 캐시하는 유사한 구성을 생성하려면 아래 단계를 수행하십시오.

이러한 명령을 실행하면 다음과 같은 서버 구성이 추가됩니다.

<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="application-security" default-realm="cached-ldap" permission-mapper="default-permission-mapper">
      <realm name="cached-ldap"/>
    </security-domain>
  </security-domains>
  ...
  <security-realms>
    ....
  <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true">
      <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org">
        <attribute-mapping>
          <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
        </attribute-mapping>
      </identity-mapping>
    </ldap-realm>
    <caching-realm name="cached-ldap" realm="ldap-realm"/>
  </security-realms>
  ...
  <http>
    ...
    <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security">
      <mechanism-configuration>
        <mechanism mechanism-name="BASIC"/>
      </mechanism-configuration>
    </http-authentication-factory>
    ...
  </http>
   ...
  <dir-contexts>
    <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system">
      <credential-reference clear-text="secret"/>
    </dir-context>
  </dir-contexts>
  ...

기본적으로 JBoss EAP는 레거시 보안 하위 시스템을 사용하여 Jakarta Authorization 정책 프로바이더 및 팩토리를 구성합니다. 기본 구성은 PicketBox의 구현으로 매핑됩니다.

elytron 하위 시스템은 Jakarta Authorization 사양에 따라 기본 제공 정책 프로바이더를 제공합니다. Elytron이 Jakarta Authorization 구성 및 기타 정책을 관리하도록 서버를 구성하기 전에 먼저 다음 관리 CLI 명령을 사용하여 레거시 보안 하위 시스템에서 Jakarta Authorization을 비활성화해야 합니다.

/subsystem=security:write-attribute(name=initialize-jacc, value=false)

이렇게 하지 않으면 서버 로그에 다음과 같은 오류가 발생할 수 있습니다. MSC000004: org.wildfly.security.policy 서비스 중지 중에 오류가 발생했습니다: java.lang.StackOverflowError.

Jakarta Authorization을 활성화하고 elytron 하위 시스템에서 Jakarta Authorization 정책 공급자를 정의하는 방법에 대한 자세한 내용은 JBoss EAP의 개발 가이드에서 elytron 하위 시스템을 사용하여 Jakarta Authorization 활성화 를 참조하십시오.

이 섹션에서는 org.jboss.naming.remote.client.InitialContext 클래스에서 지원하는 org.jboss.naming.remote.client.InitialContext 클래스에서 Elytron으로 지원하는 org.jboss.naming.client.InitialContextFactory 클래스에서 지원하는 클라이언트 애플리케이션을 마이그레이션하는 방법을 설명합니다.

다음 예제에서는 InitialContextFactory 클래스가 사용자 자격 증명의 속성을 지정하고 해당 ID가 연결되는 이름 지정 프로바이더의 URL에 대해 생성한다고 가정합니다.

Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
properties.put(Context.PROVIDER_URL,"http-remoting://127.0.0.1:8080");
properties.put(Context.SECURITY_PRINCIPAL, "bob");
properties.put(Context.SECURITY_CREDENTIALS, "secret");
InitialContext context = new InitialContext(properties);
Bar bar = (Bar) context.lookup("foo/bar");
...

다음 마이그레이션 방법 중 하나를 선택할 수 있습니다.

// Create the authentication configuration
AuthenticationConfiguration namingConfig = AuthenticationConfiguration.empty().useName("bob").usePassword("secret");

// Create the authentication context
AuthenticationContext context = AuthenticationContext.empty().with(MatchRule.ALL.matchHost("127.0.0.1"), namingConfig);

// Create a callable that creates and uses an InitialContext
Callable<Void> callable = () -> {
    Properties properties = new Properties();
    properties.put(Context.INITIAL_CONTEXT_FACTORY,"org.wildfly.naming.client.WildFlyInitialContextFactory");
    properties.put(Context.PROVIDER_URL,"remote+http://127.0.0.1:8080");
    InitialContext context = new InitialContext(properties);
    Bar bar = (Bar) context.lookup("foo/bar");
    ...
    return null;
};

// Use the authentication context to run the callable
context.runCallable(callable);

이 마이그레이션 예제에서는 클라이언트 애플리케이션이 jboss-ejb-client.properties 파일을 사용하여 원격 서버에 배포된 Jakarta Enterprise Beans를 호출하도록 구성되어 있다고 가정합니다. 클라이언트 애플리케이션 META-INF/ 디렉터리에 있는 이 파일에는 원격 서버에 연결하는 데 필요한 다음 정보가 포함되어 있습니다.

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=127.0.0.1
remote.connection.default.port = 8080
remote.connection.default.username=bob
remote.connection.default.password=secret

클라이언트는 Jakarta Enterprise Beans를 조회하고 다음 예제와 유사한 코드를 사용하여 해당 방법 중 하나를 호출합니다.

// Create an InitialContext
Properties properties = new Properties();
properties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
InitialContext context = new InitialContext(properties);

// Look up the {JEB} and invoke one of its methods
RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
    "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName());
int sum = statelessRemoteCalculator.add(101, 202);

다음 마이그레이션 방법 중 하나를 선택할 수 있습니다.

// Create the authentication configuration
AuthenticationConfiguration ejbConfig = AuthenticationConfiguration.empty().useName("bob").usePassword("secret");

// Create the authentication context
AuthenticationContext context = AuthenticationContext.empty().with(MatchRule.ALL.matchHost("127.0.0.1"), ejbConfig);

// Create a callable that invokes the {JEB}
Callable<Void> callable = () -> {

    // Create an InitialContext
    Properties properties = new Properties();
    properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
    properties.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080");
    InitialContext context = new InitialContext(properties);

    // Look up the {JEB} and invoke one of its methods
    // Note that this code is the same as before
    RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
        "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName());
    int sum = statelessRemoteCalculator.add(101, 202);
    ...
    return null;
};

// Use the authentication context to run the callable
context.runCallable(callable);

보안 영역을 사용하여 JBoss EAP 서버에 대한 HTTP 연결을 보호한 경우 이 섹션에 제공된 정보를 사용하여 해당 구성을 Elytron으로 마이그레이션할 수 있습니다.

다음 예제에서는 security-realm 에 구성된 다음 키 저장소가 있다고 가정합니다.

<security-realm name="ApplicationRealm">
  <server-identities>
    <ssl>
      <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="keystore_password" alias="server" key-password="key_password" />
    </ssl>
  </server-identities>
</security-realm>

Elytron을 사용하여 동일한 구성을 수행하려면 아래 단계를 따르십시오.

이렇게 하면 서버 구성 파일에 다음과 같은 elytron 하위 시스템 구성이 생성됩니다.

<subsystem xmlns="urn:wildfly:elytron:4.0" ...>
  ...
  <tls>
    <key-stores>
      <key-store name="LocalhostKeyStore">
        <credential-reference clear-text="keystore_password"/>
        <implementation type="JKS"/>
        <file path="server.keystore" relative-to="jboss.server.config.dir"/>
      </key-store>
    </key-stores>
    <key-managers>
      <key-manager name="LocalhostKeyManager" key-store="LocalhostKeyStore"  alias-filter="server">
        <credential-reference clear-text="key_password"/>
      </key-manager>
    </key-managers>
    <server-ssl-contexts>
      <server-ssl-context name="LocalhostSslContext" key-manager="LocalhostKeyManager"/>
    </server-ssl-contexts>
  </tls>
</subsystem>

이렇게 하면 서버 구성 파일에서 다음 undertow 하위 시스템 구성이 생성됩니다.

<https-listener name="https" socket-binding="https" ssl-context="LocalhostSslContext" enable-http2="true"/>

자세한 내용은 Elytron Subsystem 및 JBoss EAP용 서버 보안 구성 방법에서 관리 인터페이스 보안 설정 방법을 참조하십시오.

CLIENT-CERT SSL 인증을 활성화하려면 인증 요소에 truststore 요소를 추가합니다.

<security-realm name="ManagementRealm">
  <server-identities>
    <ssl>
      <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="KEYSTORE_PASSWORD" alias="server" key-password="key_password" />
    </ssl>
  </server-identities>
  <authentication>
    <truststore path="server.truststore" relative-to="jboss.server.config.dir" keystore-password="TRUSTSTORE_PASSWORD" />
    <local default-user="$local"/>
    <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
  </authentication>
</security-realm>

레거시 신뢰 저장소 는 다음 두 가지 방법으로 사용할 수 있습니다.

CA만 포함하는 기존 신뢰 저장소

다음 단계에 따라 유효한 인증서 및 개인 키가 없는 사용자가 Elytron을 사용하여 서버에 액세스하지 못하도록 서버를 구성합니다.

이렇게 하면 서버 구성 파일에 다음과 같은 elytron 하위 시스템 구성이 생성됩니다.

<subsystem xmlns="urn:wildfly:elytron:4.0"...>
  ...
  <tls>
    <key-stores>
      <key-store name="LocalhostKeyStore">
        <credential-reference clear-text="keystore_password"/>
        <implementation type="JKS"/>
        <file path="server.keystore" relative-to="jboss.server.config.dir"/>
      </key-store>
      <key-store name="TrustStore">
        <credential-reference clear-text="truststore_password"/>
        <implementation type="JKS"/>
        <file path="server.truststore" relative-to="jboss.server.config.dir"/>
      </key-store>
    </key-stores>
    <key-managers>
      <key-manager name="LocalhostKeyManager" key-store="LocalhostKeyStore" alias-filter="server">
        <credential-reference clear-text="key_password"/>
      </key-manager>
    </key-managers>
    <trust-managers>
      <trust-manager name="TrustManager" key-store="TrustStore"/>
    </trust-managers>
    <server-ssl-contexts>
      <server-ssl-context name="LocalhostSslContext" need-client-auth="true" key-manager="LocalhostKeyManager" trust-manager="TrustManager"/>
    </server-ssl-contexts>
  </tls>
</subsystem>

이렇게 하면 서버 구성 파일에서 다음 undertow 하위 시스템 구성이 생성됩니다.

<subsystem xmlns="urn:jboss:domain:undertow:10.0">
...
<https-listener name="https" socket-binding="https" ssl-context="LocalhostSslContext" enable-http2="true"/>
...
</subsystem>

영역 및 도메인

사전 정의된 Elytron ManagementDomain 보안 도메인 및 ManagementRealm 보안 영역을 사용할 수 있도록 사용자는 표준 속성 파일에 저장됩니다.

<security-domains>
    <security-domain name="ManagementDomain" default-realm="ManagementRealm" permission-mapper="default-permission-mapper">
        <realm name="ManagementRealm" role-decoder="groups-to-roles"/>
        <realm name="local"/>
    </security-domain>
</security-domains>
<security-realms>
    <properties-realm name="ManagementRealm">
        <users-properties path="mgmt-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="ManagementRealm"/>
        <groups-properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
    </properties-realm>
</security-realms>

보안 영역은 다음 두 가지 상황에서 사용됩니다.

따라서 모든 클라이언트 인증서의 경우 사용자가 보안 영역에 있어야 합니다.

Princder

인증서 인증을 사용하고 보안 영역에서 ID를 확인하기 위해 사용자 이름을 허용하는 경우 클라이언트 인증서에서 사용자 이름을 가져올 수 있는 정의된 방법이 있어야 합니다.

이 경우 인증서 제목에서 CN 속성이 사용됩니다.

/subsystem=elytron/x500-attribute-principal-decoder=x500-decoder:add(attribute-name=CN)

HTTP 인증 팩토리

HTTP 연결의 경우 이전에 정의된 리소스를 사용하여 HTTP 인증 팩토리가 정의됩니다. CLIENT_CERT 및 DIGEST 인증을 지원하도록 구성됩니다.

properties 영역에서 암호만 확인하고 클라이언트 인증서를 확인할 수 없으므로 먼저 구성 메커니즘 팩토리를 추가해야 합니다. 그러면 보안 영역에 대한 인증서 확인을 비활성화합니다.

/subsystem=elytron/configurable-http-server-mechanism-factory=configured-cert:add(http-server-mechanism-factory=global, properties={org.wildfly.security.http.skip-certificate-verification=true})

HTTP 인증은 다음과 같이 생성할 수 있습니다.

./subsystem=elytron/http-authentication-factory=client-cert-digest:add(http-server-mechanism-factory=configured-cert,security-domain=ManagementDomain,mechanism-configurations=[{mechanism-name=CLIENT_CERT,pre-realm-principal-transformer=x500-decoder},{mechanism-name=DIGEST, mechanism-realm-configurations=[{realm-name=ManagementRealm}]}])

위의 명령은 다음과 같습니다.

<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <http>
    ...
    <http-authentication-factory name="client-cert-digest" http-server-mechanism-factory="configured-cert" security-domain="ManagementDomain">
      <mechanism-configuration>
        <mechanism mechanism-name="CLIENT_CERT" pre-realm-principal-transformer="x500-decoder"/>
        <mechanism mechanism-name="DIGEST">
          <mechanism-realm realm-name="ManagementRealm"/>
        </mechanism>
      </mechanism-configuration>
    </http-authentication-factory>
    ...
    <configurable-http-server-mechanism-factory name="configured-cert" http-server-mechanism-factory="configured-cert">
        <properties>
            <property name="org.wildfly.security.http.skip-certificate-verification" value="true"/>
        </properties>
    </configurable-http-server-mechanism-factory>
    ...
  </http>
  ...
</subsystem>