Cloud ID 또는 Google Workspace를 외부 ID 공급업체(IdP)와 통합할 계획이지만 기존 일반 계정을 통합해야 하는 경우 이 문서는 페더레이션과 통합 간의 상호작용을 이해하고 평가하는 데 도움이 됩니다. 이 문서에서는 기존 일반 계정을 통합하는 기능을 방해하지 않는 방식으로 페더레이션을 구성하는 방법도 보여줍니다.
페더레이션과 사용자 계정 통합 간의 상호작용
페더레이션된 설정에서는 신뢰할 수 있는 소스가 Cloud ID 또는 Google Workspace의 사용자 계정을 자동으로 프로비저닝할 수 있도록 Cloud ID 또는 Google Workspace를 외부 신뢰할 수 있는 소스에 연결합니다.
일반적으로 페더레이션된 설정에 대해 다음과 같은 불변이 유지됩니다.
- 신뢰할 수 있는 소스는 ID의 유일한 소스입니다.
- Cloud ID 또는 Google Workspace에는 신뢰할 수 있는 소스에서 프로비저닝한 사용자 계정 이외의 사용자 계정이 없습니다.
- SAML ID 공급업체는 신뢰할 수 있는 소스가 사용자 계정을 프로비저닝한 ID가 아닌 다른 ID에 대해 Google 싱글 사인온(SSO)을 허용하지 않습니다.
이러한 불변은 Google Cloud와 외부 ID 공급업체의 페더레이션을 위한 권장사항을 반영하지만 기존 일반 계정을 마이그레이션할 때 문제가 발생합니다.
- 기존 일반 계정은 신뢰할 수 있는 소스에서 시작되지 않습니다. 이러한 계정은 이미 존재하므로 이제 신뢰할 수 있는 소스에서 알려진 ID에 연결해야 합니다.
- 기존 일반 계정은 Cloud ID 또는 Google Workspace로 마이그레이션되면 신뢰할 수 있는 소스에서 프로비저닝하지 않은 사용자 계정입니다. 신뢰할 수 있는 소스는 마이그레이션된 계정을 인식하고 '채택'해야 합니다.
- 기존 일반 계정의 ID가 SAML ID 공급업체에 알려지지 않을 수 있지만 싱글 사인온(SSO)은 계속 사용할 수 있어야 합니다.
기존 일반 계정을 통합하려면 계정 통합에 안전한 방식으로 페더레이션을 일시적으로 설정해야 합니다.
계정 통합에 안전한 페더레이션 만들기
다음 표에는 계정 통합에 안전한 페더레이션을 만들기 위해 고려해야 할 요구사항이 나와 있습니다. 외부 IdP를 사용할 계획이지만 기존 일반 계정을 통합해야 하는 경우 설정이 처음에 이러한 요구사항을 충족하도록 해야 합니다. 기존 일반 계정의 마이그레이션을 완료한 후에는 요구사항이 더 이상 적용되지 않으므로 자유롭게 구성을 변경할 수 있습니다.
| 요구사항 | 근거 |
|---|---|
| 일반 계정이 있는 ID에 대해 싱글 사인온(SSO) 허용 | 일반 계정을 마이그레이션하려면 계정을 이전해야 합니다. Cloud ID 또는 Google Workspace 관리자가 계정 이전을 시작하지만 이전을 완료하려면 일반 계정 소유자가 이전에 동의해야 합니다. 관리자는 동의가 표시되는 시점과 이전이 수행되는 시점을 제한적으로 관리할 수 있습니다.
소유자가 동의를 표시하고 이전이 완료되면 이후의 모든 사인온에는 외부 IdP를 사용하는 싱글 사인온(SSO)이 적용됩니다. 싱글 사인온(SSO)이 성공하려면 이전이 완료된 시점에 관계없이 외부 IdP가 마이그레이션하려는 모든 일반 계정의 ID에 싱글 사인온(SSO)을 허용해야 합니다. |
| 일반 계정이 있는 ID에 대해 자동 사용자 프로비저닝 방지 | 이미 일반 계정이 있는 ID에 사용자 계정을 프로비저닝하는 경우 중복 계정이 생성됩니다. 중복 계정은 일반 계정, 구성, 관련 데이터의 소유권을 Cloud ID 또는 Google Workspace로 이전하지 못하도록 차단합니다.
많은 외부 IdP의 기본 동작은 사전에 Cloud ID 또는 Google Workspace에서 사용자 계정을 만드는 것입니다. 이로 인해 중복 계정이 생성될 수 있습니다. 기존 일반 계정이 있는 ID에 대한 자동 사용자 프로비저닝을 방지하면 실수로 중복 계정을 만들지 않게 되며 일반 계정을 올바르게 이전할 수 있습니다. |
적법하다고 간주하고 Cloud Identity 또는 Google Workspace로 마이그레이션하려는 외부 IdP에 일치하는 ID가 없는 일반 계정을 확인한 경우 페더레이션 구성이 이러한 일반 계정을 마이그레이션하는 데 방해가 되지 않도록 해야 합니다.
| 요구사항 | 근거 |
|---|---|
| 외부 IdP에 일치하는 ID가 없는 마이그레이션된 계정의 삭제 방지 | 외부 IdP에 일치하는 ID가 없는 사용자 계정이 Cloud ID 또는 Google Workspace에 있는 경우 IdP는 이 사용자 계정이 분리된 것으로 간주하여 정지하거나 삭제할 수 있습니다. 외부 IdP에 일치하는 ID가 없는 마이그레이션된 계정을 외부 IdP에서 정지하거나 삭제하지 못하도록 하여 영향을 받는 계정과 연결된 구성 및 데이터를 손실하지 않도록 하고 수동으로 계정을 조정할 수 있습니다. |
계정 통합에 안전한 Microsoft Entra ID(이전의 Azure AD) 페더레이션 만들기
Cloud ID 또는 Google Workspace를 Microsoft Entra ID(이전의 Azure AD)와 페더레이션하려는 경우 Google Workspace 갤러리 앱을 사용할 수 있습니다.
프로비저닝을 사용 설정하면 Microsoft Entra ID는 Microsoft Entra ID에 대응하는 계정이 없는 Cloud ID 또는 Google Workspace의 기존 계정을 무시하므로 외부 IdP에 일치하는 ID가 없는 마이그레이션된 계정의 삭제를 방지하는 요구사항이 항상 충족됩니다.
갤러리 앱을 구성하는 방법에 따라 다음을 수행해야 합니다.
이러한 요구사항을 충족하는 방법에는 여러 가지가 있습니다. 각 접근법에는 장단점이 있습니다.
접근법 1: 프로비저닝을 구성하지 않음
이 접근법에서는 싱글 사인온(SSO)을 처리하도록 갤러리 앱을 구성하지만 자동 사용자 프로비저닝은 구성하지 않습니다. 사용자 프로비저닝을 구성하지 않으면 일반 계정이 있는 ID에 대해 자동 사용자 프로비저닝을 방지할 수 있습니다.
일반 계정이 있는 ID에 싱글 사인온(SSO)을 허용하려면 기존 일반 계정이 아직 마이그레이션 대상이라도 Google 서비스에 액세스해야 하는 모든 ID에 앱을 할당합니다.
기존 일반 계정이 있는 사용자의 경우 이전 요청이 수락되면 해당 Cloud ID 또는 Google Workspace 사용자 계정이 자동으로 생성됩니다. 이때 사용자는 즉시 싱글 사인온(SSO)을 사용할 수 있습니다.
Cloud ID 또는 Google Workspace에 사용자 계정이 없는 사용자의 경우 수동으로 계정을 만들어야 합니다.
이 접근법은 요구사항을 충족하고 설정이 가장 덜 복잡하지만 Microsoft Entra ID에서 수행된 속성 변경 또는 사용자 정지가 Cloud ID 또는 Google Workspace에 전파되지 않는다는 제한이 있습니다.
접근법 2: 수동 할당된 2개의 앱
이 접근법에서는 기존 계정이 없는 사용자를 위해 Google Workspace 또는 Cloud ID에서 사용자 계정을 수동으로 만들어야 한다는 제한을 해결할 수 있습니다. 이 접근법은 프로비저닝과 싱글 사인온(SSO)을 위한 두 개의 갤러리 앱을 사용하는 것입니다.
- 첫 번째 앱은 사용자 및 그룹 프로비저닝에만 사용되며 싱글 사인온(SSO)이 비활성화됩니다. 이 앱에 사용자를 할당하면 Cloud ID 또는 Google Workspace에 프로비저닝할 계정을 제어할 수 있습니다.
- 두 번째 앱은 싱글 사인온(SSO)에만 사용되며, 사용자를 프로비저닝할 수 있는 권한이 없습니다. 이 앱에 사용자를 할당하면 로그인이 허용되는 사용자를 제어할 수 있습니다.
이 두 앱을 사용하여 다음과 같이 사용자를 할당합니다.
- Google 서비스에 액세스해야 하는 모든 ID를 싱글 사인온(SSO) 앱에 할당합니다. 일반 계정이 있는 ID에 대해 싱글 사인온(SSO) 허용할 수 있도록 기존 일반 계정이 있는 ID를 포함합니다.
- 프로비저닝 앱에 ID를 할당할 때 Google 서비스에 액세스해야 하는 ID를 포함하되 기존 일반 계정이 있는 것으로 알려진 ID는 모두 제외합니다. 이렇게 하면 일반 계정이 있는 ID에 대해 자동 사용자 프로비저닝을 방지할 수 있습니다.
접근법 3: 사용자 생성이 사용 중지된 2개의 앱
프로비저닝을 구성할 때 Cloud ID 또는 Google Workspace 계정을 사용하여 Microsoft Entra ID에서 Cloud ID 또는 Google Workspace에 액세스하도록 승인해야 합니다. 일반적으로 이를 위해서 전용 최고 관리자 계정을 사용하는 것이 가장 좋습니다. 최고 관리자 계정은 싱글 사인온(SSO)에서 제외되기 때문입니다. 즉, SSO 구성이 적용되지 않으며 계속해서 암호를 사용하여 로그인합니다.
그러나 이 시나리오의 경우 Microsoft Entra ID에서 마이그레이션에 더 제한된 계정을 사용하도록 할 수 있습니다. 이 계정은 Microsoft Entra ID에서 사용자를 생성하는 것을 허용하지 않습니다. 이렇게 하면 프로비저닝 앱에 할당된 사용자와 무관하게 Azure에서 일반 계정이 있는 ID에 사용자 계정을 자동으로 프로비저닝하지 못하도록 방지할 수 있습니다.
Cloud ID 또는 Google Workspace에서 제한된 관리자 계정에는 다음 권한만 있어야 합니다.
- 조직 단위 > 읽기
- 사용자 > 읽기
- 사용자 > 업데이트
- 그룹
이 접근법의 단점은 비관리 계정이 없는 사용자의 경우 Cloud ID 또는 Google Workspace에서 계정을 수동으로 생성해야 한다는 것입니다.
Microsoft Entra ID와 페더레이션: 비교
다음 표에는 각 접근법이 요약되어 있습니다.
| 일반 계정이 있는 ID에 대해 싱글 사인온(SSO) 허용 | 일반 계정이 있는 ID에 대해 자동 사용자 프로비저닝 방지 | 외부 IdP에 일치하는 ID가 없는 마이그레이션된 계정의 삭제 방지 | 새 계정 자동 프로비저닝 | 마이그레이션된 계정 자동 업데이트 | |
|---|---|---|---|---|---|
| 접근법 1: 프로비저닝 없음 | ✅ | ✅ | ✅ | X | X |
| 접근법 2: 수동 할당된 2개의 앱 | ✅ | 수동 오류가 발생하기 쉬움 | ✅ | ✅ | ✅ |
| 접근법 3: 사용자 생성이 사용 중지된 2개의 앱 | ✅ | ✅ | ✅ | X | ✅ |
계정에 안전한 Active Directory 페더레이션 만들기
Cloud ID 또는 Google Workspace와 Active Directory를 페더레이션하려는 경우 Google Cloud 디렉터리 동기화(GCDS) 및 Active Directory Federation Services(AD FS)를 사용할 수 있습니다. GCDS 및 AD FS를 구성할 때는 다음을 수행해야 합니다.
- 일반 계정이 있는 ID에 대해 싱글 사인온(SSO) 허용
- 일반 계정이 있는 ID에 대해 자동 사용자 프로비저닝 방지
- 외부 IdP에 일치하는 ID가 없는 마이그레이션된 계정의 삭제 방지
이러한 요구사항을 충족하는 방법에는 여러 가지가 있습니다. 각 접근법에는 장단점이 있습니다.
접근법 1: GCDS 사용 중지
이 접근법에서는 AD FS를 사용하여 싱글 사인온(SSO)을 설정하지만 비관리 사용자 계정 마이그레이션을 완료해야 GCDS를 사용 설정할 수 있습니다. GCDS를 사용 중지하면 일반 계정이 있는 ID에 대해 자동 사용자 프로비저닝을 방지할 수 있습니다.
일반 계정이 있는 ID에 싱글 사인온(SSO)을 허용하려면 AD FS에서 커스텀 액세스 제어 정책을 만들고 기존 일반 계정이 아직 마이그레이션 대상이라도 Google 서비스에 액세스해야 하는 모든 ID를 할당합니다.
기존 일반 계정이 있는 사용자의 경우 이전 요청이 수락되면 해당 Cloud ID 또는 Google Workspace 사용자 계정이 자동으로 생성됩니다. 커스텀 액세스 제어 정책을 사용하면 사용자가 즉시 싱글 사인온(SSO)을 사용할 수 있습니다.
Cloud ID 또는 Google Workspace에 사용자 계정이 없는 사용자의 경우 수동으로 계정을 만들어야 합니다.
이 접근법은 요구사항을 충족하고 설정이 가장 덜 복잡하지만 Active Directory에서 수행된 속성 변경 또는 사용자 정지가 Cloud ID 또는 Google Workspace에 전파되지 않는다는 제한이 있습니다.
접근법 2: 수동 할당된 GCDS
이 접근법에서는 기존 계정이 없는 사용자를 위해 Cloud ID 또는 Google Workspace에서 사용자 계정을 수동으로 만들어야 한다는 제한을 해결할 수 있습니다.
접근법 1과 동일하게 AD FS에서 커스텀 액세스 제어 정책을 만들고 기존 일반 계정이 아직 마이그레이션 대상이라도 Google 서비스에 액세스해야 하는 모든 ID를 할당하여 일반 계정이 있는 ID에 싱글 사인온(SSO)을 허용합니다.
Active Directory에 GCDS에 자동으로 프로비저닝할 사용자 계정을 반영하는 그룹을 만듭니다. 구성원 목록에서 Google 서비스에 액세스해야 하는 ID를 포함하되 기존 일반 계정이 있는 것으로 알려진 ID는 모두 제외합니다.
이 그룹의 구성원인 ID에 대해서만 사용자 계정을 프로비저닝하도록 GCDS를 구성합니다. 이렇게 하면 일반 계정이 있는 ID에 대해 자동 사용자 프로비저닝을 방지할 수 있습니다.
이 접근법의 주요 제한사항은 외부 IdP에 일치하는 ID가 없는 마이그레이션된 계정의 삭제를 방지할 수 없다는 것입니다. 따라서 이 접근법은 외부 IdP에 일치하는 ID가 없는 일반 계정이 없는 경우에만 적용할 수 있습니다.
접근법 3: GCDS에서 사용자 생성 차단
프로비저닝을 구성하는 경우, Cloud ID 또는 Google Workspace에 액세스할 수 있는 권한을 GCDS에 부여해야 합니다. 일반적으로 이를 위해서 전용 최고 관리자 계정을 사용하는 것이 가장 좋습니다. 최고 관리자 계정은 싱글 사인온(SSO)에서 제외되기 때문입니다(즉, SSO 구성이 적용되지 않으며 계속 암호를 사용하여 로그인).
그러나 이 시나리오의 경우 GCDS에서 마이그레이션에 사용자 생성을 허용하지 않는 더 제한된 계정을 사용하도록 할 수 있습니다. 이렇게 하면 GCDS에서 일반 계정이 있는 ID에 사용자 계정을 자동으로 프로비저닝하지 못하도록 방지하고 외부 IdP에 일치하는 ID가 없는 마이그레이션된 계정이 삭제되는 것을 방지할 수 있습니다.
Cloud ID 또는 Google Workspace에서 제한된 관리자 계정에는 다음 권한만 있어야 합니다.
- 조직 단위
- 사용자 > 읽기
- 사용자 > 업데이트
- 그룹
- 스키마 관리
- 도메인 관리
이 접근법의 단점은 비관리 계정이 없는 사용자의 경우 Cloud ID 또는 Google Workspace에서 계정을 수동으로 생성해야 한다는 것입니다.
Active Directory와 제휴: 비교
다음 표에는 각 접근법이 요약되어 있습니다.
| 일반 계정이 있는 ID에 대해 싱글 사인온(SSO) 허용 | 일반 계정이 있는 ID에 대해 자동 사용자 프로비저닝 방지 | 외부 IdP에 일치하는 ID가 없는 마이그레이션된 계정의 삭제 방지 | 새 계정 자동 프로비저닝 | 마이그레이션된 계정 자동 업데이트 | |
|---|---|---|---|---|---|
| 접근법 1: 프로비저닝을 구성하지 않음 | ✅ | ✅ | ✅ | X | X |
| 접근법 2: 수동 할당된 GCDS | ✅ | 수동 오류가 발생하기 쉬움 | X | ✅ | ✅ |
| 접근법 3: GCDS에서 사용자 생성 차단 | ✅ | ✅ | ✅ | X | ✅ |
계정 통합에 안전한 Okta 페더레이션 만들기
Cloud ID 또는 Google Workspace를 Okta와 통합하려면 Okta 앱 카탈로그에서 Google Workspace 앱을 사용할 수 있습니다. 이 앱은 싱글 사인온(SSO)을 처리하고 Cloud ID 또는 Google Workspace에 사용자 및 그룹을 프로비저닝할 수 있습니다.
프로비저닝에 Google Workspace 앱을 사용하면 Okta는 Okta에 상대 계정이 없는 Cloud ID 또는 Google Workspace의 기존 사용자를 무시하므로 외부 IdP에 일치하는 ID가 없는 마이그레이션된 계정을 삭제하지 못하도록 방지하는 요구사항이 항상 충족됩니다.
Okta를 구성하는 방법에 따라 다음을 수행해야 합니다.
이러한 요구사항을 충족하는 방법에는 여러 가지가 있습니다. 각 접근법에는 장단점이 있습니다.
접근법 1: 프로비저닝을 구성하지 않음
이 접근법에서는 싱글 사인온(SSO)을 처리하도록 Google Workspace 앱을 구성하지만 프로비저닝은 구성하지 않습니다. 사용자 프로비저닝을 구성하지 않으면 일반 계정이 있는 ID에 대해 자동 사용자 프로비저닝을 방지할 수 있습니다.
일반 계정이 있는 ID에 싱글 사인온(SSO)을 허용하려면 기존 일반 계정이 아직 마이그레이션 대상이라도 Google 서비스에 액세스해야 하는 모든 ID에 앱을 할당합니다. Google Workspace 또는 Google Cloud 아이콘이 앱에 할당된 모든 ID의 Okta 홈페이지에 표시됩니다. 그러나 해당 사용자 계정이 Google 측에 존재하지 않으면 로그인은 실패합니다.
기존 일반 계정이 있는 사용자의 경우 이전 요청이 수락되면 해당 Cloud ID 또는 Google Workspace 사용자 계정이 자동으로 생성됩니다. 이때 사용자는 즉시 싱글 사인온(SSO)을 사용할 수 있습니다.
이 접근법은 요구사항을 충족하고 설정이 가장 덜 복잡하지만 Okta에서 수행된 속성 변경 또는 사용자 정지가 Cloud ID 또는 Google Workspace에 전파되지 않는다는 제한이 있습니다. 이 접근법의 또 다른 단점은 기존 일반 계정이 없는 모든 사용자를 위해 Cloud ID 또는 Google Workspace에서 계정을 수동으로 만들어야 한다는 것입니다.
접근법 2: 수동 할당으로 프로비저닝
이 접근법에서는 Google Workspace 앱이 싱글 사인온(SSO) 및 프로비저닝을 처리하도록 구성하지만 다음 프로비저닝 기능만 사용 설정합니다.
- 사용자 만들기
- 사용자 속성 업데이트
- 사용자 비활성화하기
앱에 ID를 할당할 때 Google 서비스에 액세스해야 하는 ID를 포함하되 기존 일반 계정이 있는 것으로 알려진 ID는 모두 제외합니다. 이렇게 하면 일반 계정이 있는 ID에 대해 자동 사용자 프로비저닝을 방지할 수 있습니다.
사용자가 이전 요청을 수락하면 사용자가 싱글 사인온(SSO)을 사용하고 Google Workspace 또는 Google Cloud에 액세스할 수 있도록 사용자를 앱에 할당합니다.
이 접근법의 한 가지 단점은 실수로 잘못 할당되면 즉시 중복 계정이 생성될 수 있으므로 다른 접근법보다 훨씬 위험하다는 것입니다.
이 접근법의 또 다른 단점은 마이그레이션된 계정이 일시적으로 잠금 상태가 되는 것입니다. 전송 요청을 수락한 후 사용자는 Okta를 통해 후속 사인온을 수행해야 합니다. 이러한 사인온 시도는 Okta에서 사용자에게 앱을 할당할 때까지 실패합니다.
접근법 3: 사용자 생성이 사용 중지된 프로비저닝
이 접근법에서는 Google Workspace가 싱글 사인온(SSO) 및 프로비저닝을 처리하도록 구성하지만 다음 프로비저닝 기능만 사용 설정합니다.
- 사용자 속성 업데이트
- 사용자 비활성화하기
사용자 만들기 옵션을 사용 중지된 상태로 두고 결국 Google 서비스에 대해 액세스 권한이 필요한 모든 ID를 앱에 할당합니다. 소비자 계정의 ID에 대해 싱글 사인온(SSO)을 허용하도록 기존 소비자 계정의 ID를 포함합니다.
Okta에서 계정 생성을 차단하면 Okta에서 일반 계정이 있는 ID에 사용자 계정을 자동으로 프로비저닝하지 못하도록 방지할 수 있습니다. 동시에 이 구성을 통해 Okta에서 해당 Google 계정이 있는 사용자에 대한 사용자 속성 변경 및 사용자 중지를 Cloud ID 또는 Google Workspace에 전파할 수 있습니다.
Cloud ID 또는 Google Workspace에 해당 사용자 계정이 없는 ID의 경우, Okta 관리 콘솔에 오류 메시지가 표시될 수 있습니다.
기존 일반 계정이 있는 사용자의 경우 이전 요청이 수락되면 해당 Cloud ID 또는 Google Workspace 사용자 계정이 자동으로 생성됩니다. 이때 사용자는 즉시 싱글 사인온(SSO)을 사용할 수 있습니다. 여기서 사용자 계정은 작동되지만 Okta에서 사용자의 홈페이지에 아이콘을 표시하지 않을 수도 있으며 대신 관리 UI에 오류 메시지를 계속 표시할 수 있습니다. 이 문제를 해결하려면 Okta 관리자 대시보드에서 할당 작업을 다시 시도하세요.
이 접근법은 Okta에서 일반 계정이 있는 ID에 사용자 계정을 자동으로 프로비저닝하지 못하도록 방지하지만 일반 계정이 있는 ID에 대해 싱글 사인온(SSO)을 허용합니다. 이 접근법은 두 번째 접근법보다 실수로 잘못 구성되는 경우가 적습니다. 한 가지 단점은 기존 일반 계정이 없는 사용자의 경우 Cloud ID 또는 Google Workspace에서 사용자 계정을 수동으로 만들어야 한다는 것입니다.
접근법 4: 수동 할당된 2개의 앱
프로비저닝 및 싱글 사인온(SSO)을 위한 2개의 앱을 사용하여 앞서 언급된 접근법의 단점을 극복할 수 있습니다.
- 프로비저닝만 처리하도록 Google Workspace 앱의 한 인스턴스를 구성합니다. 앱의 싱글 사인온(SSO) 기능이 사용되지 않습니다. 이 앱에 사용자를 할당하면 Cloud ID 또는 Google Workspace에 프로비저닝할 계정을 제어할 수 있습니다. 이 앱이 사용자에게 전혀 보이지 않도록 애플리케이션 아이콘을 사용자에게 표시하지 않음 옵션을 사용 설정합니다.
- 싱글 사인온(SSO) 목적으로만 Google Workspace 앱의 다른 인스턴스를 구성합니다. 이 앱에 사용자를 할당하면 로그온이 허용되는 사용자를 제어합니다.
이 두 앱을 사용하여 다음과 같이 사용자를 할당합니다.
- Google 서비스에 액세스해야 하는 모든 ID를 싱글 사인온(SSO) 앱에 할당합니다. 일반 계정이 있는 ID에 대해 싱글 사인온(SSO) 허용할 수 있도록 기존 일반 계정이 있는 ID를 포함합니다.
프로비저닝 앱에 ID를 할당할 때 Google 서비스에 액세스해야 하는 ID를 포함하되 기존 일반 계정이 있는 것으로 알려진 ID는 모두 제외합니다. 이렇게 하면 일반 계정이 있는 ID에 대해 자동 사용자 프로비저닝을 방지할 수 있습니다.
사용자가 이전 요청을 수락할 때마다 사용자를 앱에도 할당합니다.
Okta와 페더레이션: 비교
다음 표에는 각 접근법이 요약되어 있습니다.
| 일반 계정이 있는 ID에 대해 싱글 사인온(SSO) 허용 | 일반 계정이 있는 ID에 대해 자동 사용자 프로비저닝 방지 | 외부 IdP에 일치하는 ID가 없는 마이그레이션된 계정의 삭제 방지 | 새 계정 자동 프로비저닝 | 마이그레이션된 계정 자동 업데이트 | |
|---|---|---|---|---|---|
| 접근법 1: 프로비저닝 없음 | ✅ | ✅ | ✅ | X | X |
| 접근법 2: 수동 할당으로 프로비저닝 | X | Risky | ✅ | ✅ | ✅ |
| 접근법 3: 사용자 생성이 사용 중지된 프로비저닝 | ✅ | ✅ | ✅ | X | ✅ |
| 접근법 4: 수동 할당된 2개의 앱 | ✅ | Risky | ✅ | ✅ | ✅ |
다음 단계
- Active Directory와 페더레이션을 설정하거나 Microsoft Entra ID와 페더레이션을 설정하는 방법을 검토합니다.
- Cloud ID 또는 Google Workspace 계정을 준비하여 온보딩 프로세스를 시작합니다.