IaaS(Infrastructure as a Service)와 PaaS(Platform as a Service)가 수많은 프로젝트에 필수적인 급속한 클라우드 기술 발전 시대에 다양한 클라우드 서비스의 원활한 통합에 대한 요구는 부인할 수 없습니다. 이 분야의 주요 업체인 Microsoft는 사용자 친화적인 Microsoft Entra ID 서비스를 만드는 데 상당한 시간을 투자했습니다. 그러나 공급업체가 꼼꼼하게 정리한 지침에도 불구하고 전문가는 Slack, Salesforce 또는 Datadog과 같은 플랫폼과의 통합을 구성할 때 문제에 직면하는 경우가 많습니다. 문서는 특정 질문에 대한 답변을 제공하는 데 부족합니다.
Social Discovery Group 팀도 이러한 문제에 직면했으며, 이 기사에서는 이러한 문제를 탐색하고 해결하는 방법에 대한 통찰력을 제공할 것입니다.
50개 이상의 데이트 플랫폼 포트폴리오에서 Social Discovery Group은 보안과 신뢰성을 보장하기 위해 다양한 기술과 클라우드 서비스를 활용합니다. 우리는 다양한 클라우드 간의 P2P 연결을 포함하여 다양한 시스템을 통합하고 구성하는 데 광범위한 경험을 보유하고 있습니다.
Microsoft Entra ID는 ID 및 액세스 관리를 위한 클라우드 솔루션으로, 클라우드에서 작동하는 디렉터리 및 인증 서비스 역할을 합니다. Microsoft Entra ID는 다양한 Microsoft 및 타사 서비스에 대한 인증 및 권한 부여 서비스를 제공합니다. 이 기사에서는 Slack, MongoAtlas, ElasticCloud, Salesforce 및 Datadog 클라우드 시스템의 통합을 살펴보겠습니다.
정확한 가이드가 없기 때문에 우리는 그 과정에서 발생한 모든 문제를 자세히 설명하는 자체 가이드를 만들기로 결정했습니다. 이제 Azure의 "엔터프라이즈 애플리케이션" 섹션으로 이동하겠습니다.
새로운 기업 애플리케이션을 생성해야 합니다(몇 번의 클릭만으로 완료 가능). 다음으로 방금 생성한 애플리케이션에 액세스하고 Single Sign-On(SAML)을 구성합니다. 위에서 아래로 변경합니다.
"회원" 역할을 생성하세요(또는 다른 이름을 선택하세요). 다음으로 Microsoft Entra ID에서 테스트 사용자를 생성하고 애플리케이션에 추가합니다. 그런 다음 Slack의 관리 센터로 이동합니다. 다음 단계를 따르세요. Slack 관리자 - 인증 - SAML 구성 - 구성
다음 단계는 SAML을 구성하는 것입니다. "표시 이름" 설정에 주의하는 것이 좋습니다. 또한 설정에서 "로그인 시 프로필 업데이트"를 선택 취소하여 이메일 주소 및 표시 이름 변경을 허용하지 않습니다.
로그인 버튼의 텍스트를 사용자 정의하고 사용자가 SSO를 제외한 다른 방법을 사용하여 로그인하는 것을 금지하는 옵션도 있습니다. 그런 다음 Microsoft 계정을 사용하여 Slack에 로그인할 수 있습니다. 추가 필드나 설정이 필요한 경우 Azure AD Provision을 통해 수행할 수 있습니다.
새 속성을 추가하려면 사용자 속성으로 이동하여 새 매핑 추가를 선택합니다. Slack에 표시하려는 소스 속성을 선택하고 해당 Slack 속성과 연결합니다.
필요한 속성을 추가하고 설정을 저장한 후 주문형 프로비저닝을 진행하여 기능을 테스트합니다. 긍정적인 결과가 나오면 다음을 받게 됩니다.
다음으로 Slack으로 이동하여 전체 사용자 프로필에 표시할 속성과 해당 속성을 검색할 위치를 지정해야 합니다. 프로필로 이동하여 표시할 정보와 해당 정보를 가져올 위치를 선택하세요. 이 경우 SCIM은 Azure AD에 해당합니다.
다음으로, 원활한 통합을 경험하기 위해 Active Directory에서 Slack에 필요한 사용자를 추가하는 것이 좋습니다. 또한 사용자를 제거할 때 발생하는 문제에 주의를 기울이고 싶습니다. 사용자가 Slack 관리 센터를 통해 Slack에서 수동으로 삭제되면 권한이 부족하여 사용자를 Slack으로 전송할 수 없다는 오류가 지속됩니다. 이는 Entra ID가 범위 내의 사용자에 대한 정보를 유지하고 고유한 ID를 할당하기 때문에 발생합니다. Slack에서 사용자를 삭제했다가 다시 추가하면 Entra ID가 새 사용자로 인식하여 업데이트 시 권한 문제가 발생합니다.
여기에서 설명서를 확인하세요.
MongoAtlas의 경우 프로세스는 비슷한 경로를 따릅니다. 또한 새로운 기업 애플리케이션을 만들어야 합니다. 쉽게 검색 필드에 "MongoDB Atlas — SSO"를 입력하세요. 자세한 지침은 여기에서 확인할 수 있습니다.
다음으로 Single Sign-On 설정으로 이동하여 다음을 입력해야 합니다.
"식별자" 텍스트 필드에 다음 템플릿을 사용하여 URL을 입력합니다: https://www.okta.com/saml2/service-provider/<Customer_Unique>
"응답 URL" 텍스트 필드에 템플릿을 사용하여 URL을 입력합니다.
https://auth.mongodb.com/sso/saml2/<고객_고유>
"로그인 URL" 텍스트 필드에 https://cloud.mongodb.com/sso/<Customer_Unique> 템플릿을 사용하여 URL을 입력합니다.
속성 섹션에 주의를 기울여 아래 스크린샷에 표시된 대로 구성하는 것이 좋습니다("memberOf"를 추가하는 것이 필수임).
그런 다음 "SAML을 사용하여 Single Sign-On 설정" 페이지에서 "SAML 서명 인증서" 섹션으로 이동하여 페더레이션을 위한 XML 메타데이터를 찾습니다. 인증서를 다운로드하고 로컬(페더레이션 메타데이터 XML)에 저장하려면 "다운로드"를 선택합니다. 나중에 MongoDB Atlas에서 필요할 것입니다.
"MongoDB Atlas 설정 - SSO" 섹션에서 해당 URL을 복사합니다. 다음으로 MongoDB Atlas -> 조직 -> 설정 -> 연합 인증 설정 으로 이동합니다.
Atlas에 Microsoft Entra ID 자격 증명 공급자를 추가하여 시작하세요. Microsoft 포털 (발급자 URI, 로그인 URL, Single Sign-On URL) 에서 이전 단계에서 언급한 각 URL을 입력 하고 ID 공급자 서명 인증서를 업로드한 후 아래 스크린샷에 표시된 대로 나머지 설정을 구성합니다 .
나중에 Azure의 Single Sign-On 구성 페이지에 업로드해야 하므로 "다음"을 클릭하고 메타데이터 파일을 로컬에 저장합니다.
그런 다음 MongoDB Atlas에서 생성된 해당 TXT 레코드를 사용하여 도메인을 추가, 매핑 및 검증합니다. 그런 다음 도메인을 자격 증명 공급자와 연결하고 가장 흥미로운 부분인 역할 구성으로 이동합니다.
예시로 다음과 같은 역할을 만들었습니다. 각 역할에는 프로젝트에 부여된 특정 권한이 있습니다. 그런 다음 이러한 역할을 Azure 역할에 매핑해야 합니다. 애플리케이션의 "앱 역할"로 이동하여 MongoAtlas에서 방금 이러한 역할에 할당한 이름과 정확히 일치하는 값을 가진 역할을 만들고 추가하세요.
그런 다음 Microsoft Entra ID 엔터프라이즈 애플리케이션의 애플리케이션에 사용자를 추가하고 적절한 역할을 할당합니다. MongoDB Atlas의 페더레이션 관리 섹션에서 "Azure SSO로 로그인"을 활성화하고 구성된 설정이 올바르게 작동하는지 확인합니다.
자세한 지침은 여기의 설명서를 참조하세요.
Elastic Cloud와의 통합으로 넘어가겠습니다. Enterprise Application Entra ID에서 애플리케이션을 생성하는 기본 단계는 이전 단계와 유사합니다. 여기에서 식별자 또는 로그아웃 URL을 얻을 수 있는 위치에 대한 정보를 찾을 수 있습니다. 그러나 속성에 문제가 발생했으므로 작업 구성의 스크린샷을 제공하겠습니다.
우리는 독자와 슈퍼유저라는 두 가지 역할을 만들었습니다.
여기에서 필요한 만큼 역할을 생성할 수 있습니다. Elasticsearch의 역할 설정은 역할 매핑에서 구성되며 다음과 같습니다.
이제 흥미로운 부분이 나옵니다. 수행해야 할 두 가지 작업은 Kibana 및 Elasticsearch에 대한 Azure SSO 구성을 추가하는 것입니다. 이를 달성하려면 다음 단계를 따르십시오.
Elasticsearch Cloud 배포의 편집 섹션으로 이동하여 elasticsearch.yml 구성을 업데이트하세요. 다음 줄을 추가합니다.
“ xpack:
security:
authc:
realms:
saml:
saml-azure-ad:
order: 2
attributes.principal: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
attributes.groups: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role"
attributes.name: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
attributes.mail: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
idp.metadata.path: "APP Federation metadata URL"
idp.entity_id: "Azure Entra ID Identifier"
sp.entity_id: "Kibana endpoint"
sp.acs: "Kibana endpoint/api/security/v1/saml"
sp.logout: "Kibana endpoint/logout" “
구성과 일치하도록 빨간색으로 강조 표시된 값을 추가하고 수정한 후 "저장"을 클릭하세요. Elastic Cloud는 모든 변경 사항을 검증하고 클러스터 업데이트를 시작합니다. 이 프로세스는 몇 분 정도 걸릴 수 있습니다.
“ xpack.security.authc.providers:
saml.saml1:
order: 0
realm: saml-azure-ad
description: "Log in with Azure Entra ID"
basic.basic1:
order: 1 ”
이전 두 단계를 완료한 후에는 Kibana 로그인 페이지에서 다른 로그인 옵션을 사용할 수 있습니다. 다음으로 Microsoft Entra ID Enterprise 애플리케이션의 애플리케이션에 사용자를 추가하고 필요한 역할을 할당하는 작업을 진행합니다.
자세한 내용은 여기 문서를 참조하세요.
Salesforce와의 통합은 이전 통합보다 조금 더 복잡했습니다. 초기 단계는 유사하지만 프로비저닝 섹션에 주의를 기울여야 합니다. 계정 동기화가 발생하는 관리자 자격 증명 지정과 관련하여 미묘한 차이가 있으며 속성 매핑 활성화가 필요합니다.
다음은 스크린샷에 있는 구성 설정의 예입니다. 속성과 관련하여 심각한 문제는 발생하지 않았지만 우리가 사용한 속성의 스크린샷도 제공하겠습니다.
Salesforce 자체에는 특별한 뉘앙스가 없었고, 이 가이드 에 설명된 대로 다음 단계를 진행했습니다.
Datadog과의 통합 과정에서 몇 가지 문제도 발생했습니다. 우리를 안내한 기본 문서는 여기에서 찾을 수 있습니다. 미묘한 문제를 해결하려면 이 가이드를 참조하세요.
모든 일이 순조롭게 시작되었고, 처음에는 아무 문제도 없을 것 같았습니다. 평소와 마찬가지로 Microsoft Entra ID에 새로운 Enterprise Application을 만들었습니다.
"SAML을 사용하여 Single Sign-On 설정" 섹션에서 Datadog 계정에 대해 선택한 위치에 주의하세요. 우리의 경우에는 유럽 지역이었습니다.
앞서 언급했듯이 MongoAtlasDB의 경우 역할 매핑을 위해 "memberOf" 속성을 추가합니다.
모든 설정을 저장하고 페더레이션 메타데이터 XML을 다운로드합니다. 이 파일을 Datadog의 SAML 설정에 업로드하세요. 참고할 수 있는 편리한 링크는 다음과 같습니다. Datadog SAML 설정(위치가 다른 경우 "EU"를 적절한 도메인 영역으로 바꾸십시오). 아래 스크린샷과 같아야 합니다.
조직의 로그인 방법 설정에서 필요한 것만 유지합니다(저의 경우 비밀번호 로그인과 Google 인증을 비활성화했습니다). Microsoft Entra ID에 대한 애플리케이션 등록에서 Azure에 역할을 추가합니다.
가장 흥미로운 부분이 여기에 있습니다. Datadog에서 SAML 그룹 매핑 -> 역할 매핑으로 이동하여 키, 값 및 역할을 추가합니다. 그것은 간단 해 보인다. 아래 스크린샷을 참조하세요.
하지만 작동하지 않고 "이 사용자에 대한 AuthNMapping이 없습니다"라는 오류가 계속 표시됩니다.
꽤 오랫동안 우리는 모든 문서, 로그 및 문제 해결 페이지를 검토하면서 우리가 무엇을 잘못하고 있는지 이해하려고 노력했습니다. 아쉽게도 이에 대한 언급은 어디에도 없었습니다. 결국 해결책은 간단합니다. 아래 스크린샷에 표시된 구성을 따르세요.
KEY 필드에 http://schemas.microsoft.com/ws/2008/06/identity/claims/role 문자열을 입력합니다.
이 작업을 수행한 후 모든 것이 성공적으로 작동하기 시작했습니다.
"이것은 우리가 Microsoft Entra ID와 통합한 시스템의 작은 부분일 뿐입니다. 여기서 공유한 통찰력이 유용한 리소스가 되어 통합 프로세스를 간소화하고 귀중한 시간을 절약할 수 있기를 바랍니다. 결론적으로 Microsoft를 사용하면 다음과 같은 이점이 있습니다. Entra ID는 강조할 수 있습니다: 비밀번호를 여러 번 입력할 필요가 없는 Single Sign-On, 추가 구성 요소가 필요하지 않음, 구성 및 관리 용이성, 그룹 정책 및 그룹, 장치 등록, 높은 수준의 보안.