Azure AD와 Oracle Access Manager for Oracle E-Business Suite 간 SSO 구성 정보

이제 Azure AD에 새 통합 서비스 제공자를 등록하고, Oracle Access Manager에 새 ID 제공자(E-Business Suite)를 등록하고, Oracle Access Manager를 사용하여 Azure AD 및 E-Business Suite를 사용한 통합 SSO 인증을 수행하기 위해 필요한 구성을 변경합니다.

Azure AD 및 E-Business Suite Federation 흐름 이해

구성을 진행하기 전에 Azure AD 및 E-Business Suite Federation Flow를 이해해야 합니다.

ebiz-federation-flow.png에 대한 설명은 다음과 같습니다.
그림 ebiz-federation-flow.png에 대한 설명

이 시나리오에서 사용자는 Azure AD에 저장된 인증서를 사용하여 E-Business Suite에 액세스합니다. 이 액세스는 Azure AD가 IDP(ID 제공자)이고 E-Business Suite가 SP(서비스 제공자)인 SAML 2.0 프로토콜의 통합 인증 설정을 통해 수행됩니다. Oracle Access Manager는 SSO용 E-Business Suite 앞에 배치되므로 E-Business Suite에 통합 기능을 제공하는 구성요소이기도 합니다. 이 섹션에서는 Azure AD와 Oracle Access Manager 간에 ID 페더레이션을 구현하는 데 필요한 단계를 제공합니다.

E-Business Suite로 보호되는 끝점에 대한 액세스에서 시작된 통합 플로우에 주로 관심이 있습니다. SAML 프로토콜 용어에서 이것을 SP에서 시작한 서비스 제공자(Service-provider-initiated) 플로우라고 하며 그림 2에 설명되어 있습니다. 이 흐름에서 OAM(Oracle Access Manager) 서버는 E-Business Suite에서 보호되는 리소스에 대한 액세스를 감지하고, 인증 요청(SAMLRequest)을 생성하고, 인증을 위해 브라우저를 Azure AD로 재지정합니다. Azure AD는 사용자에게 인증서를 요청하고, 이를 검증하고, 수신된 인증 요청에 대한 응답으로 SAMLResponse를 생성하고, 이를 Oracle Access Manager로 전송합니다. 그러면 Oracle Access Manager는 검증을 검증하고 검증에 포함된 사용자 식별 정보를 검증하여 보호된 리소스에 대한 액세스 권한을 부여합니다.

이 섹션에 제공된 구성은 ID 제공자가 시작한(IdP 시작) 플로우도 고려합니다. 이 플로우는 처음에 Azure AD SAML 사이트 간 URL에 대해 요청되며, 이 URL은 요청하지 않은 SAMLResponse를 Oracle Access Manager 서버로 전송합니다.

SP에서 시작한 단일 로그아웃(로그아웃 플로우가 E-Business Suite에서 시작됨)도 제공된 구성에서 지원됩니다. 이 백서가 처음 게시될 때 IDP에서 시작한 단일 로그아웃(로그아웃 플로우가 Azure 포털에서 시작됨)은 지원되지 않습니다. 자세한 내용은 이 문서 끝에 있는 "알려진 문제" 섹션을 참조하십시오.

Azure AD를 ID 제공자로 구성

