SAML 2.0 인증 saml-2-0-authentication

선택한 SAML 2.0 호환 IDP에 대해 최종 사용자(AEM 작성자가 아님)를 설정하고 인증하는 방법에 대해 알아보십시오.

AEM as a Cloud Service을 위한 SAML은 무엇입니까?

SAML 2.0을 AEM Publish(또는 미리보기)와 통합하면 AEM 기반 웹 경험의 최종 사용자가 Adobe이 아닌 IDP(ID 공급자)에 인증하고 지정된 승인된 사용자로 AEM에 액세스할 수 있습니다.

구성 연습

이 비디오는 AEM as a Cloud Service Publish 서비스와 SAML 2.0 통합을 설정하고 Okta를 IDP로 사용하는 방법에 대해 안내합니다.

사전 요구 사항

SAML 2.0 인증을 설정할 때 필요한 사항은 다음과 같습니다.

SAML 2.0은 AEM 게시 또는 미리보기에 대한 사용을 인증하는 데만 지원됩니다. 및 IDP를 사용하여 AEM 작성자의 인증을 관리하려면 IDP를 Adobe IMS와 통합하십시오.

AEM에 IDP 공개 인증서 설치

IDP의 공개 인증서가 AEM의 Global Trust Store에 추가되고, IDP에서 보낸 SAML 어설션이 유효한지 확인하는 데 사용됩니다.

글로벌 Trust Store는 AEM 작성자의 IDP 공개 인증서로 구성되지만 SAML은 AEM 게시에서만 사용되므로 IDP 공개 인증서에 액세스하려면 글로벌 Trust Store를 AEM 게시로 복제해야 합니다.

인증 서비스 키 저장소 만들기 authentication-service-keystore

인증 서비스에 대한 키 저장소를 만들려면 SAML 2.0 인증 처리기 OSGi 구성 속성 handleLogout이(가) true(으)로 설정되어 있거나 AuthnRequest 서명/SAML 어설션 암호화가 필요한 경우

AEM 공개/개인 키 쌍 설치 install-aem-public-private-key-pair

AEM 공개/개인 키 쌍 설치는 선택 사항입니다

AEM Publish는 AuthnRequests(IDP)에 서명하고 SAML 어설션(AEM)을 암호화하도록 구성할 수 있습니다. 이 작업은 AEM Publish에 개인 키를 제공함으로써 수행되며 이는 IDP에 대한 공개 키와 일치합니다.

AuthnRequest 서명 및 SAML 어설션 암호화는 모두 선택 사항이지만 SAML 2.0 인증 처리기 OSGi 구성 속성 useEncryption을(를) 사용하여 둘 다 활성화되었습니다. 즉, 둘 다 사용하거나 둘 다 사용할 수 없습니다.

SAML 2.0 인증 처리기 구성 configure-saml-2-0-authentication-handler

AEM의 SAML 구성은 Adobe Granite SAML 2.0 Authentication Handler OSGi 구성을 통해 수행됩니다.
이 구성은 OSGi 공장 구성입니다. 즉, 단일 AEM as a Cloud Service 게시 서비스에는 저장소의 개별 리소스 트리에 적용되는 여러 SAML 구성이 있을 수 있습니다. 이는 다중 사이트 AEM 배포에 유용합니다.

SAML 구성이 환경마다 다른 경우 환경당 OSGi 구성(config.publish.dev, config.publish.stage 및 config.publish.prod)을 특정 특성으로 정의할 수 있습니다.

암호화 사용

AuthnRequest 및 SAML 어설션 암호화할 때 useEncryption, spPrivateKeyAlias 및 keyStorePassword 속성이 필요합니다. keyStorePassword에 암호가 포함되어 있으므로 값을 OSGi 구성 파일에 저장하지 말고 비밀 구성 값을 사용하여 삽입해야 합니다.

레퍼러 필터 구성

SAML 인증 프로세스 중에 IDP는 AEM 게시의 .../saml_login 끝점에 대한 클라이언트측 HTTP POST를 시작합니다. IDP와 AEM 게시가 다른 원본에 있는 경우 IDP 원본의 HTTP POST를 허용하도록 OSGi 구성을 통해 AEM 게시의 레퍼러 필터​가 구성됩니다.

