AEM의 폐쇄형 사용자 그룹 closed-user-groups-in-aem

소개 introduction

AEM 6.3 이후, 기존 구현에 존재하는 성능, 확장성 및 보안 문제를 해결하기 위한 새로운 폐쇄형 사용자 그룹 구현이 있습니다.

새 구현의 목표는 이전 버전의 문제와 디자인 제한 사항을 해결하면서 필요한 기존 기능을 다루는 것입니다. 그 결과 다음과 같은 특성을 가진 새로운 CUG 설계가 이루어졌습니다.

새로운 사용자 지정 사용자 그룹 구현 the-new-custom-user-group-implementation

AEM의 컨텍스트에서 알려진 CUG는 다음 단계로 구성됩니다.

새로운 구현은 인증과 권한 부여 요소 사이에 선을 긋도록 설계되었습니다. AEM 6.3부터는 인증 요구 사항을 명시적으로 추가하지 않고 읽기 액세스를 제한할 수 있습니다. 예를 들어, 지정된 인스턴스가 인증을 모두 필요로 하거나 지정된 트리가 이미 인증을 필요로 하는 하위 트리에 있는 경우.

마찬가지로, 주어진 트리는 유효 권한 설정을 변경하지 않고 인증 요구 사항으로 표시될 수 있습니다. 조합 및 결과는 CUG 정책 및 인증 요구 사항 결합 섹션에 나와 있습니다.

개요 overview

인증: 읽기 액세스 제한 authorization-restricting-read-access

CUG의 주요 기능은 선택된 주도자를 제외한 모든 사용자에 대해 컨텐츠 저장소의 특정 트리에 대한 읽기 액세스를 제한하는 것입니다. 새로운 구현에서는 즉시 기본 액세스 제어 콘텐츠를 조작하는 대신 CUG를 나타내는 전용 유형의 액세스 제어 정책을 정의하여 다른 접근 방식을 사용합니다.

CUG에 대한 액세스 제어 정책 access-control-policy-for-cug

이 새로운 유형의 정책에는 다음과 같은 특성이 있습니다.

또한 CUG를 나타내는 데 사용되는 PrincipalSetPolicy 구현은 다음을 정의합니다.

이러한 CUG 정책은 oak-authorization-cug라는 별도의 인증 모듈을 통해 AEM 인스턴스에 배포됩니다. 이 모듈에는 자체 액세스 제어 관리 및 권한 평가가 함께 제공됩니다. 즉, 기본 AEM 설정에서는 여러 인증 메커니즘을 결합하는 Oak 콘텐츠 저장소 구성을 제공합니다. 자세한 내용은 Apache Oak 설명서의 이 페이지를 참조하십시오.

이 복합 설정에서 새 CUG는 대상 노드에 연결된 기존 액세스 제어 콘텐츠를 대체하지 않습니다. 대신 원래 액세스 제어에 영향을 주지 않고 나중에 제거할 수도 있는 보충 자료로, 기본적으로 AEM의 액세스 제어 목록이 됩니다.

전자의 구현과 달리 새로운 CUG 정책은 항상 접근 제어 콘텐츠로 인식되고 취급된다. 이는 JCR 액세스 제어 관리 API를 사용하여 만들고 편집함을 의미합니다. 자세한 내용은 CUG 정책 관리 섹션을 참조하십시오.

CUG 정책의 권한 평가 permission-evaluation-of-cug-policies

CUG에 대한 전용 액세스 제어 관리 외에도 새로운 인증 모델을 사용하면 정책에 대한 권한 평가를 조건부로 활성화할 수 있습니다. 이렇게 하면 스테이징 환경에서 CUG 정책을 설정할 수 있으며, 프로덕션 환경에 복제되는 경우에만 유효 권한을 평가할 수 있습니다.

CUG 정책 및 기본 또는 추가 인증 모델과의 상호 작용에 대한 권한 평가는 Apache Jackrabbit Oak의 여러 인증 메커니즘에 대해 설계된 패턴을 따릅니다. 즉, 모든 모델이 액세스 권한을 부여하는 경우에만 주어진 권한 세트가 부여됩니다. 자세한 내용은 Jackrabbit Oak 설명서를 참조하세요.

CUG 정책을 처리하고 평가하기 위해 설계된 권한 모델과 연관된 권한 평가에는 다음과 같은 특성이 적용됩니다.

허가 평가에 따른 단일 CUG 정책의 효과는 다음과 같이 요약할 수 있다.

모범 사례 best-practices

다음 모범 사례는 CUG를 통한 제한된 읽기 액세스를 정의하는 데 설명되어야 합니다.

인증: 인증 요구 사항 정의 authentication-defining-the-auth-requirement

CUG 기능의 인증 관련 부분을 사용하면 인증이 필요한 트리를 표시하고 선택적으로 전용 로그인 페이지를 지정할 수 있습니다. 이전 버전에 따라 새 구현을 사용하면 콘텐츠 저장소에서 인증이 필요한 트리를 표시할 수 있습니다. 또한 요구 사항을 적용하고 로그인 리소스로 리디렉션하는 Sling org.apache.sling.api.auth.Authenticator을(를) 사용하여 조건부로 동기화할 수 있습니다.

이러한 요구 사항은 sling.auth.requirements 등록 속성을 제공하는 OSGi 서비스를 통해 인증자에 등록됩니다. 그런 다음 이러한 속성을 사용하여 인증 요구 사항을 동적으로 확장합니다. 자세한 내용은 Sling 설명서를 참조하세요.