먼저 Azure AD를 ID 제공자로 구성해야 합니다.

  1. 도메인 관리자로 Azure 포털에 사인인합니다.
  2. 왼쪽 맨 왼쪽 탐색 창에서 Azure Active Directory를 누릅니다.
  3. Azure Active Directory 창에서 엔터프라이즈 애플리케이션을 누릅니다.
  4. 새 애플리케이션을 누릅니다.
  5. 갤러리에서 추가 섹션의 검색 상자에 EBS용 Oracle Access Manager를 입력하고 결과 애플리케이션에서 EBS용 Oracle Access Manager를 선택한 다음 추가를 누릅니다.
  6. Oracle Access Manager를 애플리케이션에 대한 서비스 제공자로 구성하려면 Single Sign-On을 누릅니다.
  7. 단일 사인온 방법으로 SAML을 선택합니다.

    SAML을 사용하여 SSO(Single Sign-On) 설정 페이지가 나타납니다. 여기서는 다음 단계에 통합 세부정보를 입력합니다.

    입력해야 하는 일부 값은 Oracle Access Manager의 SAML 메타데이터에서 가져옵니다. 메타데이터를 가져오려면 http(s)://<oam_hostname>:<port>/oamfed/sp/metadata로 이동합니다. 출력은 XML 데이터로, 그 중 일부는 다음 단계에서 필요합니다.

  8. SAML을 사용하여 Single Sign-On 설정 페이지의 기본 SAML 구성 영역에서 식별자(엔티티 ID), 회신 URL(검증 소비자 서비스 URL)로그아웃 URL에 대한 값을 제공합니다.
    • Identifier(엔티티 ID)는 SAML 메타데이터에서 EntityDescriptor 요소의 entityID 속성에 해당합니다. 런타임 시 Azure AD는 SAML 검증의 대상자 요소에 값을 추가하여 검증의 예상 대상자임을 나타냅니다. Oracle Access Manager 메타 데이터에서 다음 값을 찾아 해당 값을 입력합니다.
      <md:EntityDescriptor
      …
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       ID="id-4TfauRP-ZeWyweEXkrqcBA0w0nRhe64hOPfnY2YR"
       cacheDuration="P30DT0H0M0S"
       entityID="http://myoamserver.mycompany.com:14100/oam/fed"
       validUntil="2029-03-19T21:13:40Z">
      …
    • 회신 URL(검증 소비자 서비스 URL)은 SAML 메타데이터에서 AssertionConsumerService 요소의 Location 속성에 해당합니다. 다음 예와 같이 HTTP_POST 바인딩에 상대적인 Location 속성을 선택해야 합니다. 회신 URL은 검증을 처리해야 하는 통합 파트너의 SAML 서비스 끝점입니다.
      <md:AssertionConsumerService
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      Location="https://myoamserver.mycompany.com/oam/server/fed/sp/sso"
      index="1"/>
    • 로그아웃 URL은 Oracle Access Manager의 SAML logout 끝점에 해당합니다. 이 값은 Oracle Access Manager SAML 메타데이터에서 SingleLogoutService 요소의 Location 속성에 해당합니다. 이 값은 IdP에서 시작된 로그아웃 플로우에서만 사용됩니다.
      <md:SingleLogoutService
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      Location="https://myoamserver.mycompany.com/oamfed/sp/samlv20"
      ResponseLocation="https://myoamserver.mycompany.com/oamfed/sp/samlv20"
      />
      

    참고:

    사인온 URL 및 릴레이 상태 속성은 이 시나리오와 관련이 없으므로 건너뛸 수 있습니다.
  9. 사용자 속성 및 클레임 영역에서 SAML 검증에 삽입되어 Oracle Access Manager로 전송될 사용자 속성을 구성합니다. 이 시나리오의 경우 일부 형식의 고유한 사용자 식별을 전송해야 합니다.
    userprincipalname는 Azure AD 내에서 고유한 속성이므로 이름 식별자 value: user.userprincipalname [nameid-format:emailAddress]에 대한 기본값으로 둡니다. 이러한 구성의 의미는 userprincipalname 값을 Oracle Access Manager ID 저장소(LDAP 서버 저장소)의 사용자 항목으로 가져와야 한다는 것입니다.
  10. . SAML 서명 인증서 영역에서 Federation Metadata XML 옆의 다운로드 링크를 누르고 컴퓨터에 파일을 저장합니다. 나중에 Oracle Access Manager를 서비스 제공자로 구성할 때 사용합니다.

애플리케이션에 사용자 지정