AEM Publish는 단일 레퍼러 필터 구성을 지원하므로 SAML 구성 요구 사항을 기존 구성과 병합합니다.

환경마다 config.publish.dev(또는 config.publish.stage)이 다른 경우 환경당 OSGi 구성(config.publish.prod, allow.hosts 및 allow.hosts.regex)을 특정 특성으로 정의할 수 있습니다.

CORS(원본 간 리소스 공유) 구성

SAML 인증 프로세스 중에 IDP는 AEM 게시의 .../saml_login 끝점에 대한 클라이언트측 HTTP POST를 시작합니다. IDP와 AEM 게시가 다른 호스트/도메인에 있는 경우 AEM 게시의 CRoss-Origin Resource Sharing(CORS)​이(가) IDP의 호스트/도메인에서 HTTP POST를 허용하도록 구성되어 있어야 합니다.

이 HTTP POST 요청의 Origin 헤더에 일반적으로 AEM 게시 호스트와 다른 값이 있으므로 CORS 구성이 필요합니다.

로컬 AEM SDK(localhost:4503)에서 SAML 인증을 테스트할 때 IDP가 Origin 헤더를 null(으)로 설정할 수 있습니다. "null" 목록에 alloworigin을(를) 추가합니다.

{
    "alloworigin": [
        "$[env:SAML_IDP_ORIGIN;default=https://dev-1234567890.okta.com]",
        "null"
    ],
    "allowedpaths": [
        ".*/saml_login"
    ],
    "supportedmethods": [
        "POST"
    ]
}

config.publish.dev 및 config.publish.stage이(가) 환경마다 다른 경우 환경당 OSGi 구성(config.publish.prod, alloworigin 및 allowedpaths)을 특정 특성으로 정의할 수 있습니다.

SAML HTTP POST를 허용하도록 AEM Dispatcher 구성

IDP에 성공적으로 인증되면 IDP는 AEM의 등록된 /saml_login 끝점(IDP에 구성됨)으로 HTTP POST를 다시 오케스트레이션합니다. /saml_login에 대한 이 HTTP POST는 Dispatcher에서 기본적으로 차단되므로 다음 Dispatcher 규칙을 사용하여 명시적으로 허용해야 합니다.

...

# Allow SAML HTTP POST to ../saml_login end points
/0190 { /type "allow" /method "POST" /url "*/saml_login" }

Apache 웹 서버에서 URL 재작성이 구성(dispatcher/src/conf.d/rewrites/rewrite.rules)된 경우 .../saml_login 끝점에 대한 요청이 실수로 손상되지 않았는지 확인하십시오.

동적 그룹 멤버십

동적 그룹 멤버십은 그룹 평가 및 프로비저닝의 성능을 향상시키는 Apache Jackrabbit Oak의 기능입니다. 이 섹션에서는 이 기능을 활성화할 때 사용자와 그룹이 저장되는 방법과 SAML 인증 핸들러의 구성을 수정하여 신규 또는 기존 환경에 대해 활성화하는 방법에 대해 설명합니다.

새 환경에서 SAML 사용자에 대해 동적 그룹 멤버십을 활성화하는 방법

새 AEM as a Cloud Service 환경에서 그룹 평가 성능을 크게 향상시키려면 새 환경에서 동적 그룹 멤버십 기능을 활성화하는 것이 좋습니다.
또한 데이터 동기화가 활성화될 때 필요한 단계입니다. 자세한 내용은 여기를 참조하세요.
이렇게 하려면 OSGI 구성 파일에 다음 속성을 추가합니다.

/apps/example/osgiconfig/config.publish/com.adobe.granite.auth.saml.SamlAuthenticationHandler~example.cfg.json