전용 Mixin 유형을 사용하여 인증 요구 사항 정의 defining-the-authentication-requirement-with-a-dedicated-mixin-type

보안상의 이유로 새 구현은 로그인 경로 granite:loginPath에 대해 STRING 형식의 단일 선택적 속성을 정의하는 granite:AuthenticationRequired(이)라는 전용 mixin 형식으로 잔여 JCR 속성의 사용을 대체합니다. 이 mixin 유형과 관련된 콘텐츠 변경 사항만 Apache Sling Authenticator에 등록된 요구 사항을 업데이트하게 됩니다. 일시적인 수정 사항이 지속되면 수정 사항이 추적되므로 javax.jcr.Session.save() 호출이 유효해야 합니다.

granite:loginPath 속성에도 동일하게 적용됩니다. 인증 요구 사항 관련 mixin 유형에 의해 정의되는 경우에만 존중됩니다. 구조화되지 않은 JCR 노드에서 이 이름을 가진 잔여 속성을 추가해도 원하는 효과가 표시되지 않으며 속성은 OSGi 등록 갱신을 담당하는 핸들러에서 무시됩니다.

Sling 인증자에 인증 요구 사항 및 로그인 경로 등록 registering-the-authentication-requirement-and-login-path-with-the-sling-authenticator

이 유형의 인증 요구 사항은 특정 실행 모드 및 컨텐츠 리포지토리 내의 작은 트리 하위 집합으로 제한될 것으로 예상되므로 요구 사항 mixin 유형 및 로그인 경로 등록 정보의 추적은 조건부입니다. 지원되는 경로를 정의하는 해당 구성에 바인딩됩니다(아래 구성 옵션 참조). 따라서 이러한 지원되는 경로 범위 내의 변경 사항만 OSGi 등록 업데이트를 트리거하고, 다른 곳에서는 mixin 유형과 속성이 모두 무시됩니다.

이제 기본 AEM 설정은 작성자 실행 모드에서 mixin을 설정할 수 있도록 하여 이 구성을 활용하지만 게시 인스턴스에 복제할 때만 영향을 줍니다. Sling이 인증 요구 사항을 적용하는 방법에 대한 자세한 내용은 Sling 인증 - 프레임워크 설명서를 참조하십시오.

구성된 지원 경로 내에 granite:AuthenticationRequired mixin 유형을 추가하면 담당 처리기의 OSGi 등록이 sling.auth.requirements 속성을 사용하는 새로운 추가 항목을 포함하여 업데이트됩니다. 지정된 인증 요구 사항이 선택적 granite:loginPath 속성을 지정하는 경우 값이 인증 요구 사항에서 제외할 '-' 접두사가 있는 인증자에 등록되기도 합니다.

인증 요구 사항의 평가 및 상속 evaluation-and-inheritance-of-the-authentication-requirement

Apache Sling 인증 요구 사항은 페이지 또는 노드 계층 구조를 통해 상속됩니다. 상속의 세부 사항과 순서 및 우선 순위 등 인증 요구 사항에 대한 평가는 구현 세부 사항으로 간주되며 이 문서에 문서화되지 않습니다.

로그인 경로 평가 evaluation-of-login-path

인증 시 로그인 경로와 해당 리소스에 대한 리디렉션 평가는 기본적으로 AEM으로 구성된 Apache Sling AuthenticationHandler인 Adobe Granite 로그인 선택기 인증 처리기(com.day.cq.auth.impl.LoginSelectorHandler)의 구현 세부 사항입니다.

AuthenticationHandler.requestCredentials을(를) 호출하면 이 처리기는 사용자가 리디렉션되는 매핑 로그인 페이지를 확인하려고 시도합니다. 여기에는 다음 단계가 포함됩니다.

이 설명서의 대상은 내부 LoginPathProvider 인터페이스에 의해 노출된 로그인 경로를 평가하는 것입니다. AEM 6.3 이후 제공된 구현은 다음과 같이 작동합니다.

Granite의 새로운 인증 요구 사항 지원에 의해 구현된 LoginPathProvider은(는) granite:loginPath 속성으로 정의된 로그인 경로를 노출하며, 이는 위에서 설명한 대로 mixin 유형으로 정의됩니다. 로그인 경로를 포함하는 리소스 경로와 속성 값 자체의 매핑은 메모리에 유지되며 계층의 다른 노드에 적합한 로그인 경로를 찾는 것으로 평가됩니다.

모범 사례 best-practices-1

인증 요구 사항을 정의할 때 다음 모범 사례를 고려해야 합니다.

저장소에서의 표시 representation-in-the-repository

저장소의 CUG 정책 표시 cug-policy-representation-in-the-repository

Oak 설명서는 새로운 CUG 정책이 저장소 콘텐츠에 반영되는 방식을 다룹니다. 자세한 내용은 CUG를 사용한 액세스 관리에 대한 Jackrabbit Oak 설명서를 참조하세요.

저장소의 인증 요구 사항 authentication-requirement-in-the-repository

별도의 인증 요구 사항이 필요한 경우 대상 노드에 배치된 전용 mixin 노드 유형을 사용하는 저장소 콘텐츠에 반영됩니다. mixin 유형은 대상 노드가 정의한 트리에 대한 전용 로그인 페이지를 지정하는 선택적 속성을 정의합니다.