그런 다음 응용 프로그램에 유저를 할당합니다. Azure AD가 애플리케이션에서 인증 요청을 수신하면 애플리케이션에 지정한 사용자만 로그인할 수 있습니다.

  1. 이전 섹션에서 생성한 Azure AD 애플리케이션에서 사용자 및 그룹을 누른 다음 사용자 추가를 누릅니다.
  2. Users and groups: None Selected 옵션을 선택하고 다음 단계를 수행합니다.
    1. 구성원 선택 또는 외부 사용자 초대 검색 상자에 사용자 이름을 입력한 다음 Enter 키를 누릅니다.
    2. 사용자를 선택한 다음 선택을 눌러 사용자를 추가합니다.
    3. 지정을 누릅니다.
    4. 사용자 또는 그룹을 더 추가하려면 해당 단계를 반복합니다.
  3. 사용자가 SSO 구성에만 해당되는 이 엔터프라이즈 애플리케이션을 볼 수 없도록 하려면 속성을 누르고 사용자에게 표시 값을 아니요로 변경한 다음 저장을 누릅니다.

Azure AD에 대한 새 ID 제공자 생성

그런 다음 Azure AD에 대한 새 ID 제공자를 생성합니다. 이 단계에서는 Oracle Access Manager 통합 서비스가 사용으로 설정되었다고 가정합니다.

  1. Oracle Access Manager 콘솔에 관리자로 사인인합니다.
  2. 콘솔 상단에서 Federation 탭을 누릅니다.
  3. 실행 패드 탭의 통합 영역에서 서비스 제공자 관리를 누릅니다.
  4. 서비스 제공자 관리 탭에서 ID 제공자 파트너 생성을 누릅니다.
  5. 일반 사항 영역에서 ID 제공자 파트너의 이름을 입력하고 파트너 사용기본 ID 제공자 파트너를 모두 선택합니다. 저장하기 전에 다음 단계로 이동합니다.
  6. . 서비스 정보 영역에서 다음을 수행합니다.
    1. 프로토콜로 SAML2.0를 선택합니다.
    2. 제공자 메타데이터에서 로드를 선택합니다.
    3. 찾아보기(Windows의 경우) 또는 파일 선택(Mac의 경우)을 누르고 이전에 저장한 Azure AD SAML 메타데이터 파일을 선택합니다.
    4. 저장하기 전에 다음 단계로 이동하십시오.
  7. 매핑 옵션 영역에서 다음을 수행합니다.
    1. E-Business Suite 사용자에 대해 선택된 Oracle Access Manager LDAP ID 저장소로 사용할 사용자 ID 저장소 옵션을 선택합니다. 일반적으로 Oracle Access Manager ID 저장소로 이미 구성되어 있습니다.
    2. User Search Base DN은 비워 둡니다. 검색 기준은 ID 저장소 구성에서 자동으로 선택됩니다.
    3. 어설션 이름 ID를 사용자 ID 저장소에 매핑 속성을 선택하고 텍스트 상자에 메일을 입력합니다.

    참고:

    이 구성은 Azure AD와 Oracle Access Manager 간의 사용자 매핑을 정의합니다. Oracle Access Manager는 수신 SAML 검증에서 NameID 요소의 값을 가져와서 구성된 ID 저장소의 모든 사용자 항목에서 메일 속성에 대해 해당 값을 조회하려고 시도합니다. 따라서 이전에 표시된 Azure AD 구성에서 Azure AD 사용자 주체 이름이 Oracle Access Manager ID 저장소의 mail 속성과 동기화되어야 합니다.
  8. 저장을 눌러 ID 제공자 파트너를 저장합니다.
  9. 파트너를 저장한 후 탭 하단의 고급 영역으로 돌아갑니다. 옵션이 다음과 같이 구성되었는지 확인합니다.
    • Enable global logout이 선택되었습니다.
    • HTTP POST SSO 응답 바인딩이 선택되었습니다.
      Oracle Access Manager가 Azure AD에 SAML 검증을 다시 전송하는 방법을 알려주는 인증 요청을 전송하는 지침입니다. Oracle Access Manager에서 보내는 인증 요청을 검사하면 다음 예와 같이 표시됩니다. 예제에서 AuthnRequest 요소의 굵게 ProtocolBinding 속성을 기록해 두십시오.
      <?xml version="1.0"?>
      <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
      xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
      xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      Destination="https://login.microsoftonline.com/4e39517e-7ef9-45a7-
      9751-6ef6f2d43429/saml2" ID="id-y5nmx61xB8QWXtDmYWcH7rPYs5zXtV-fcKRyyM9" IssueInstant="2019-04-23T17:01:25Z"
      ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      Version="2.0">
      <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameidformat:entity">http://myoamserver.mycompany.com:14100/oam/fed</saml:Is
      suer>
      <dsig:Signature>
      <dsig:SignedInfo>
      <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xmlexc-c14n#"/>
      <dsig:SignatureMethod
      Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
      <dsig:Reference URI="#id-y5nmx61xB8QWXtDmYWcH7rPYs5zXtV-fcKRy-yM9">
      <dsig:Transforms>
      <dsig:Transform
      Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
      <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      </dsig:Transforms>
      <dsig:DigestMethod
      Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
      <dsig:DigestValue>pa00UWdqfywm4Qb59HioA6BhD18=</dsig:DigestValue>
      </dsig:Reference>
      </dsig:SignedInfo>
      <dsig:SignatureValue>X4eZRyFD6sznA0g3BJebU2c6ftunG2UvwbMptO+10wFky0aAL
      nnr0Na+5fF83U4Ut99OvAIZ41K3YMNaR4A8zr37SSlBrb72X7CTtxjh2mAphWDRPmkJx4v
      S0HACzZh0MHimdwq+qVXuFRbSLBE+9XNSGWJzGAh//WqGBlNrKnw=</dsig:SignatureV
      alue>
      </dsig:Signature>
      </samlp:AuthnRequest>
    • Enable HTTP Basic Authentication (SSO artifact binding)이 선택되지 않았습니다.

      이 설정은 Azure AD가 HTTP POST 요청을 통해 검증을 전송하도록 요청합니다. 이와 같은 요청을 받으면 ID 제공자는 일반적으로 검증이 포함된 HTML 폼을 서비스 제공자의 ACS(Assertion Consumer Service)에 자동으로 게시되는 숨겨진 폼 요소로 생성합니다.

  10. General 영역에서 Create Authentication Scheme and Module 버튼을 누릅니다.
    인증 체계 및 모듈은 파트너 이름으로 생성됩니다. 인증에 Azure AD 자격 증명이 필요한 E-Business Suite 리소스에 인증 체계를 연결하는 구성만 남았습니다. 이 작업은 다음 섹션에서 수행합니다.
  11. 다음 단계에 따라 생성된 인증 모듈을 확인할 수 있습니다.
    1. 콘솔 상단에 있는 Application Security 탭을 누릅니다.
    2. Plug-ins(플러그인)에서 Authentication Modules(인증 모듈)를 선택하고 Search(검색)를 누른 다음 통합 모듈을 찾습니다.
    3. 모듈을 선택한 다음 Steps 탭을 누릅니다.
    4. FedSSOIdP 속성의 값은 ID 제공자 파트너입니다.

E-Business Suite 리소스를 인증 체계와 연관

마지막 구성 단계는 E-Business Suite 리소스를 인증 체계와 연관시키는 것입니다. Oracle Access Manager 콘솔에 관리자로 로그인한 상태에서 이러한 단계를 수행합니다.

  1. 콘솔 맨 위에서 Application Security를 누릅니다.
  2. Access Manager에서 애플리케이션 도메인을 선택하고 검색을 누른 다음 E-Business Suite WebGate를 등록했을 통합을 위해 E-Business Suite 스크립트 실행 중 생성된 애플리케이션 도메인을 선택합니다.
  3. Authentication Policies 탭을 누른 다음 Protected Resources Policy를 누릅니다.
    새 통합 인증 체계로 이전에 생성된 인증 체계를 변경하여 인증 체계를 변경합니다. Oracle Access Manager가 보호된 리소스를 ID 제공자에 연결하는 방식입니다.
  4. Apply를 눌러 변경사항을 저장합니다.