이 구성을 통해 사용자 및 그룹은 Oak 외부 사용자​(으)로 만들어집니다. AEM에서 외부 사용자 및 그룹에는 rep:principalName 또는 [user name];[idp](으)로 구성된 기본 [group name];[idp]이(가) 있습니다.
ACL(액세스 제어 목록)이 사용자 또는 그룹의 PrincipalName과 연결되어 있음을 나타냅니다.
이전에 identitySyncType이(가) 지정되지 않았거나 default(으)로 설정된 기존 배포에서 이 구성을 배포하는 경우 새 사용자 및 그룹이 만들어지고 이러한 새 사용자 및 그룹에 ACL을 적용해야 합니다. 외부 그룹은 로컬 사용자를 포함할 수 없습니다. Repoinit은(는) 사용자가 로그인을 수행할 때만 만들어지더라도 SAML 외부 그룹에 대한 ACL을 만드는 데 사용할 수 있습니다.
ACL에서 이 리팩터링을 방지하기 위해 표준 마이그레이션 기능이 구현되었습니다.

동적 그룹 멤버십을 사용하여 로컬 및 외부 그룹에 멤버십을 저장하는 방법

로컬 그룹에서 그룹 구성원이 oak 특성에 저장됩니다. rep:members. 속성에는 그룹의 모든 멤버에 대한 uid 목록이 포함됩니다. 추가 정보는 여기에서 찾을 수 있습니다.
예:

{
  "jcr:primaryType": "rep:Group",
  "rep:principalName": "operators",
  "rep:managedByIdp": "SAML",
  "rep:members": [
    "635afa1c-beeb-3262-83c4-38ea31e5549e",
    "5e496093-feb6-37e9-a2a1-7c87b1cec4b0",
    ...
  ],
   ...
}

동적 그룹 멤버십이 있는 외부 그룹은 그룹 항목에 멤버를 저장하지 않습니다.
그룹 멤버십은 대신 사용자 항목에 저장됩니다. 추가 설명서는 여기에서 찾을 수 있습니다. 예를 들어 이것은 그룹의 OAK 노드입니다.

{
  "jcr:primaryType": "rep:Group",
  "jcr:mixinTypes": [
    "rep:AccessControllable"
  ],
  "jcr:createdBy": "",
  "jcr:created": "Tue Jul 16 2024 08:58:47 GMT+0000",
  "rep:principalName": "GROUP_1;aem-saml-idp-1",
  "rep:lastSynced": "Tue Jul 16 2024 08:58:47 GMT+0000",
  "jcr:uuid": "d9c6af8a-35c0-3064-899a-59af55455cd0",
  "rep:externalId": "GROUP_1;aem-saml-idp-1",
  "rep:authorizableId": "GROUP_1;aem-saml-idp-1"
}

해당 그룹의 사용자 멤버에 대한 노드입니다.

{
  "jcr:primaryType": "rep:User",
  "jcr:mixinTypes": [
    "rep:AccessControllable"
  ],
  "surname": "Test",
  "rep:principalName": "testUser",
  "rep:externalId": "test;aem-saml-idp-1",
  "rep:authorizableId": "test",
  "rep:externalPrincipalNames": [
    "projects-users;aem-saml-idp-1",
    "GROUP_2;aem-saml-idp-1",
    "GROUP_1;aem-saml-idp-1",
    "operators;aem-saml-idp-1"
  ],
  ...
}

기존 환경에서 SAML 사용자에 대해 동적 그룹 멤버십을 활성화하는 방법

앞의 절에서 설명했듯이 외부 사용자 및 그룹의 형식은 로컬 사용자 및 그룹에 사용되는 형식과 약간 다르다. 외부 그룹에 대한 새 ACL을 정의하고 새 외부 사용자를 프로비저닝하거나 아래에 설명된 대로 마이그레이션 도구를 사용할 수 있습니다.

외부 사용자가 있는 기존 환경에 대한 동적 그룹 멤버십 활성화

다음 속성이 지정되면 SAML 인증 처리기가 외부 사용자를 만듭니다. "identitySyncType": "idp". 이 경우 "identitySyncType": "idp_dynamic"(으)로 이 속성을 수정하여 동적 그룹 구성원을 사용하도록 설정할 수 있습니다. 마이그레이션이 필요하지 않습니다.

로컬 사용자가 있는 기존 환경의 동적 그룹 멤버십으로 자동 마이그레이션