로그인 경로와 연관된 페이지는 해당 트리의 내부 또는 외부에 위치할 수 있다. 인증 요구 사항에서 제외됩니다.

[granite:AuthenticationRequired]
      mixin
      - granite:loginPath (STRING)

CUG 정책 및 인증 요구 사항 관리 managing-cug-policies-and-authentication-requirement

CUG 정책 관리 managing-cug-policies

CUG에 대한 읽기 액세스를 제한하는 새로운 유형의 액세스 제어 정책은 JCR 액세스 제어 관리 API를 사용하여 관리되며 JCR 2.0 사양에 설명된 메커니즘을 따릅니다.

새 CUG 정책 설정 set-a-new-cug-policy

이전에 CUG가 설정되지 않은 노드에서 새 CUG 정책을 적용하기 위한 코드입니다. getApplicablePolicies은(는) 이전에 설정되지 않은 새 정책만 반환합니다. 마지막으로 정책을 다시 작성해야 하며 변경 사항은 지속되어야 합니다.

String path = [...] // needs to be a supported, absolute path

Principal toAdd1 = [...]
Principal toAdd2 = [...]
Principal toRemove = [...]

AccessControlManager acMgr = session.getAccessControlManager();
PrincipalSetPolicy cugPolicy = null;

AccessControlPolicyIterator it = acMgr.getApplicablePolicies(path);
while (it.hasNext()) {
        AccessControlPolicy policy = it.nextAccessControlPolicy();
        if (policy instanceof PrincipalSetPolicy) {
           cugPolicy = (PrincipalSetPolicy) policy;
           break;
        }
}

if (cugPolicy == null) {
   log.debug("no applicable policy"); // path not supported or no applicable policy (for example,
                                                   // the policy was set before)
   return;
}

cugPolicy.addPrincipals(toAdd1, toAdd2);
cugPolicy.removePrincipals(toRemove));

acMgr.setPolicy(path, cugPolicy); // as of this step the policy can be edited/removed
session.save();

기존 CUG 정책 편집 edit-an-existing-cug-policy

기존 CUG 정책을 편집하려면 다음 단계를 수행해야 합니다. 수정된 정책은 다시 기록해야 하며 변경 사항은 javax.jcr.Session.save()을(를) 사용하여 지속되어야 합니다.

String path = [...] // needs to be a supported, absolute path

Principal toAdd1 = [...]
Principal toAdd2 = [...]
Principal toRemove = [...]

AccessControlManager acMgr = session.getAccessControlManager();
PrincipalSetPolicy cugPolicy = null;

for (AccessControlPolicy policy : acMgr.getPolicies(path)) {
     if (policy instanceof PrincipalSetPolicy) {
        cugPolicy = (PrincipalSetPolicy) policy;
        break;
     }
}

if (cugPolicy == null) {
   log.debug("no policy to edit"); // path not supported or policy not set before
   return;
}

if (cugPolicy.addPrincipals(toAdd1, toAdd2) || cugPolicy.removePrincipals(toRemove)) {
   acMgr.setPolicy(path, cugPolicy);
   session.save();
} else {
     log.debug("cug policy not modified");
}

효과적인 CUG 정책 검색 retrieve-effective-cug-policies

JCR 액세스 제어 관리는 지정된 경로에서 적용되는 정책을 검색하기 위한 최선의 방법을 정의합니다. CUG 정책의 평가는 조건부이며 사용하도록 설정하는 해당 구성에 따라 다르므로 getEffectivePolicies을(를) 호출하는 것이 특정 CUG 정책이 특정 설치에서 적용되는지 확인하는 편리한 방법입니다.

String path = [...] // needs to be a supported, absolute path

AccessControlManager acMgr = session.getAccessControlManager();
PrincipalSetPolicy cugPolicy = null;

