ID 제공자 관리
SAML 또는 OIDC 싱글 사인온을 위한 맞춤형 ID 제공자(IdP)를 구성하여 조직의 사용자가 기존 기업 자격 증명으로 인증할 수 있도록 합니다.
ID 제공자 관리는 Enterprise 플랜 관리자만 사용할 수 있습니다.
맞춤형 ID 제공자(IdP)를 구성하여 조직의 싱글 사인온(SSO)을 활성화합니다. IdP를 구성하면 IDE, Bob Shell, Bob Web에서 IBM Bob에 로그인할 때 Bob이 인증을 위해 해당 IdP로 리디렉션합니다.
Bob에서 SAML 및 OpenID Connect(OIDC) ID 제공자를 구성할 수 있습니다. 조직의 ID 플랫폼에 맞는 프로토콜을 사용하세요.
SSO 프로토콜 호환성
IBM Bob은 다음 SSO 프로토콜과 호환됩니다:
- SAML(Security Assertion Markup Language)
- OIDC(OpenID Connect)
검증된 OIDC 제공자
구성 및 토큰 요구 사항을 충족하는 다른 OIDC 제공자도 사용할 수 있지만, 다음 플랫폼은 검증되었습니다:
- Auth0
- Keycloak
- Okta
- PingOne
ID 제공자 추가
IdP를 추가하는 것은 2단계 프로세스입니다. 먼저 IdP를 구성하고 저장한 다음, 해당 IdP를 사용하는 이메일 도메인을 추가합니다.
1단계: ID 제공자 구성
IBM Bob 관리 페이지로 이동합니다.
Authentication 탭을 선택합니다.
Add IdP를 클릭합니다. IdP의 이름을 입력합니다. IdP 유형을 선택합니다: SAML 또는 OIDC. 서비스 제공자(SP) 자격 증명을 생성합니다.
Bob은 SAML 인증 요청에 서명하기 위해 SP 개인 키와 SP 인증서가 필요합니다. openssl 명령줄 도구를 사용하여 직접 생성해야 합니다.
이미 SP 키 쌍과 인증서가 있는 경우 다음 단계로 건너뜁니다.
다음 명령을 실행하여 SP 개인 키를 생성합니다:
openssl genrsa -out sp_private_key.pem 2048그런 다음 이 명령을 실행하여 개인 키에서 SP 인증서를 생성합니다. /CN, /O, /C 값을 설명적인 인증서 이름, 조직 이름, 2자리 국가 코드로 교체합니다:
openssl req -new -x509 -key sp_private_key.pem -out sp_certificate.pem -days 365 -subj "/CN=Bob SAML SP/O=IBM/C=US"sp_certificate.pem 파일은 IdP가 Bob의 요청에 대한 서명을 확인할 수 있도록 IdP에도 업로드해야 합니다.
IdP의 구성 세부 정보를 입력합니다. 다음 섹션에서 프로토콜별 요구 사항을 검토합니다. Save를 클릭합니다.
IdP가 생성되어 Authentication 탭의 테이블에 표시됩니다.
SAML 구성
SAML에는 다음 구성 세부 정보가 필요합니다:
Identity provider 필드 — IdP에서 가져옵니다:
idp_entity_id— IdP의 고유 식별자(예:https://idp.example.com)idp_sso_url— Bob이 인증 요청을 보내는 SSO URLidp_certificate— IdP의 SAML 응답을 확인하는 데 사용되는 PEM 인코딩 X.509 인증서
Service provider 필드 — 이전 단계에서 생성한 파일을 사용합니다:
sp_private_key—sp_private_key.pem의 내용sp_certificate—sp_certificate.pem의 내용
선택적 필드:
idp_slo_url— IdP의 Single Logout URL. Single Logout은 Bob에서 아직 완전히 구현되지 않았습니다.
Attribute mapping 섹션에서 IdP의 사용자 속성을 IBM Bob의 사용자 필드에 매핑합니다. 매핑 형식은 Bob 속성 이름 → IdP 속성 이름 또는 URI입니다. 올바른 속성 이름은 IdP 구성을 확인하세요.
email(필수) — 사용자의 이메일 주소name(선택 사항) — 사용자의 전체 표시 이름given_name(선택 사항) — 사용자의 이름family_name(선택 사항) — 사용자의 성groups(선택 사항) — 사용자의 그룹
IdP 관리자: 새 OIDC 클라이언트 등록
Bob 인스턴스 관리자가 Bob에서 OIDC IdP 레코드를 구성하려면, 먼저 IdP 관리자가 ID 제공자 내에서 OIDC 애플리케이션(클라이언트)을 생성해야 합니다. 이 단계에서 생성된 값이 Bob 인스턴스 관리자가 Bob에 IdP를 추가할 때 입력하는 값입니다.
애플리케이션 유형 및 부여 유형
ID 제공자에서 웹 애플리케이션(서버 측 / 기밀 클라이언트)을 생성하고 Authorization Code 부여 유형을 활성화합니다. Bob은 Authorization Code 흐름만 사용합니다 — Implicit, Device Code, Client Credentials는 선택하지 마세요.
리디렉션 URI
다음 콜백 URL을 OIDC 애플리케이션에 등록하세요. 대부분의 제공자는 문자열을 정확히 일치시키므로, 정확히 복사하세요:
https://api.us-east.bob.ibm.com/authn/v1/auth/callback클라이언트에서 활성화할 스코프
| 스코프 | 목적 | 필수 |
|---|---|---|
openid | OIDC 모드를 활성화하고 id_token을 반환 | 예 |
email | id_token 또는 userinfo 엔드포인트를 통해 사용자 이메일 주소를 노출 | 예 |
offline_access | 액세스 토큰과 함께 refresh_token을 부여 | 대부분의 제공자에서 예 |
Bob은 모든 Authorization Code 교환 응답에 refresh_token이 있어야 합니다. 제공자가 다른 메커니즘(예: 제공자별 스코프, 또는 모든 코드 교환 시 무조건적으로)으로 리프레시 토큰을 발급하는 경우 그에 맞게 구성하세요 — 단, 클라이언트가 리프레시 토큰을 받을 수 있어야 합니다. refresh_token이 반환되지 않으면 로그인이 중단됩니다.
토큰 엔드포인트 인증 방법
OIDC 애플리케이션의 토큰 엔드포인트 인증 방법을 **client_secret_post**로 설정하세요. Bob은 모든 토큰 요청에서 client_id와 client_secret을 폼 바디 파라미터로 전송합니다. client_secret_basic, private_key_jwt, none은 허용되지 않습니다.
토큰 설정
| 설정 | 필요한 값 |
|---|---|
| 액세스 토큰 형식 | 임의(JWT 또는 불투명 — Bob은 IdP 액세스 토큰을 직접 파싱하지 않음) |
| ID 토큰 | 모든 Authorization Code 교환 및 모든 토큰 갱신 시 발급되어야 함 |
| ID 토큰 서명 알고리즘 | RS256, ES256 또는 PS256 |
| 리프레시 토큰 교체 | 리프레시 토큰 교체를 사용할 수 있습니다. Bob은 각 갱신 시 새 토큰을 저장합니다. 제공자가 리프레시 토큰을 교체하는 경우, Bob이 교체 토큰을 받은 후에만 제공자가 이전 토큰을 무효화하도록 하세요(표준 교체 동작, 유예 기간 없는 일회성 사용 아님). |
Bob 인스턴스 관리자에게 전달할 값
클라이언트 애플리케이션이 생성되면, 다음 값을 Bob 인스턴스 관리자에게 전달하세요:
| 값 | 찾는 위치 | Bob 구성 필드 |
|---|---|---|
| 클라이언트 ID | 애플리케이션 자격 증명 페이지 | client_id |
| 클라이언트 시크릿 | 애플리케이션 자격 증명 페이지 | client_secret |
| Authorization 엔드포인트 URL | 제공자의 OIDC 엔드포인트 페이지 또는 .well-known/openid-configuration | authorization_endpoint |
| 토큰 엔드포인트 URL | 제공자의 OIDC 엔드포인트 페이지 또는 .well-known/openid-configuration | token_endpoint |
| JWKS URI | 제공자의 OIDC 엔드포인트 페이지 또는 .well-known/openid-configuration | jwks_uri |
| Issuer URL | 제공자의 OIDC 엔드포인트 페이지 또는 .well-known/openid-configuration | issuer |
| Userinfo 엔드포인트 URL(선택 사항) | 제공자의 OIDC 엔드포인트 페이지 또는 .well-known/openid-configuration | userinfo_endpoint |
대부분의 제공자는 https://<제공자-도메인>/.well-known/openid-configuration에서 모든 엔드포인트 URL을 공개합니다.
OIDC 구성
OIDC 제공자 검색을 사용할 수 있습니다. Retrieve configuration 버튼을 클릭하면 제공자의 .well-known/openid-configuration 문서에서 엔드포인트 필드를 자동으로 채우거나 각 엔드포인트 URL을 수동으로 입력할 수 있습니다.
OIDC에는 다음 구성 세부 정보가 필요합니다:
| 필드 | 필수 | 설명 |
|---|---|---|
client_id | 예 | ID 제공자에 등록된 클라이언트 식별자. |
client_secret | 예 | 등록된 애플리케이션의 클라이언트 시크릿. Bob은 이를 안전하게 저장하며 API 응답에서 반환하지 않습니다. |
scopes | 예 | 인증 흐름 중에 요청되는 스코프. 이 목록에는 openid가 포함되어야 합니다. 일반적으로 email과 offline_access와 같은 리프레시 토큰을 발급하는 데 사용되는 제공자별 스코프도 포함됩니다. |
authorization_endpoint | 예 | Bob이 사용자를 로그인을 위해 리디렉션하는 HTTPS 인증 URL. |
token_endpoint | 예 | 인증 코드를 토큰과 교환하는 데 사용되는 HTTPS 토큰 URL. |
jwks_uri | 예 | id_token 응답의 서명을 확인하는 데 사용되는 JSON Web Key Set(JWKS)의 HTTPS URL. |
issuer | 아니요 | ID 제공자의 HTTPS 발급자 식별자. |
prompt | 아니요 | 인증 요청에 전달되는 OIDC prompt 값. |
OIDC는 Attribute mapping을 사용하지 않습니다. Bob은 id_token의 email 클레임에서 사용자의 이메일을 직접 읽습니다.
OIDC 구성 예시
{
"authorization_endpoint": "https://corp.okta.com/oauth2/default/v1/authorize",
"token_endpoint": "https://corp.okta.com/oauth2/default/v1/token",
"issuer": "https://corp.okta.com/oauth2/default",
"client_id": "0oa1b2c3d4e5f6g7h8i9",
"client_secret": "super-secret-value",
"scopes": ["openid", "email", "offline_access"]
}OIDC 요구 사항 및 제한 사항
- Bob은 인증 코드 교환 응답에
refresh_token이 필요합니다. 제공자가 이를 반환하지 않으면 로그인이 실패합니다. - 대부분의 제공자에서
scopes에offline_access를 추가하면 리프레시 토큰 발급이 트리거됩니다. 일부 제공자는 다른 동작을 사용하므로 제공자의 문서를 확인하세요. - OIDC 백채널 로그아웃은 사용할 수 없습니다.
- 제공자가 엔드포인트 URL을 변경하면 Bob에서 IdP 구성을 업데이트하세요.
2단계: 도메인 필터 추가
IdP를 저장한 후, 인증에 해당 IdP를 사용해야 하는 이메일 도메인을 추가합니다.
Authentication 탭에서 방금 생성한 IdP를 찾아 설정을 엽니다. Domain filters 섹션에서 이 IdP를 사용해야 하는 이메일 도메인을 추가합니다. 구성된 도메인과 일치하는 이메일 주소를 가진 사용자는 로그인 시 이 IdP로 리디렉션됩니다. 변경 사항을 저장합니다.
각 이메일 도메인은 하나의 IdP에만 연결할 수 있습니다. 도메인이 이미 다른 IdP에서 사용 중인 경우, 충돌이 해결될 때까지 구성을 저장할 수 없습니다. SSO가 적용되기 전에 각 도메인을 확인해야 합니다. 도메인 소유권 확인을 참조하세요.
도메인 소유권 확인
IBM Bob은 SSO가 적용되기 전에 조직이 각 도메인을 소유하고 있는지 확인할 것을 요구합니다. 확인은 도메인에 DNS TXT 레코드를 추가하여 수행됩니다.
IBM Bob 관리 페이지로 이동합니다. Authentication 탭을 선택합니다. 확인하려는 도메인이 포함된 IdP를 선택합니다. Domain filters 섹션에서 도메인을 찾아 표시된 확인 코드를 복사합니다. DNS 제공자에서 다음 형식으로 도메인에 TXT 레코드를 추가합니다:
bob-verify=<verification-code>_verification-code_를 Domain filters 섹션에서 복사한 코드로 교체합니다. Authentication 탭으로 돌아가서 해당 도메인의 Check verification을 클릭합니다.
IBM Bob이 TXT 레코드를 성공적으로 감지하면 도메인 확인 상태가 Verified로 업데이트됩니다. DNS 변경 사항이 전파되는 데 시간이 걸릴 수 있습니다.
ID 제공자 제거
IBM Bob 관리 페이지로 이동합니다. Authentication 탭을 선택합니다. 제거하려는 IdP를 찾아 Delete를 클릭합니다. 확인 대화 상자에서 Confirm을 클릭합니다.
IdP를 삭제하면 연결된 모든 도메인의 SSO 구성이 제거됩니다. 해당 IdP를 인증에 사용하던 사용자는 다른 방법으로 로그인해야 합니다. IdP에 확인된 도메인이 있는 경우 경고가 표시됩니다.