다음 속성이 지정되면 SAML 인증 처리기에서 로컬 사용자를 만듭니다. "identitySyncType": "default". 이 값은 속성을 지정하지 않은 경우에도 기본값입니다. 이 섹션에서는 자동 마이그레이션 절차에 의해 수행되는 단계에 대해 설명합니다.

이 마이그레이션이 활성화되면 사용자 인증 중에 수행되며 다음 단계로 구성됩니다.

예를 들어 마이그레이션 user1이(가) 로컬 사용자이고 로컬 그룹 group1의 멤버인 경우 마이그레이션 후 다음 변경 사항이 발생합니다.
user1이(가) 외부 사용자가 됩니다. rep:externalId 특성이 이 프로필에 추가되었습니다.
user1이(가) 외부 그룹 group1;idp의 구성원이 됩니다.
user1은(는) 더 이상 로컬 그룹의 직접 구성원이 아닙니다. group1
group1;idp은(는) 로컬 그룹 group1의 구성원입니다.
user1은(는) 상속을 통해 로컬 그룹 group1의 멤버입니다.

외부 그룹의 그룹 구성원이 속성 rep:externalPrincipalNames의 사용자 프로필에 저장되어 있습니다.

동적 그룹 멤버십으로 자동 마이그레이션을 구성하는 방법

{
  "idpIdentifier": "<value of IDP Identifier (idpIdentifier)" property from the "com.adobe.granite.auth.saml.SamlAuthenticationHandler" configuration to be migrated>"
}

여러 SAML 구성을 마이그레이션하려면 com.adobe.granite.auth.saml.migration.SamlDynamicGroupMembershipMigration에 대한 여러 OSGi 팩토리 구성을 만들어야 하며, 각 구성은 마이그레이션할 idpIdentifier을(를) 지정합니다.

고급 사용 사례에 대한 사용자 정의 SAML 후크

IDP가 SAML 어설션의 사용자 프로필 데이터 및 사용자 그룹 멤버십을 전송할 수 없거나 AEM에 동기화하기 전에 데이터를 변환해야 하는 경우 SAML 인증 프로세스를 확장하기 위해 사용자 지정 SAML 후크를 구현할 수 있습니다. SAML 후크를 사용하면 그룹 멤버십 할당을 사용자 지정하고, 사용자 프로필 속성을 수정하고, 인증 흐름 동안 사용자 지정 비즈니스 논리를 추가할 수 있습니다.

사용자 정의 SAML 후크를 사용해야 하는 경우

사용자 정의 SAML 후크는 다음 작업을 수행해야 할 때 유용합니다.

SamlHook 인터페이스 이해

com.adobe.granite.auth.saml.spi.SamlHook 인터페이스는 SAML 인증 프로세스의 여러 단계에서 호출되는 두 개의 후크 메서드를 제공합니다.

1. postSamlValidationProcess

이 메서드는 SAML 응답의 유효성을 검사했지만 사용자 동기화 프로세스가 시작되는 이전​에 이후​라고 합니다. 속성 추가 또는 변형과 같이 SAML 어설션 데이터를 수정하기에 이상적인 위치입니다.

public void postSamlValidationProcess(
    HttpServletRequest request,
    Assertion assertion,
    Message samlResponse)

사용 사례:

2. postSyncUserProcess

이 메서드는 사용자 동기화 프로세스가 완료된 후 after​에 호출됩니다. 이 후크는 AEM 사용자가 생성되거나 업데이트된 후 추가 작업을 수행하는 데 사용할 수 있습니다.

public void postSyncUserProcess(
    HttpServletRequest request,
    HttpServletResponse response,
    Assertion assertion,
    AuthenticationInfo authenticationInfo,
    String samlResponse)

사용 사례:

중요: 리포지토리에서 사용자 속성을 수정하려면 후크를 구현해야 합니다.

사용자 정의 SAML 후크 구현

다음 단계에서는 사용자 정의 SAML 후크를 만들고 배포하는 방법에 대해 간략히 설명합니다.

1단계: SAML 후크 구현 만들기

