조직에 내부 Active Directory (AD)를 외부 클라우드 제품과 통합 할 수있는 기능을 제공하고자합니다.서비스 제공 업체로; SCIM은 SAML을 사용하는 ADFS를 대체합니다.
우리 고객은 ADFS를 사용하는 페더레이션 서버를 가지고 있습니다. 우리는이 수준에서 둘 이상의 클라이언트를 사용하기 위해 자체 ADFS 서비스가 필요하다는 것을 알고 있습니다. SCIM을 대체품으로 사용할 수 있다는 의미입니까?
SimpleSAMLphp를 선택했습니다. API 클레임 프로세스를 통해 프로비저닝을 수락합니다. 우리는 이미 작업을 쉽게하는 그룹 정책을 갖추고 있습니다.
SAML 클레임을 통한 사용자 프로비저닝 – Silver
에 ADFS 서버가 있어야합니다. 비록 당신이 그것을 사용할 수는 있지만, 비교적 복잡한 전개, 복잡한 자동화, 제한된 프로토콜 지원 등등 몇 가지 단점이 있습니다. 당신이 필요로하는 것을하기 위해 그것을 조정할 꽤 많은 시간을 보낼 것입니다. 물론 이것은 이것에 대한 내 자신의 경험입니다.
개념적으로, 당신 말이 맞습니다. 중개자 (일반적으로 앱과 사용자의 ADFS와 같은 사용자를 아는 모든 시스템 간의 인증 트랜잭션을 중개하는 "페더레이션 공급자"라고 함)가 필요합니다.
가벼운 무게, 클라우드 준비 상태 및 확장하기 쉬운 옵션을 선택하십시오. 다행히도 많은 옵션이 있습니다.
1- 서비스 옆에 배포 할 수있는 오픈 소스 제품인 IdentityServer을 사용할 수 있습니다. 사용자가 원하는대로 확장하고 사용자 정의 할 수있는 오픈 소스 제품입니다. 수많은 유연성을 제공합니다. OSS이므로 스택을 "소유"할 수 있으며 원하는대로 수행 할 수 있습니다.
2- Microsoft에서 호스팅하는 페더레이션 공급자 인 Azure AD를 사용할 수 있습니다. ADFS 및 기타 일반 공급자와 함께 사용할 수 있습니다. 몇 가지 제한이 있습니다. 예를 들어, 사용자 데이터베이스를 쉽게 유지할 수 없으며 필요할 가능성이 높은 일반적인 것들 중에서 사용자 프로필을 정상화하지 않습니다.
3 너 같은 시나리오에 맞게 최적화 된 Auth0을 사용할 수 있습니다. (전체 공개 : 이것은 제가 작업하는 제품입니다).
어쨌든 here과 같은 시나리오 아키텍처에 대해 자세히 알아볼 수 있습니다.
정보 @eugeno_pace 주셔서 감사합니다. 우리는 여전히 SAML 또는 OAUTH가 필요합니까? – steve0nz
... 그것은 내 이해였습니다. 여러 명의 IDP가 사용자를 보내도록 허용하려면 SCRIM 또는 ADFS 서비스가 필요합니다. 다른 방법으로 사용자를 인증/프로비저닝 할 수 있습니까? – steve0nz
예, 앱에서 보안 토큰 (SAML 또는 WS-Fed를 사용하는 경우)을 수락하거나 OAuth를 구현해야합니다. 예, 고객이 토큰을 제공해야합니다 (또는 OAuth 협상에서 참여해야 함). 제가 제안하는 것처럼 중개자가있어 고객이 보유한 구현 세부 정보와 앱을 분리하고 승선 및 프로비저닝도 처리합니다. 우리는 (Auth0) 그것이 좌절의 일반적인 원인이기 때문에 승선 과정도 자동화하기로 결정했습니다. –
당신은 SCIM이라고하면 "단순 클라우드 ID 관리"를 의미합니까? 그것은 STS가 아닌 프로토콜입니다. – nzpcmad