// log an debug message of all CUG policies that take effect at the given path
// there could be zero, one or many (creating nested CUGs is possible)
for (AccessControlPolicy policy : acMgr.getEffectivePolicies(path) {
     if (policy instanceof PrincipalSetPolicy) {
        String policyPath = "-";
        if (policy instanceof JackrabbitAccessControlPolicy) {
           policyPath = ((JackrabbitAccessControlPolicy) policy).getPath();
        }
        log.debug("Found effective CUG for path '{}' at '{}', path, policyPath);
     }
}

상속된 CUG 정책 검색 retrieve-inherited-cug-policies

적용 여부에 관계없이 주어진 경로에 정의된 모든 중첩 CUG 찾기 자세한 내용은 구성 옵션 섹션을 참조하십시오.

String path = [...]

List<AccessControlPolicy> cugPolicies = new ArrayList<AccessControlPolicy>();
while (isSupportedPath(path)) {
     for (AccessControlPolicy policy : acMgr.getPolicies(path)) {
         if (policy instanceof PrincipalSetPolicy) {
            cugPolicies.add(policy);
         }
      }
      path = (PathUtils.denotesRoot(path)) ? null : PathUtils.getAncestorPath(path, 1);
}

주도자별 CUG 정책 관리 managing-cug-policies-by-pincipal

보안 주체별로 액세스 제어 정책을 편집할 수 있도록 해 주는 JackrabbitAccessControlManager에 의해 정의된 확장은 CUG 액세스 제어 관리를 사용하여 구현되지 않습니다. CUG 정책은 항상 모든 보안 주체에 영향을 미칩니다. PrincipalSetPolicy에 나열된 보안 주체는 읽기 액세스 권한을 부여 받고 다른 모든 보안 주체는 대상 노드에 의해 정의된 트리의 콘텐츠를 읽을 수 없습니다.

해당 메서드는 항상 빈 정책 배열을 반환하지만 예외를 throw하지 않습니다.

인증 요구 사항 관리 managing-the-authentication-requirement

대상 노드의 유효 노드 유형을 변경하여 새 인증 요구 사항을 생성, 수정 또는 제거합니다. 그런 다음 일반 JCR API를 사용하여 선택적 로그인 경로 속성을 작성할 수 있습니다.

새 인증 요구 사항 추가 adding-a-new-auth-requirement

인증 요구 사항을 만드는 단계는 아래에 자세히 설명되어 있습니다. 대상 노드가 포함된 트리에 대해 RequirementHandler이(가) 구성된 경우에만 요구 사항이 Apache Sling 인증자에 등록됩니다.

Node targetNode = [...]

targetNode.addMixin("granite:AuthenticationRequired");
session.save();

로그인 경로로 새 인증 요구 사항 추가 add-a-new-auth-requirement-with-login-path

로그인 경로를 포함한 인증 요구 사항을 만드는 단계입니다. 대상 노드가 포함된 트리에 대해 RequirementHandler이(가) 구성된 경우에만 로그인 경로에 대한 요구 사항과 제외가 Apache Sling 인증자에 등록됩니다.

Node targetNode = [...]
String loginPath = [...] // STRING property

Node targetNode = session.getNode(path);
targetNode.addMixin("granite:AuthenticationRequired");

targetNode.setProperty("granite:loginPath", loginPath);
session.save();

기존 로그인 경로 수정 modify-an-existing-login-path

기존 로그인 경로를 변경하는 단계는 아래에 자세히 설명되어 있습니다. 대상 노드가 포함된 트리에 대해 RequirementHandler이(가) 구성된 경우에만 수정 내용이 Apache Sling 인증자에 등록됩니다. 이전 로그인 경로 값이 등록에서 제거됩니다. 대상 노드와 연결된 인증 요구 사항은 이 수정 사항의 영향을 받지 않습니다.

Node targetNode = [...]
String newLoginPath = [...] // STRING property

if (targetNode.isNodeType("granite:AuthenticationRequired")) {
   targetNode.setProperty("granite:loginPath", newLoginPath);
   session.save();
} else {
     log.debug("cannot modify login path property; mixin type missing");
}

기존 로그인 경로 제거 remove-an-existing-login-path

기존 로그인 경로를 제거하는 절차. 대상 노드가 포함된 트리에 대해 RequirementHandler이(가) 구성된 경우에만 Apache Sling 인증자에서 로그인 경로 항목의 등록이 취소됩니다. 대상 노드와 연결된 인증 요구 사항은 영향을 받지 않습니다.

Node targetNode = [...]

if (targetNode.hasProperty("granite:loginPath") &&
   targetNode.isNodeType("granite:AuthenticationRequired")) {
   targetNode.setProperty("granite:loginPath", null);
   session.save();
} else {
     log.debug("cannot remove login path property; mixin type missing");
}

또는 동일한 목적을 달성하기 위해 아래 방법을 사용할 수 있습니다.

String path = [...] // absolute path to target node

String propertyPath = PathUtils.concat(path, "granite:loginPath");
if (session.propertyExists(propertyPath)) {
    session.getProperty(propertyPath).remove();
    // or: session.removeItem(propertyPath);
    session.save();
}

인증 요구 사항 제거 remove-an-auth-requirement

기존 인증 요구 사항을 제거하는 절차. 대상 노드가 포함된 트리에 대해 RequirementHandler이(가) 구성된 경우에만 Apache Sling 인증자에서 요구 사항이 등록 취소됩니다.

Node targetNode = [...]
targetNode.removeMixin("granite:AuthenticationRequired");

session.save();

유효한 인증 요구 사항 검색 retrieve-effective-auth-requirements

Apache Sling Authenticator에 등록된 모든 유효 인증 요구 사항을 읽을 수 있는 전용 공개 API는 없습니다. 그러나 이 목록은 https://<serveraddress>:<serverport>/system/console/slingauth의 시스템 콘솔에서 "인증 요구 사항 구성" 섹션 아래에 표시됩니다.

다음 이미지는 데모 콘텐츠가 있는 AEM 게시 인스턴스의 인증 요구 사항을 보여줍니다. 커뮤니티 페이지의 강조 표시된 경로는 이 문서에 설명된 구현에서 추가한 요구 사항이 Apache Sling 인증자에 어떻게 반영되는지 보여줍니다.

유효한 로그인 경로 검색 retrieve-the-effective-login-path

현재 인증이 필요한 리소스에 익명으로 액세스할 때 적용되는 로그인 경로를 검색할 공개 API가 없습니다. 로그인 경로를 검색하는 방법에 대한 자세한 내용은 로그인 경로 평가 섹션을 참조하십시오.

그러나 이 기능으로 정의된 로그인 경로 외에도 로그인으로 리디렉션을 지정하는 대체 방법이 있습니다. 이는 지정된 AEM 설치의 콘텐츠 모델 및 인증 요구 사항을 디자인할 때 고려해야 합니다.

상속된 인증 요구 사항 검색 retrieve-the-inherited-auth-requirement

로그인 경로와 마찬가지로 콘텐츠에 정의된 상속된 인증 요구 사항을 검색하는 공개 API는 없습니다. 다음 예제에서는 적용 여부에 관계없이 주어진 계층으로 정의된 모든 인증 요구 사항을 나열하는 방법을 보여줍니다. 자세한 내용은 구성 옵션을 참조하세요.

String path = [...]
Node node = session.getNode(path);

Map<String, String> authRequirements = new ArrayList<String, String>();
while (isSupported(node)) {
     if (node.isNodeType("granite:AuthenticationRequired")) {
         String loginPath = (node.hasProperty("granite:loginPath") ?
                                     node.getProperty("granite:loginPath").getString() :
                                     "";
        authRequirements.put(node.getPath(), loginPath);
        node = node.getParent();
     }
}

CUG 정책 및 인증 요구 사항 결합 combining-cug-policies-and-the-authentication-requirement

다음 표에는 구성을 통해 두 모듈을 모두 활성화한 AEM 인스턴스의 유효한 CUG 정책 조합과 인증 요구 사항이 나와 있습니다.

OSGi 구성 요소 및 구성 osgi-components-and-configuration

이 섹션에서는 OSGi 구성 요소 및 새로운 CUG 구현과 함께 도입된 개별 구성 옵션에 대한 개요를 제공합니다.

이전 구현과 새 구현 간의 구성 옵션에 대한 포괄적인 매핑은 CUG 매핑 설명서 를 참조하십시오.

인증: 설정 및 구성 authorization-setup-and-configuration

새로운 인증 관련 부분이 AEM 기본 설치의 일부인 Oak CUG 인증 번들(org.apache.jackrabbit.oak-authorization-cug)에 포함되어 있습니다. 번들은 읽기 액세스를 관리하기 위한 추가 방법으로 배포되는 것을 목표로 하는 분리된 인증 모델을 정의한다.

CUG 인증 설정 setting-up-cug-authorization

CUG 권한 설정에 대해서는 관련 Apache 설명서에 자세히 설명되어 있습니다. 기본적으로 AEM에는 모든 실행 모드에서 배포된 CUG 인증이 있습니다. 다른 인증 설정이 필요한 설치에서 CUG 인증을 비활성화하는 데 단계별 지침을 사용할 수도 있습니다.

레퍼러 필터 구성 configuring-the-referrer-filter

또한 CDN, 로드 밸런서 등을 통해 AEM에 액세스하는 데 사용할 수 있는 모든 호스트 이름으로 Sling 레퍼러 필터를 구성해야 합니다.

레퍼러 필터가 구성되지 않은 경우 사용자가 CUG 사이트에 로그인하려고 하면 다음과 유사한 오류가 표시됩니다.

31.01.2017 13:49:42.321 *INFO* [qtp1263731568-346] org.apache.sling.security.impl.ReferrerFilter Rejected referrer header for POST request to /libs/granite/core/content/login.html/j_security_check : https://hostname/libs/granite/core/content/login.html?resource=%2Fcontent%2Fgeometrixx%2Fen%2Ftest-site%2Ftest-page.html&$$login$$=%24%24login%24%24&j_reason=unknown&j_reason_code=unknown

OSGi 구성 요소의 특성 characteristics-of-osgi-components

인증 요구 사항을 정의하고 전용 로그인 경로를 지정하기 위해 다음 두 가지 OSGi 구성 요소가 도입되었습니다.

org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugConfiguration

org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugExcludeImpl

구성 옵션 configuration-options

주요 구성 옵션은 다음과 같습니다.

CUG 인증 모듈과 연결된 사용 가능한 구성 옵션은 Apache Oak 설명서에 자세히 나열되고 설명되어 있습니다.

CUG 평가에서 주도자 제외 excluding-principals-from-cug-evaluation

개별 학교장은 CUG 평가에서 면제하는 것이 전자의 시행에서 채택되었다. 새로운 CUG 인증은 CugExclude라는 전용 인터페이스를 통해 이를 다룹니다. Apache Jackrabbit Oak 1.4에는 고정된 주도자 세트를 제외하는 기본 구현과 개별 주도자 이름을 구성할 수 있도록 하는 확장 구현이 함께 제공됩니다. 후자는 AEM 게시 인스턴스에 구성됩니다.

AEM 6.3부터 기본적으로 다음 주도자가 CUG 정책의 영향을 받지 않습니다.

자세한 내용은 아래 AEM 6.3 이후의 기본 구성 섹션의 표를 참조하십시오.

Apache Jackrabbit Oak CUG 제외 목록 ​의 구성 섹션에 있는 시스템 콘솔에서 '관리자' 그룹의 제외를 변경하거나 확장할 수 있습니다.

또는 특별한 필요가 있는 경우 제외된 주도자 집합을 조정하기 위해 CugExclude 인터페이스의 사용자 지정 구현을 제공하고 배포할 수 있습니다. 자세한 내용 및 예제 구현은 CUG 플러그성에 대한 설명서를 참조하십시오.

인증: 설정 및 구성 authentication-setup-and-configuration

새로운 인증 관련 부분이 Adobe Granite Authentication Handler 번들( com.adobe.granite.auth.authhandler 버전 5.6.48)에 포함되어 있습니다. 이 번들은 AEM 기본 설치의 일부입니다.

더 이상 사용되지 않는 CUG 지원에 대한 인증 요구 사항 대체를 설정하려면 주어진 AEM 설치 시 일부 OSGi 구성 요소가 존재하고 활성 상태여야 합니다. 자세한 내용은 아래의 OSGi 구성 요소의 특성 ​을 참조하십시오.

OSGi 구성 요소의 특성

인증 요구 사항을 정의하고 전용 로그인 경로를 지정하기 위해 다음 두 가지 OSGi 구성 요소가 도입되었습니다.

com.adobe.granite.auth.requirement.impl.RequirementService

com.adobe.granite.auth.requirement.impl.DefaultRequirementHandler

구성 옵션 configuration-options-1

CUG 재작성의 인증 관련 부분은 Adobe Granite 인증 요구 사항 및 로그인 경로 핸들러와 연결된 단일 구성 옵션으로만 제공됩니다.

"인증 요구 사항 및 로그인 경로 처리기"

AEM 6.3 이후 기본 구성 default-configuration-since-aem

AEM을 새로 설치하면 기본적으로 CUG 기능의 권한 부여 및 인증 관련 부분에 대해 새 구현이 모두 사용됩니다. 이전 구현인 "Adobe Granite CUG(폐쇄형 사용자 그룹) 지원"은 더 이상 사용되지 않으며 기본적으로 모든 AEM 설치에서 비활성화됩니다. 대신 새 구현은 다음과 같이 활성화됩니다.

작성자 인스턴스 author-instances

Publish 인스턴스 publish-instances

CUG 인증 및 인증 요구 사항 비활성화 disabling-cug-authorization-and-authentication-requirement

주어진 설치가 CUG를 사용하지 않거나 인증 및 권한 부여에 다른 수단을 사용하는 경우 새 구현이 완전히 비활성화될 수 있습니다.

CUG 인증 비활성화 disable-cug-authorization

복합 인증 설정에서 CUG 인증 모델을 제거하는 방법에 대한 자세한 내용은 CUG 플러그성 설명서를 참조하십시오.

인증 요구 사항 비활성화 disable-the-authentication-requirement

granite.auth.authhandler 모듈에서 제공한 인증 요구 사항에 대한 지원을 비활성화하려면 Adobe Granite 인증 요구 사항 및 로그인 경로 처리기 ​와(과) 관련된 구성을 제거하는 것으로 충분합니다.

다른 모듈과의 상호 작용 interaction-with-other-modules

Apache Jackrabbit API apache-jackrabbit-api

CUG 인증 모델에서 사용하는 새로운 유형의 액세스 제어 정책을 반영하기 위해 Apache Jackrabbit에서 정의한 API가 확장되었습니다. jackrabbit-api 모듈의 버전 2.11.0은 javax.jcr.security.AccessControlPolicy에서 확장하는 org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy이라는 새 인터페이스를 정의합니다.

Apache Jackrabbit FileVault apache-jackrabbit-filevault

Apache Jackrabbit FileVault의 가져오기 메커니즘이 PrincipalSetPolicy 유형의 액세스 제어 정책을 처리하도록 조정되었습니다.

Apache Sling 컨텐츠 배포 apache-sling-content-distribution

위의 Apache Jackrabbit FileVault 섹션을 참조하십시오.

Adobe Granite 복제 adobe-granite-replication

다른 AEM 인스턴스 간에 CUG 정책을 복제할 수 있도록 복제 모듈이 약간 조정되었습니다.

CUG 정책을 복제하는 데는 한 가지 제한이 있습니다. 해당 믹스인 노드 유형 rep:CugMixin,을(를) 제거하지 않고 지정된 CUG 정책을 제거하면 복제 시 제거가 반영되지 않습니다. 이 문제는 정책 제거 시 항상 mixin을 제거하여 해결되었습니다. 그러나 mixin 유형을 수동으로 추가하는 경우 제한 사항이 표시될 수 있습니다.

Adobe Granite 인증 핸들러 adobe-granite-authentication-handler

com.adobe.granite.auth.authhandler 번들과 함께 제공되는 인증 처리기 Adobe Granite HTTP 헤더 인증 처리기 ​에는 동일한 모듈에서 정의한 CugSupport 인터페이스에 대한 참조가 있습니다. 특정 상황에서 '영역'을 계산하는 데 사용되므로 핸들러로 구성된 영역으로 돌아갑니다.

지정된 설정에서 더 이상 사용되지 않는 구현을 다시 사용하도록 설정하는 경우 최대 이전 버전과의 호환성을 보장하기 위해 CugSupport에 대한 참조를 선택 사항으로 조정했습니다. 구현을 사용하여 설치하면 더 이상 CUG 구현에서 영역을 추출하지 않지만 Adobe Granite HTTP 헤더 인증 처리기 ​로 정의된 대로 영역이 항상 표시됩니다.

AEM LiveCopy aem-livecopy

LiveCopy를 사용하여 CUG를 구성하는 작업은 다음과 같이 추가 노드 하나와 추가 속성 하나를 추가하여 저장소에 표시됩니다.

이 두 요소는 모두 cq:Page 아래에 만들어집니다. 현재 디자인을 사용하면 MSM은 cq:PageContent(jcr:content) 노드 아래에 있는 노드 및 속성만 처리합니다.

따라서 CUG 그룹은 블루프린트에서 라이브 카피로 롤아웃할 수 없습니다. Live Copy를 구성할 때 이를 염두에 두고 계획을 세우십시오.

새로운 CUG 구현의 변경 사항 changes-with-the-new-cug-implementation

이 섹션의 목표는 CUG 기능에 대한 변경 사항에 대한 개요와 이전 및 새 구현 간의 비교를 제공하는 것입니다. CUG 지원 구성 방식에 영향을 주는 변경 사항을 나열하고 저장소 콘텐츠에서 CUG를 관리하는 방법 및 사용자를 설명합니다.

CUG 설정 및 구성의 차이점 differences-in-cug-setup-and-configuration

더 이상 사용되지 않는 OSGi 구성 요소 Adobe CUG(Granite Closed User Group) 지원( com.day.cq.auth.impl.cug.CugSupportImpl)이(가) 이전 CUG 기능의 인증 및 인증 관련 부분을 별도로 처리할 수 있도록 새 구성 요소로 대체되었습니다.

저장소 컨텐츠에서 CUG 관리의 차이점 differences-in-managing-cugs-in-the-repository-content

다음 섹션에서는 구현 및 보안 관점에서 이전 구현과 새 구현 간의 차이점에 대해 설명합니다. 새로운 구현은 동일한 기능을 제공하는 것을 목표로 하지만 새로운 CUG를 사용할 때 알아야 할 미묘한 변화가 있습니다.

권한 부여와 관련된 차이점 differences-with-regards-to-authorization

인증 관점의 주요 차이점은 아래 목록에 요약되어 있습니다.

CUG에 대한 전용 액세스 제어 콘텐츠

이전 구현에서는 기본 인증 모델을 사용하여 게시에서 액세스 제어 목록 정책을 조작하고 CUG에서 지정한 설정으로 기존 ACE를 교체했습니다. 이는 게시에서 해석된 일반적이고 잔여 JCR 속성을 작성함으로써 트리거되었습니다.

새로운 구현에서는 생성, 수정 또는 제거되는 CUG의 영향을 받지 않는 기본 인증 모델의 액세스 제어 설정입니다. 대신 PrincipalSetPolicy(이)라는 새로운 유형의 정책이 추가 액세스 제어 콘텐츠로 대상 노드에 적용됩니다. 이 추가 정책은 대상 노드의 하위 노드로 배치되며, 존재하는 경우 기본 정책 노드의 형제 노드가 됩니다.

액세스 제어 관리에서 CUG 정책 편집

이렇게 하면 나머지 JCR 속성에서 전용 액세스 제어 정책으로 이동하면 CUG 기능의 권한 부분을 만들거나 수정하는 데 필요한 권한에 영향을 줍니다. 이는 액세스 제어 콘텐츠를 수정한 것으로 간주되므로 저장소에 쓸 수 있는 jcr:readAccessControl 및 jcr:modifyAccessControl 권한이 필요합니다. 따라서 페이지의 액세스 제어 콘텐츠를 수정할 권한이 있는 콘텐츠 작성자만 이 콘텐츠를 설정하거나 수정할 수 있습니다. 이는 일반 JCR 속성을 작성할 수 있는 기능이 충분하여 권한이 에스컬레이션된 이전 구현과 대조됩니다.

정책에 정의된 대상 노드

제한된 읽기 액세스 권한이 적용될 하위 트리를 정의하는 JCR 노드에 CUG 정책을 만듭니다. CUG가 전체 트리에 영향을 미칠 것으로 예상되는 경우 이 페이지가 AEM 페이지일 수 있습니다.

지정된 페이지 아래에 있는 jcr:content 노드에만 CUG 정책을 배치하면 지정된 페이지의 콘텐츠 s.str에 대한 액세스만 제한되지만 동위 멤버나 하위 페이지에는 적용되지 않습니다. 이는 유효한 사용 사례일 수 있으며 세분화된 액세스 콘텐츠를 적용할 수 있는 저장소 편집기를 통해 달성할 수 있습니다. 그러나 jcr:content 노드에 cq:cugEnabled 속성을 배치하는 것이 내부적으로 페이지 노드에 다시 매핑된 이전 구현과 대조됩니다. 이 매핑은 더 이상 수행되지 않습니다.

CUG 정책으로 권한 평가

이전 CUG 지원에서 추가 인증 모델로 이동하여 효과적인 읽기 권한을 평가하는 방식이 변경됩니다. Jackrabbit 설명서에 설명된 대로 Oak 리포지토리에 구성된 모든 모델의 권한 평가에서 읽기 액세스를 허용하는 경우 CUGcontent을(를) 볼 수 있는 지정된 주체는 읽기 액세스만 부여됩니다.

즉, 유효 권한을 평가하기 위해 CUGPolicy과(와) 기본 액세스 제어 항목을 모두 고려하며 CUG 콘텐츠에 대한 읽기 액세스는 두 유형의 정책에서 모두 부여된 경우에만 부여됩니다. 전체 /content 트리에 대한 읽기 액세스 권한이 모든 사용자에게 부여된 기본 AEM 게시 설치에서 CUG 정책의 효과는 이전 구현과 동일합니다.

온디맨드 평가

CUG 인증 모델을 사용하면 액세스 제어 관리 및 권한 평가를 개별적으로 켤 수 있습니다.

CUG 정책의 새 AEM 기본 설정 평가에서는 '게시' 실행 모드에서만 활성화됩니다. 자세한 내용은 AEM 6.3 이후의 기본 구성에 대한 세부 정보를 참조하십시오. 지정된 경로에 대한 유효 정책을 콘텐츠에 저장된 정책과 비교하여 확인할 수 있습니다. CUG에 대한 권한 평가가 활성화된 경우에만 유효 정책이 표시됩니다.

위에서 설명한 대로 CUG 액세스 제어 정책은 이제 항상 콘텐츠에 저장되지만 Apache Jackrabbit Oak CUG 구성의 시스템 콘솔에서 CUG 평가가 활성화됨​ 을(를) 설정한 경우에만 해당 정책으로 인해 발생하는 유효 권한 평가가 적용됩니다. 기본적으로 '게시' 실행 모드에서만 사용할 수 있습니다.

인증 관련 차이점 differences-with-regards-to-authentication

인증과 관련된 차이점은 아래에 설명되어 있습니다.

인증 요구 사항에 대한 전용 Mixin 유형 dedicated-mixin-type-for-authentication-requirement

이전 구현에서 CUG의 권한 부여 및 인증 측면이 모두 단일 JCR 속성(cq:cugEnabled)에 의해 트리거되었습니다. 인증에 관한 한 Apache Sling Authenticator 구현에 저장된 인증 요구 사항 목록이 업데이트되었습니다. 새 구현에서는 대상 노드를 전용 mixin 유형(granite:AuthenticationRequired)으로 표시하여 동일한 결과를 얻을 수 있습니다.

로그인 경로 제외를 위한 속성 property-for-excluding-login-path

mixin 형식은 기본적으로 cq:cugLoginPage 속성에 해당하는 granite:loginPath이라는 단일 선택적 속성을 정의합니다. 이전 구현과 달리, 로그인 경로 속성은 해당 선언 노드 유형이 언급된 mixin인 경우에만 고려됩니다. mixin 유형을 설정하지 않고 해당 이름의 속성을 추가해도 효과가 없으며 로그인 경로에 대한 새 요구 사항이나 제외가 인증자에게 보고되지 않습니다.

인증 요구 사항에 대한 권한 privilege-for-authentication-requirement

mixin 형식을 추가하거나 제거하려면 jcr:nodeTypeManagement 권한이 부여되어야 합니다. 이전 구현에서는 jcr:modifyProperties 권한을 사용하여 나머지 속성을 편집했습니다.

granite:loginPath에 관한 한 속성을 추가, 수정 또는 제거하는 데 동일한 권한이 필요합니다.

믹스인 유형으로 정의된 대상 노드 target-node-defined-by-mixin-type

강제 로그인을 적용할 하위 트리를 정의하는 JCR 노드에 인증 요구 사항을 만듭니다. CUG가 전체 트리에 영향을 주고 새 구현에 대한 UI가 페이지 노드에 인증 요구 사항 믹스인 유형을 추가하는 경우 AEM 페이지일 수 있습니다.

지정된 페이지 아래에 있는 jcr:content 노드에만 CUG 정책을 배치하면 콘텐츠에 대한 액세스만 제한됩니다. 하지만 페이지 노드 자체나 하위 페이지에는 영향을 주지 않습니다.

유효한 시나리오일 수 있으며, 모든 노드에 믹스인을 배치할 수 있도록 해 주는 저장소 편집기에서 가능합니다. 그러나 이 동작은 jcr:content 노드에 cq:cugEnabled 또는 cq:cugLoginPage 속성을 배치하는 것이 궁극적으로 페이지 노드에 내부적으로 다시 매핑되는 이전 구현과 대조됩니다. 이 매핑은 더 이상 수행되지 않습니다.

구성된 지원 경로 configured-supported-paths

granite:AuthenticationRequired mixin 형식과 granite:loginPath 속성은 모두 Adobe Granite 인증 요구 사항 및 로그인 경로 처리기 ​와 함께 제공되는 지원되는 경로 구성 옵션 집합에 정의된 범위 내에서만 적용됩니다. 경로를 지정하지 않으면 인증 요구 사항 기능이 모두 비활성화됩니다. 이 경우 mixin 유형 및 속성은 주어진 JCR 노드에 추가되거나 설정될 때 적용됩니다.

JCR 컨텐츠, OSGi 서비스 및 구성 매핑 mapping-of-jcr-content-osgi-services-and-configurations

아래 문서는 이전 구현과 새 구현 간에 OSGi 서비스, 구성 및 저장소 컨텐츠의 포괄적인 매핑을 제공합니다.

AEM 6.3 이후 CUG 매핑

파일 가져오기

업그레이드 CUG upgrade-cug

더 이상 사용되지 않는 CUG를 사용한 기존 설치 existing-installations-using-the-deprecated-cug

이전 CUG 지원 구현은 더 이상 사용되지 않으며 이후 버전에서 제거됩니다. AEM 6.3 이전 버전에서 업그레이드할 때에는 새 구현으로 이동하는 것이 좋습니다.

업그레이드된 AEM 설치의 경우 CUG 구현이 하나만 활성화되어 있는지 확인하는 것이 중요합니다. 더 이상 사용되지 않는 신규 및 기존 CUG 지원의 조합은 테스트되지 않으며 원하지 않은 비헤이비어를 초래할 수 있습니다.

기존 CUG 콘텐츠 마이그레이션 migrating-existing-cug-content

Adobe은 새로운 CUG 구현으로 마이그레이션할 수 있는 도구를 제공합니다. 사용하려면 다음 단계를 수행하십시오.