com.adobe.granite.auth.saml.spi.SamlHook 인터페이스를 구현하는 AEM 프로젝트에서 새 Java 클래스를 만듭니다.

package com.mycompany.aem.saml;

import com.adobe.granite.auth.saml.spi.Assertion;
import com.adobe.granite.auth.saml.spi.Attribute;
import com.adobe.granite.auth.saml.spi.Message;
import com.adobe.granite.auth.saml.spi.SamlHook;
import org.apache.jackrabbit.api.JackrabbitSession;
import org.apache.jackrabbit.api.security.user.Authorizable;
import org.apache.jackrabbit.api.security.user.UserManager;
import org.apache.sling.auth.core.spi.AuthenticationInfo;
import org.apache.sling.jcr.api.SlingRepository;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Reference;
import org.osgi.service.component.annotations.ReferenceCardinality;
import org.osgi.service.metatype.annotations.AttributeDefinition;
import org.osgi.service.metatype.annotations.Designate;
import org.osgi.service.metatype.annotations.ObjectClassDefinition;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import javax.annotation.Nonnull;
import javax.jcr.RepositoryException;
import javax.jcr.Session;
import javax.jcr.ValueFactory;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@Component
@Designate(ocd = SampleImpl.Configuration.class, factory = true)
public class SampleImpl implements SamlHook {
    @ObjectClassDefinition(name = "Saml Sample Authentication Handler Hook Configuration")
    @interface Configuration {
        @AttributeDefinition(
                name = "idpIdentifier",
                description = "Identifier of SAML Idp. Match the idpIdentifier property's value configured in the SAML Authentication Handler OSGi factory configuration (com.adobe.granite.auth.saml.SamlAuthenticationHandler~<unique-id>) this SAML hook will hook into"
        )
        String idpIdentifier();

    }

    private static final String SAMPLE_SERVICE_NAME = "sample-saml-service";
    private static final String CUSTOM_LOGIN_COUNT = "customLoginCount";

    private final Logger log = LoggerFactory.getLogger(getClass());

    private SlingRepository repository;

    @SuppressWarnings("UnusedDeclaration")
    @Reference(name = "repository", cardinality = ReferenceCardinality.MANDATORY)
    public void bindRepository(SlingRepository repository) {
        this.repository = repository;
    }

    /**
     * This method is called after the user sync process is completed.
     * At this point, the user has already been synchronized in OAK (created or updated).
     * Example: Track login count by adding custom attributes to the user in the repository
     *
     * @param request
     * @param response
     * @param assertion
     * @param authenticationInfo
     * @param samlResponse
     */
    @Override
    public void postSyncUserProcess(HttpServletRequest request, HttpServletResponse response, Assertion assertion,
                                    AuthenticationInfo authenticationInfo, String samlResponse) {
        log.info("Custom Audit Log: user {} successfully logged in", authenticationInfo.getUser());

        // This code executes AFTER the user has been synchronized in OAK
        // The user object already exists in the repository at this point
        Session serviceSession = null;
        try {
            // Get a service session - requires "sample-saml-service" to be configured as system user
            // Configure in: "Apache Sling Service User Mapper Service Amendment"
            serviceSession = repository.loginService(SAMPLE_SERVICE_NAME, null);

            // Get the UserManager to work with users and groups
            UserManager userManager = ((JackrabbitSession) serviceSession).getUserManager();

            // Get the authorizable (user) that just logged in
            Authorizable user = userManager.getAuthorizable(authenticationInfo.getUser());

            if (user != null && !user.isGroup()) {
                ValueFactory valueFactory = serviceSession.getValueFactory();

                // Increment login count
                long loginCount = 1;
                if (user.hasProperty(CUSTOM_LOGIN_COUNT)) {
                    loginCount = user.getProperty(CUSTOM_LOGIN_COUNT)[0].getLong() + 1;
                }
                user.setProperty(CUSTOM_LOGIN_COUNT, valueFactory.createValue(loginCount));
                log.debug("Set {} property to {} for user {}", CUSTOM_LOGIN_COUNT, loginCount, user.getID());

                // Save all changes to the repository
                if (serviceSession.hasPendingChanges()) {
                    serviceSession.save();
                    log.debug("Successfully saved custom attributes for user {}", user.getID());
                }
            } else {
                log.warn("User {} not found or is a group", authenticationInfo.getUser());
            }

        } catch (RepositoryException e) {
            log.error("Error adding custom attributes to user repository for user: {}",
                     authenticationInfo.getUser(), e);
        } finally {
            if (serviceSession != null) {
                serviceSession.logout();
            }
        }
    }

    /**
     * This method is called after the SAML response is validated but before the user sync process starts.
     * We can modify the assertion here to add custom attributes.
     *
     * @param request
     * @param assertion
     * @param samlResponse
     */
    @Override
    public void postSamlValidationProcess(@Nonnull HttpServletRequest request, @Nonnull Assertion assertion, @Nonnull Message samlResponse) {
        // Add the attribute "memberOf" with value "sample-group" to the assertion
        // In this example "memberOf" is a multi-valued attribute that contains the groups from the Saml Idp
        log.debug("Inside postSamlValidationProcess");
        Attribute groupsAttr = assertion.getAttributes().get("groups");
        if (groupsAttr != null) {
            groupsAttr.addAttributeValue("sample-group-from-hook");
        } else {
            groupsAttr = new Attribute();
            groupsAttr.setName("groups");
            groupsAttr.addAttributeValue("sample-group-from-hook");
            assertion.getAttributes().put("groups", groupsAttr);
        }
    }

}

2단계: SAML 후크 구성

SAML 후크는 OSGi 구성을 사용하여 적용할 IDP를 지정합니다. 다음 프로젝트의 OSGi 구성 파일을 만듭니다.

/ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.mycompany.aem.saml.CustomSamlHook~okta.cfg.json

{
  "idpIdentifier": "$[env:SAML_IDP_ID;default=http://www.okta.com/exk4z55r44Jz9C6am5d7]",
  "service.ranking": 100
}

idpIdentifier은(는) 해당 SAML 인증 처리기 OSGi 팩터리 구성(PID: idpIdentifier)에 구성된 com.adobe.granite.auth.saml.SamlAuthenticationHandler~<unique-id>.cfg.json 값과 일치해야 합니다. 이 일치는 중요합니다. SAML 후크는 동일한 idpIdentifier 값을 갖는 SAML 인증 처리기 인스턴스에 대해서만 호출됩니다. SAML 인증 처리기는 팩터리 구성입니다. 즉, 여러 인스턴스(예: com.adobe.granite.auth.saml.SamlAuthenticationHandler~okta.cfg.json, com.adobe.granite.auth.saml.SamlAuthenticationHandler~azure.cfg.json)가 있을 수 있으며 각 후크는 idpIdentifier을(를) 통해 특정 처리기에 연결되어 있습니다. service.ranking 속성은 여러 후크를 구성할 때 실행 순서를 제어합니다(높은 값이 먼저 실행됨).

3단계: Maven 종속성 추가

AEM Maven 핵심 프로젝트 pom.xml에 필요한 SAML SPI 종속성을 추가합니다.

AEM as a Cloud Service 프로젝트의 경우 SAML 인터페이스를 포함하는 AEM SDK API 종속성을 사용하십시오.

<dependency>
    <groupId>com.adobe.aem</groupId>
    <artifactId>aem-sdk-api</artifactId>
    <version>${aem.sdk.api}</version>
    <scope>provided</scope>
</dependency>

aem-sdk-api 아티팩트에 com.adobe.granite.auth.saml.spi.SamlHook을(를) 포함하여 필요한 모든 Adobe Granite SAML 인터페이스가 포함되어 있습니다.

4단계: 서비스 사용자 구성(저장소를 수정하는 경우)

postSyncUserProcess 예에 표시된 대로 SAML 후크에서 리포지토리의 사용자 속성을 수정해야 하는 경우 서비스 사용자를 구성해야 합니다.

{
  "user.mapping": [
    "com.mycompany.aem.core:sample-saml-service=saml-hook-service"
  ]
}

create service user saml-hook-service with path system/saml

set ACL for saml-hook-service
    allow jcr:read,rep:write,rep:userManagement on /home/users
end

이렇게 하면 서비스 사용자에게 저장소의 사용자 속성을 읽고 수정할 수 있는 권한이 부여됩니다.

5단계: AEM에 배포

사용자 지정 SAML 후크를 AEM as a Cloud Service에 배포합니다.

중요한 고려 사항

SAML 구성 배포

OSGi 구성은 Git에 커밋하고 Cloud Manager을 사용하여 AEM as a Cloud Service에 배포해야 합니다.

$ git remote -v
adobe   https://git.cloudmanager.adobe.com/myOrg/myCloudManagerGit/ (fetch)
adobe   https://git.cloudmanager.adobe.com/myOrg/myCloudManagerGit/ (push)
$ git add .
$ git commit -m "SAML 2.0 configurations"
$ git push adobe saml-auth:develop

전체 스택 배포 파이프라인을 사용하여 대상 Cloud Manager Git 분기(이 예에서는 develop)를 배포합니다.

SAML 인증 호출

SAML 인증 흐름은 특별히 제작된 링크나 단추를 만들어 AEM 사이트 웹 페이지에서 호출할 수 있습니다. 아래 설명된 매개 변수는 필요에 따라 프로그래밍 방식으로 설정할 수 있으므로, 예를 들어 로그인 단추는 단추의 컨텍스트에 따라 SAML 인증이 성공하면 사용자가 받는 위치인 saml_request_path을(를) 다른 AEM 페이지로 설정할 수 있습니다.

SAML을 사용하는 동안 보안 캐싱

AEM 게시 인스턴스에서는 대부분의 페이지가 일반적으로 캐시됩니다. 그러나 SAML로 보호된 경로의 경우 캐싱은 비활성화되거나 auth_checker 구성을 사용하여 보안 캐싱을 활성화해야 합니다. 자세한 내용은 제공된 세부 정보를 참조하십시오여기

auth_checker를 활성화하지 않고 보호된 경로를 캐시하는 경우 예기치 않은 동작이 발생할 수 있습니다.

GET 요청

SAML 인증은 다음 형식으로 HTTP GET 요청을 만들어 호출할 수 있습니다.

HTTP GET /system/sling/login

쿼리 매개 변수를 제공하는 방법:

예를 들어 이 HTML 링크는 SAML 로그인 흐름을 트리거하고 성공 시 사용자를 /content/wknd/us/en/protected/page.html(으)로 이동합니다. 이러한 쿼리 매개 변수는 필요에 따라 프로그래밍 방식으로 설정할 수 있습니다.

<a href="/system/sling/login?resource=/content/wknd&saml_request_path=/content/wknd/us/en/protected/page.html">
    Log in using SAML
</a>

POST 요청

SAML 인증은 다음 형식으로 HTTP POST 요청을 만들어 호출할 수 있습니다.

HTTP POST /system/sling/login

및 양식 데이터 제공:

예를 들어 이 HTML 단추는 HTTP POST를 사용하여 SAML 로그인 흐름을 트리거하고 성공 시 사용자를 /content/wknd/us/en/protected/page.html(으)로 안내합니다. 이러한 양식 데이터 매개 변수는 필요에 따라 프로그래밍 방식으로 설정할 수 있습니다.

<form action="/system/sling/login" method="POST">
    <input type="hidden" name="resource" value="/content/wknd">
    <input type="hidden" name="saml_request_path" value="/content/wknd/us/en/protected/page.html">
    <input type="submit" value="Log in using SAML">
</form>

Dispatcher 구성

HTTP GET 및 POST 메서드를 모두 사용하려면 클라이언트가 AEM의 /system/sling/login 끝점에 액세스해야 하므로 AEM Dispatcher을 통해 이를 허용해야 합니다.

GET 또는 POST의 사용 여부를 기준으로 필요한 URL 패턴 허용

# Allow GET-based SAML authentication invocation
/0191 { /type "allow" /method "GET" /url "/system/sling/login" /query "*" }

# Allow POST-based SAML authentication invocation
/0192 { /type "allow" /method "POST" /url "/system/sling/login" }