Skip to main content
이 페이지에서는 액세스 제어, 인증 및 자동화된 사용자 프로비저닝을 포함한 LangSmith의 사용자 관리 기능을 다룹니다:
  • 액세스 제어 설정: 역할 기반 액세스 제어(RBAC)를 구성하여 워크스페이스 내 사용자 권한을 관리하며, 사용자 정의 역할을 생성하고 사용자에게 할당합니다.
  • SAML SSO (엔터프라이즈 플랜): SAML 2.0을 사용하여 엔터프라이즈 고객을 위한 Single Sign-On 인증을 설정하며, 주요 ID 공급자에 대한 구성을 포함합니다.
  • SCIM 사용자 프로비저닝 (엔터프라이즈 플랜): SCIM을 사용하여 ID 공급자와 LangSmith 간의 사용자 프로비저닝 및 프로비저닝 해제를 자동화합니다.

​
액세스 제어 설정하기

RBAC(역할 기반 액세스 제어)는 엔터프라이즈 고객만 사용할 수 있는 기능입니다. 이 기능에 관심이 있으시면 영업 팀에 문의해 주세요. 다른 플랜은 모든 사용자에 대해 기본적으로 Admin 역할을 사용합니다.
액세스 제어를 설정하기 전에 관리 개요 페이지를 읽어보시면 도움이 될 것입니다.
LangSmith는 RBAC를 사용하여 워크스페이스 내 사용자 권한을 관리합니다. 이를 통해 누가 LangSmith 워크스페이스에 액세스할 수 있고 그 안에서 무엇을 할 수 있는지 제어할 수 있습니다. workspace:manage 권한을 가진 사용자만 워크스페이스의 액세스 제어 설정을 관리할 수 있습니다.

​
역할 생성하기

기본적으로 LangSmith는 다음과 같은 시스템 역할을 제공합니다:
  • Admin: 워크스페이스 내 모든 리소스에 대한 전체 액세스 권한을 갖습니다.
  • Viewer: 워크스페이스 내 모든 리소스에 대한 읽기 전용 액세스 권한을 갖습니다.
  • Editor: 워크스페이스 관리(사용자 추가/제거, 역할 변경, 서비스 키 구성)를 제외한 모든 권한을 갖습니다.
이러한 역할이 귀하의 액세스 모델에 맞지 않는 경우, Organization Admins는 필요에 맞는 사용자 정의 역할을 생성할 수 있습니다. 역할을 생성하려면 조직 설정 페이지의 Members and roles 섹션에서 Roles 탭으로 이동합니다. 새로 생성하는 역할은 조직 내 모든 워크스페이스에서 사용할 수 있습니다. Create Role 버튼을 클릭하여 새 역할을 생성합니다. Create role 양식이 열립니다. Create Role 액세스를 제어하려는 다양한 LangSmith 리소스에 대한 권한을 할당합니다.

​
사용자에게 역할 할당하기

역할 설정이 완료되면 사용자에게 역할을 할당할 수 있습니다. 사용자에게 역할을 할당하려면 조직 설정 페이지의 Workspaces 섹션에서 Workspace members 탭으로 이동합니다. 각 사용자는 역할을 할당하는 데 사용할 수 있는 Role 드롭다운을 갖습니다. Assign Role 특정 역할을 가진 신규 사용자를 초대할 수도 있습니다. Invite User

​
조직에 SAML SSO 설정하기

Single Sign-On(SSO) 기능은 엔터프라이즈 클라우드 고객이 단일 인증 소스를 통해 LangSmith에 액세스할 수 있도록 합니다. 이를 통해 관리자는 팀 액세스를 중앙에서 관리하고 정보를 더욱 안전하게 보호할 수 있습니다. LangSmith의 SSO 구성은 SAML(Security Assertion Markup Language) 2.0 표준을 사용하여 구축되었습니다. SAML 2.0은 ID 공급자(IdP)를 조직에 연결하여 더 쉽고 안전한 로그인 경험을 제공합니다. SSO 서비스는 사용자가 하나의 자격 증명 세트(예: 이름 또는 이메일 주소와 비밀번호)를 사용하여 여러 애플리케이션에 액세스할 수 있도록 합니다. 서비스는 사용자에게 권한이 부여된 모든 애플리케이션에 대해 최종 사용자를 한 번만 인증하며, 사용자가 같은 세션 중에 애플리케이션을 전환할 때 추가 프롬프트를 제거합니다. SSO의 이점은 다음과 같습니다:
  • 조직 소유자를 위해 여러 시스템에 걸친 사용자 관리를 간소화합니다.
  • 조직이 자체 보안 정책(예: MFA)을 시행할 수 있도록 합니다.
  • 최종 사용자가 여러 비밀번호를 기억하고 관리할 필요가 없습니다. 여러 애플리케이션에 걸쳐 하나의 액세스 지점에서 로그인할 수 있도록 하여 최종 사용자 경험을 단순화합니다.

​
Just-in-time (JIT) 프로비저닝

LangSmith는 SAML SSO를 사용할 때 Just-in-time 프로비저닝을 지원합니다. 이를 통해 SAML SSO를 통해 로그인하는 사람이 자동으로 조직 및 선택된 워크스페이스에 구성원으로 참여할 수 있습니다.
JIT 프로비저닝은 신규 사용자, 즉 다른 로그인 방법을 통해 동일한 이메일 주소로 조직에 이미 액세스 권한이 없는 사용자에 대해서만 실행됩니다.

​
로그인 방법 및 액세스

조직에 대한 SAML SSO 구성을 완료하면 사용자는 사용자 이름/비밀번호 또는 Google 인증과 같은 다른 로그인 방법 외에도 SAML SSO를 통해 로그인할 수 있습니다:
  • SAML SSO를 통해 로그인하면 사용자는 SAML SSO가 구성된 해당 조직에만 액세스할 수 있습니다.
  • SAML SSO만을 로그인 방법으로 사용하는 사용자는 개인 조직을 갖지 않습니다.
  • 다른 방법을 통해 로그인하면 사용자는 SAML SSO가 구성된 조직과 함께 자신이 속한 다른 조직에 액세스할 수 있습니다.

​
SAML SSO만 강제하기

SAML SSO만 강제하는 조직에서는 사용자 초대가 지원되지 않습니다. 초기 워크스페이스 멤버십 및 역할은 JIT 프로비저닝에 의해 결정되며, 이후 변경 사항은 UI에서 관리할 수 있습니다. 자동화된 사용자 관리의 추가 유연성을 위해 LangSmith는 SCIM을 지원합니다.
사용자가 SAML SSO를 사용하여 로그인할 때만 조직에 액세스할 수 있도록 하려면 Login via SSO only 체크박스를 선택하고 Save를 클릭합니다. 이렇게 하면 비 SSO 로그인 방법을 통해 로그인한 조직 액세스 사용자는 SAML SSO를 사용하여 다시 로그인해야 합니다. 이 설정은 체크박스를 선택 해제하고 Save를 클릭하여 모든 로그인 방법을 허용하도록 다시 전환할 수 있습니다.
이 설정을 Only SAML SSO로 업데이트하려면 SAML SSO를 통해 로그인해야 합니다. 이는 SAML 설정이 유효한지 확인하고 사용자가 조직에서 잠기는 것을 방지하기 위함입니다.
문제 해결은 SAML SSO FAQ를 참조하세요. SAML SSO 설정에 문제가 있으면 [email protected]로 LangChain 지원 팀에 문의하세요.

​
사전 요구 사항

SAML SSO는 엔터프라이즈 플랜의 조직에서 사용할 수 있습니다. 자세한 내용은 영업팀에 문의하세요.
  • 조직이 엔터프라이즈 플랜에 가입되어 있어야 합니다.
  • ID 공급자(IdP)가 SAML 2.0 표준을 지원해야 합니다.
  • Organization Admins만 SAML SSO를 구성할 수 있습니다.
사용자 프로비저닝 및 프로비저닝 해제를 위해 SAML과 함께 SCIM을 사용하는 방법에 대한 지침은 SCIM 설정을 참조하세요.

​
초기 구성

IdP별 구성 단계는 다음 중 하나를 참조하세요:
  1. IdP에서: 다음 세부 정보로 SAML 애플리케이션을 구성한 다음 3단계를 위해 메타데이터 URL 또는 XML을 복사합니다.
    다음 URL은 미국 및 유럽 지역에서 다릅니다. 올바른 링크를 선택해야 합니다.
    1. Single sign-on URL (또는 ACS URL):
    2. Audience URI (또는 SP Entity ID):
    3. Name ID format: email address.
    4. Application username: email address.
    5. Required claims: sub 및 email.
  2. LangSmith에서: Settings -> Members and roles -> SSO Configuration으로 이동합니다. 필수 정보를 입력하고 제출하여 SSO 로그인을 활성화합니다:
    1. SAML metadata URL 또는 SAML metadata XML 중 하나를 입력합니다.
    2. Default workspace role 및 Default workspaces를 선택합니다. SSO를 통해 로그인하는 신규 사용자는 선택된 역할로 지정된 워크스페이스에 추가됩니다.
  • Default workspace role 및 Default workspaces는 편집할 수 있습니다. 업데이트된 설정은 신규 사용자에게만 적용되며 기존 사용자에게는 적용되지 않습니다.
  • (곧 제공 예정) SAML metadata URL 및 SAML metadata XML은 편집할 수 있습니다. 이는 일반적으로 암호화 키가 순환/만료되거나 메타데이터 URL이 변경되었지만 동일한 IdP가 여전히 사용되는 경우에만 필요합니다.

​
Entra ID (Azure)

추가 정보는 Microsoft의 문서를 참조하세요.
1단계: 새 Entra ID 애플리케이션 통합 생성하기
  1. 권한이 있는 역할(예: Global Administrator)로 Azure 포털에 로그인합니다. 왼쪽 탐색 창에서 Entra ID 서비스를 선택합니다.
  2. Enterprise Applications으로 이동한 다음 All Applications을 선택합니다.
  3. Create your own application을 클릭합니다.
  4. Create your own application 창에서:
    1. 애플리케이션의 이름을 입력합니다(예: LangSmith).
    2. *Integrate any other application you don’t find in the gallery (Non-gallery)**를 선택합니다.
  5. Create를 클릭합니다.
2단계: Entra ID 애플리케이션 구성 및 SAML 메타데이터 얻기
  1. 생성한 엔터프라이즈 애플리케이션을 엽니다.
  2. 왼쪽 탐색 메뉴에서 Manage > Single sign-on을 선택합니다.
  3. Single sign-on 페이지에서 SAML을 클릭합니다.
  4. Basic SAML Configuration을 업데이트합니다:
    1. Identifier (Entity ID):
    2. Reply URL (Assertion Consumer Service URL):
    3. Relay State, Logout Url 및 Sign on URL은 비워 둡니다.
    4. Save를 클릭합니다.
  5. 필수 클레임이 Namespace: http://schemas.xmlsoap.org/ws/2005/05/identity/claims와 함께 있는지 확인합니다:
    1. sub: user.objectid.
    2. emailaddress: user.userprincipalname 또는 user.mail (후자를 사용하는 경우 모든 사용자가 Contact Information 아래 Email 필드를 채웠는지 확인합니다).
    3. (선택 사항) SCIM의 경우 Unique User Identifier (Name ID)에 대한 구체적인 지침은 설정 문서를 참조하세요.
  6. SAML 기반 Sign-on 페이지의 SAML Certificates 아래에서 App Federation Metadata URL을 복사합니다.
3단계: LangSmith SSO 구성 설정하기 이전 단계의 메타데이터 URL을 사용하여 초기 구성의 필수 정보 입력 단계에 있는 지침을 따릅니다. 4단계: SSO 설정 확인하기
  1. Entra ID의 사용자/그룹에 애플리케이션을 할당합니다:
    1. Manage > Users and groups를 선택합니다.
    2. Add user/group을 클릭합니다.
    3. Add Assignment 창에서:
      1. Users 아래에서 None Selected를 클릭합니다.
      2. 엔터프라이즈 애플리케이션에 할당하려는 사용자를 검색한 다음 Select를 클릭합니다.
      3. 사용자가 선택되었는지 확인하고 Assign을 클릭합니다.
  2. SSO Configuration 페이지의 고유 로그인 URL을 통해 사용자가 로그인하도록 하거나 Manage > Single sign-on으로 이동하여 **Test single sign-on with (application name)**를 선택합니다.

​
Google

추가 정보는 Google의 문서를 참조하세요. 1단계: Google Workspace SAML 애플리케이션 생성 및 구성하기
  1. 적절한 권한이 있는 관리자 계정으로 로그인되어 있는지 확인합니다.
  2. Admin console에서 Menu -> Apps -> Web and mobile apps로 이동합니다.
  3. Add App을 클릭한 다음 Add custom SAML app을 클릭합니다.
  4. 앱 이름을 입력하고 선택적으로 아이콘을 업로드합니다. Continue를 클릭합니다.
  5. Google Identity Provider details 페이지에서 IDP metadata를 다운로드하고 2단계를 위해 저장합니다. Continue를 클릭합니다.
  6. Service Provider Details 창에서 다음을 입력합니다:
    1. ACS URL:
    2. Entity ID:
    3. Start URL 및 Signed response 박스는 비워 둡니다.
    4. Name ID 형식을 EMAIL로 설정하고 Name ID를 기본값(Basic Information > Primary email)으로 둡니다.
    5. Continue를 클릭합니다.
  7. Add mapping을 사용하여 필수 클레임이 있는지 확인합니다:
    1. Basic Information > Primary email -> email
2단계: LangSmith SSO 구성 설정하기 이전 단계의 IDP metadata를 메타데이터 XML로 사용하여 초기 구성의 필수 정보 입력 단계에 있는 지침을 따릅니다. 3단계: Google에서 SAML 앱 켜기
  1. Menu -> Apps -> Web and mobile apps 아래의 SAML 앱을 선택합니다.
  2. User access를 클릭합니다.
  3. 서비스를 켭니다:
    1. 조직의 모든 사용자에 대해 서비스를 켜려면 On for everyone을 클릭한 다음 Save를 클릭합니다.
    2. 조직 단위에 대해 서비스를 켜려면:
      1. 왼쪽에서 조직 단위를 선택한 다음 On을 선택합니다.
      2. Service status가 Inherited로 설정되어 있고 상위 설정이 변경되더라도 업데이트된 설정을 유지하려면 Override를 클릭합니다.
      3. Service status가 Overridden으로 설정되어 있으면 Inherit를 클릭하여 상위와 동일한 설정으로 되돌리거나 Save를 클릭하여 상위 설정이 변경되더라도 새 설정을 유지합니다.
    3. 조직 단위 전체 또는 내에서 사용자 집합에 대해 서비스를 켜려면 액세스 그룹을 선택합니다. 자세한 내용은 그룹을 사용하여 서비스 액세스 사용자 정의를 참조하세요.
  4. 사용자가 LangSmith에 로그인하는 데 사용하는 이메일 주소가 Google 도메인에 로그인하는 데 사용하는 이메일 주소와 일치하는지 확인합니다.
4단계: SSO 설정 확인하기 SSO Configuration 페이지의 고유 로그인 URL을 통해 액세스 권한이 있는 사용자가 로그인하도록 하거나 Google의 SAML 애플리케이션 페이지로 이동하여 TEST SAML LOGIN을 클릭합니다.

​
Okta

​
지원되는 기능

  • IdP 시작 SSO (Single Sign-On)
  • SP 시작 SSO
  • Just-In-Time 프로비저닝
  • SSO만 강제하기

​
구성 단계

추가 정보는 Okta의 문서를 참조하세요. 1단계: Okta SAML 애플리케이션 생성 및 구성하기
Okta Integration Network를 통해 (권장)
  1. Okta에 로그인합니다.
  2. 오른쪽 상단에서 Admin을 선택합니다. Admin 영역에서는 버튼이 표시되지 않습니다.
  3. Browse App Integration Catalog를 선택합니다.
  4. LangSmith 애플리케이션을 찾아 선택합니다.
  5. 애플리케이션 개요 페이지에서 Add Integration을 선택합니다.
  6. ApiUrlBase는 비워 둡니다.
  7. AuthHost를 입력합니다:
    • US: auth.langchain.com
    • EU: eu.auth.langchain.com
  8. (선택 사항, SCIM도 함께 사용할 계획인 경우) LangSmithUrl을 입력합니다:
    • US: api.smith.langchain.com
    • EU: eu.api.smith.langchain.com
  9. Application Visibility 아래에서 박스를 선택하지 않은 상태로 유지합니다.
  10. Next를 선택합니다.
  11. SAML 2.0을 선택합니다.
  12. Sign-On Options를 입력합니다:
    • Application username format: Email
    • Update application username on: Create and update
    • Allow users to securely see their password: 선택하지 않음.
  13. 다음 단계에서 사용할 Sign On Options 페이지에서 Metadata URL을 복사합니다.
사용자 정의 앱 통합을 통해
SCIM은 이 구성 방법과 호환되지 않습니다. Okta Integration Network를 통해를 참조하세요.
  1. 관리자로 Okta에 로그인하고 Okta Admin console로 이동합니다.
  2. Applications > Applications에서 Create App Integration을 클릭합니다.
  3. SAML 2.0을 선택합니다.
  4. App name(예: LangSmith)을 입력하고 선택적으로 App logo를 입력한 다음 Next를 클릭합니다.
  5. Configure SAML 페이지에 다음 정보를 입력합니다:
    1. Single sign-on URL (ACS URL). Use this for Recipient URL and Destination URL을 선택한 상태로 유지합니다:
    2. Audience URI (SP Entity ID):
    3. Name ID format: Persistent.
    4. Application username: email.
    5. 나머지 필드는 비워 두거나 기본값으로 설정합니다.
    6. Next를 클릭합니다.
  6. Finish를 클릭합니다.
  7. 다음 단계에서 사용할 Sign On 페이지에서 Metadata URL을 복사합니다.
2단계: LangSmith SSO 구성 설정하기 이전 단계의 메타데이터 URL을 사용하여 초기 구성의 필수 정보 입력 단계에 있는 지침을 따릅니다. 3단계: Okta에서 LangSmith에 사용자 할당하기
  1. Applications > Applications에서 1단계에서 생성한 SAML 애플리케이션을 선택합니다.
  2. Assignments 탭에서 Assign을 클릭한 다음 Assign to People 또는 Assign to Groups를 클릭합니다.
  3. 원하는 항목을 선택한 다음 Assign 및 Done을 클릭합니다.
4단계: SSO 설정 확인하기 SSO Configuration 페이지의 고유 로그인 URL을 통해 액세스 권한이 있는 사용자가 로그인하도록 하거나 사용자가 Okta 대시보드에서 애플리케이션을 선택하도록 합니다.

​
SP 시작 SSO

서비스 공급자 시작 SSO가 구성되면 사용자는 고유 로그인 URL을 사용하여 로그인할 수 있습니다. 이는 LangSmith UI의 Organization members and roles에서 SSO configuration을 통해 찾을 수 있습니다.

​
조직에 SCIM 설정하기

System for Cross-domain Identity Management(SCIM)는 사용자 프로비저닝 자동화를 허용하는 개방형 표준입니다. SCIM을 사용하면 LangSmith 조직 및 워크스페이스에서 사용자를 자동으로 프로비저닝 및 프로비저닝 해제하여 조직의 ID 공급자와 사용자 액세스를 동기화할 수 있습니다.
SCIM은 엔터프라이즈 플랜의 조직에서 사용할 수 있습니다. 자세한 내용은 영업팀에 문의하세요.SCIM은 Helm 차트 버전 0.10.41(애플리케이션 버전 0.10.108) 이상에서 사용할 수 있습니다.SCIM 지원은 API 전용입니다(아래 지침 참조).
SCIM은 수동 사용자 관리의 필요성을 제거하고 사용자 액세스가 항상 조직의 ID 시스템과 최신 상태를 유지하도록 보장합니다. 이를 통해 다음이 가능합니다:
  • 자동화된 사용자 관리: IdP의 상태에 따라 LangSmith에서 사용자가 자동으로 추가, 업데이트 및 제거됩니다.
  • 관리 오버헤드 감소: 여러 시스템에서 수동으로 사용자 액세스를 관리할 필요가 없습니다.
  • 보안 향상: 조직을 떠나는 사용자는 LangSmith에서 자동으로 프로비저닝 해제됩니다.
  • 일관된 액세스 제어: 사용자 속성 및 그룹 멤버십이 시스템 간에 동기화됩니다.
  • 팀 액세스 제어 확장: 많은 워크스페이스 및 사용자 정의 역할을 가진 대규모 팀을 효율적으로 관리합니다.
  • 역할 할당: 사용자 그룹에 대해 특정 조직 역할 및 워크스페이스 역할을 선택합니다.

​
요구 사항

​
사전 요구 사항

  • 조직이 엔터프라이즈 플랜에 가입되어 있어야 합니다.
  • ID 공급자(IdP)가 SCIM 2.0을 지원해야 합니다.
  • 조직 관리자만 SCIM을 구성할 수 있습니다.
  • 클라우드 고객의 경우: 조직에 대해 SAML SSO를 구성할 수 있어야 합니다.
  • 자체 호스팅 고객의 경우: Client Secret을 사용한 OAuth 인증 모드가 활성화되어 있어야 합니다.
  • 자체 호스팅 고객의 경우 ID 공급자에서 LangSmith로의 네트워크 트래픽이 허용되어야 합니다:
    • Microsoft Entra ID는 IP 범위 허용 목록 또는 에이전트 기반 솔루션을 지원하여 연결을 제공합니다. (세부 정보).
    • Okta는 IP 또는 도메인 허용 목록 지정(세부 정보) 또는 에이전트 기반 솔루션(세부 정보)을 지원하여 연결을 제공합니다.

​
역할 우선순위

사용자가 동일한 워크스페이스에 대해 여러 그룹에 속할 때 다음 우선순위가 적용됩니다:
  1. 조직 관리자 그룹이 가장 높은 우선순위를 갖습니다. 이 그룹의 사용자는 모든 워크스페이스에서 Admin이 됩니다.
  2. 가장 최근에 생성된 워크스페이스별 그룹이 다른 워크스페이스 그룹보다 우선합니다.
그룹이 삭제되거나 사용자가 그룹에서 제거되면 우선순위 규칙에 따라 남아 있는 그룹 멤버십에 따라 액세스가 업데이트됩니다.SCIM 그룹 멤버십은 수동으로 할당된 역할 또는 Just-in-time (JIT) 프로비저닝을 통해 할당된 역할을 재정의합니다. 충돌을 방지하려면 JIT 프로비저닝을 비활성화하는 것이 좋습니다.

​
이메일 확인

클라우드에서만 SCIM으로 새 사용자를 생성하면 사용자에게 이메일이 전송됩니다. 이 이메일의 링크를 클릭하여 이메일 주소를 확인해야 합니다. 링크는 24시간 후에 만료되며, SCIM을 통해 사용자를 제거하고 다시 추가하여 필요한 경우 다시 보낼 수 있습니다.

​
속성 및 매핑

​
그룹 명명 규칙

그룹 멤버십은 특정 명명 규칙을 사용하여 LangSmith 워크스페이스 멤버십 및 워크스페이스 역할에 매핑됩니다: 조직 관리자 그룹 형식: <optional_prefix>Organization Admin 또는 <optional_prefix>Organization Admins 예:
  • LS:Organization Admins
  • Groups-Organization Admins
  • Organization Admin
워크스페이스별 그룹 형식: <optional_prefix><org_role_name>:<workspace_name>:<workspace_role_name> 예:
  • LS:Organization User:Production:Annotators
  • Groups-Organization User:Engineering:Developers
  • Organization User:Marketing:Viewers

​
매핑

ID 공급자에 따라 구체적인 지침이 다를 수 있지만, 이러한 매핑은 LangSmith SCIM 통합에서 지원되는 내용을 보여줍니다:

​
사용자 속성

LangSmith 앱 속성ID 공급자 속성매칭 우선순위
userName1email address
active!deactivated
emails[type eq "work"].valueemail address2
name.formatteddisplayName OR givenName + familyName3
givenNamegivenName
familyNamefamilyName
externalIdsub41
  1. userName은 LangSmith에서 필수가 아닙니다.
  2. 이메일 주소는 필수입니다.
  3. displayName이 Firstname Lastname 형식과 일치하지 않는 경우 계산된 표현식을 사용합니다.
  4. 불일치를 방지하기 위해 클라우드 고객의 경우 SAML NameID 어설션과 일치해야 하고, 자체 호스팅의 경우 sub OAuth2.0 클레임과 일치해야 합니다.

​
그룹 속성

LangSmith 앱 속성ID 공급자 속성매칭 우선순위
displayNamedisplayName11
externalIdobjectId
membersmembers
  1. 그룹은 그룹 명명 규칙 섹션에 설명된 명명 규칙을 따라야 합니다. 회사에 그룹 명명 정책이 있는 경우 대신 description ID 공급자 속성에서 매핑하고 그룹 명명 규칙 섹션을 기반으로 설명을 설정해야 합니다.

​
1단계 - SAML SSO 구성 (클라우드 전용)

SAML SSO 구성에는 두 가지 시나리오가 있습니다:
  1. 조직에 대해 SAML SSO가 이미 구성된 경우, 애플리케이션을 처음 추가하는 단계(Okta Integration Network에서 애플리케이션 추가 또는 새 Entra ID 애플리케이션 통합 생성)를 건너뛰어야 합니다. 이미 애플리케이션이 구성되어 있으므로 프로비저닝만 활성화하면 됩니다.
  2. SCIM과 함께 SAML SSO를 처음 구성하는 경우 먼저 SAML SSO 설정 지침을 따른 다음 여기의 지침에 따라 SCIM을 활성화합니다.

​
NameID 형식

LangSmith는 SAML NameID를 사용하여 사용자를 식별합니다. NameID는 SAML 응답의 필수 필드이며 대소문자를 구분하지 않습니다. NameID는 다음을 충족해야 합니다:
  1. 각 사용자에게 고유해야 합니다.
  2. 무작위로 생성된 고유 사용자 ID와 같이 절대 변경되지 않는 영구 값이어야 합니다.
  3. 각 로그인 시도 시 정확히 일치해야 합니다. 사용자 입력에 의존해서는 안 됩니다.
NameID는 이메일 주소나 사용자 이름이 시간이 지남에 따라 변경될 가능성이 더 높고 대소문자를 구분할 수 있으므로 이메일 주소나 사용자 이름이 아니어야 합니다. NameID 형식은 이메일과 같이 다른 형식이 필요한 필드를 사용하지 않는 한 Persistent여야 합니다.

​
2단계 - JIT 프로비저닝 비활성화

SCIM을 활성화하기 전에 자동 및 수동 사용자 프로비저닝 간의 충돌을 방지하기 위해 Just-in-time (JIT) 프로비저닝을 비활성화합니다.

​
클라우드에서 JIT 비활성화

PATCH /orgs/current/info 엔드포인트를 사용합니다: 
curl -X PATCH $LANGCHAIN_ENDPOINT/orgs/current/info \
  -H "X-Api-Key: $LANGCHAIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jit_provisioning_enabled": false}'

​
자체 호스팅에서 JIT 비활성화

LangSmith 차트 버전 0.11.14부터 SSO를 사용하는 자체 호스팅 조직에 대해 JIT 프로비저닝을 비활성화할 수 있습니다. 비활성화하려면 다음 값을 설정합니다: 
commonEnv:
  - name: SELF_HOSTED_JIT_PROVISIONING_ENABLED
    value: "false"

​
3단계 - SCIM Bearer Token 생성

자체 호스팅 환경에서 아래의 전체 URL은 https://langsmith.yourdomain.com/api/v1/platform/orgs/current/scim/tokens(하위 도메인 없이, /api/v1 경로 접두사 참고) 또는 https://langsmith.yourdomain.com/subdomain/api/v1/platform/orgs/current/scim/tokens(하위 도메인 포함)처럼 보일 수 있습니다. 자세한 내용은 ingress 문서를 참조하세요.
조직을 위한 SCIM Bearer Token을 생성합니다. 이 토큰은 IdP가 SCIM API 요청을 인증하는 데 사용됩니다. 환경 변수가 적절하게 설정되어 있는지 확인합니다. 예: 
curl -X POST $LANGCHAIN_ENDPOINT/v1/platform/orgs/current/scim/tokens \
  -H "X-Api-Key: $LANGCHAIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"description": "Your description here"}'
SCIM Bearer Token 값은 이 요청에 대한 응답 외부에서는 사용할 수 없습니다. 다음 추가 엔드포인트가 있습니다:
  • GET /v1/platform/orgs/current/scim/tokens
  • GET /v1/platform/orgs/current/scim/tokens/{scim_token_id}
  • PATCH /v1/platform/orgs/current/scim/tokens/{scim_token_id} (description 필드만 지원됨)
  • DELETE /v1/platform/orgs/current/scim/tokens/{scim_token_id}

​
4단계 - ID 공급자 구성

Azure Entra ID(이전 Azure AD) 또는 Okta를 사용하는 경우 ID 공급자 설정에 대한 구체적인 지침이 있습니다(Azure Entra ID, Okta 참조). 위의 요구 사항 및 단계는 모든 ID 공급자에 적용됩니다.

​
Azure Entra ID 구성 단계

추가 정보는 Microsoft의 문서를 참조하세요.
자체 호스팅 설치에서는 oid JWT 클레임이 sub로 사용됩니다. 추가 세부 정보는 이 Microsoft Learn 링크 및 관련 구성 지침을 참조하세요.
1단계: 엔터프라이즈 애플리케이션에서 SCIM 구성하기
  1. 권한이 있는 역할(예: Global Administrator)로 Azure 포털에 로그인합니다.
  2. 기존 LangSmith 엔터프라이즈 애플리케이션으로 이동합니다.
  3. 왼쪽 탐색 메뉴에서 Manage > Provisioning을 선택합니다.
  4. Get started를 클릭합니다.
2단계: 관리자 자격 증명 구성하기
  1. Admin Credentials 아래:
    • Tenant URL:
      • US: https://api.smith.langchain.com/scim/v2
      • EU: https://eu.api.smith.langchain.com/scim/v2
      • Self-hosted: <langsmith_url>/scim/v2
    • Secret Token: 3단계에서 생성한 SCIM Bearer Token을 입력합니다.
  2. Test Connection을 클릭하여 구성을 확인합니다.
  3. Save를 클릭합니다.
3단계: 속성 매핑 구성하기 Mappings 아래에서 다음 속성 매핑을 구성합니다: 사용자 속성 Target Object Actions를 Create 및 Update로 설정합니다(안전을 위해 Delete를 비활성화한 상태로 시작):
LangSmith 앱 속성Microsoft Entra ID 속성매칭 우선순위
userNameuserPrincipalName
activeNot([IsSoftDeleted])
emails[type eq "work"].valuemail1
name.formatteddisplayName OR Join(" ", [givenName], [surname])2
externalIdobjectId31
  1. 사용자의 이메일 주소는 Entra ID에 있어야 합니다.
  2. displayName이 Firstname Lastname 형식과 일치하지 않는 경우 Join 표현식을 사용합니다.
  3. 불일치를 방지하기 위해 SAML NameID 어설션 및 sub OAuth2.0 클레임과 일치해야 합니다. 클라우드의 SAML SSO의 경우 Unique User Identifier (Name ID) 필수 클레임은 user.objectID여야 하며 Name identifier format은 persistent여야 합니다.
그룹 속성 Target Object Actions를 Create 및 Update만으로 설정합니다(안전을 위해 Delete를 비활성화한 상태로 시작):
LangSmith 앱 속성Microsoft Entra ID 속성매칭 우선순위
displayNamedisplayName11
externalIdobjectId
membersmembers
  1. 그룹은 그룹 명명 규칙 섹션에 설명된 명명 규칙을 따라야 합니다. 회사에 그룹 명명 정책이 있는 경우 대신 description Microsoft Entra ID 속성에서 매핑하고 그룹 명명 규칙 섹션을 기반으로 설명을 설정해야 합니다.
4단계: 사용자 및 그룹 할당하기
  1. Applications > Applications에서 LangSmith 엔터프라이즈 애플리케이션을 선택합니다.
  2. Assignments 탭에서 Assign을 클릭한 다음 Assign to People 또는 Assign to Groups를 클릭합니다.
  3. 원하는 항목을 선택한 다음 Assign 및 Done을 클릭합니다.
5단계: 프로비저닝 활성화하기
  1. Provisioning 아래에서 Provisioning Status를 On으로 설정합니다.
  2. 초기 동기화를 모니터링하여 사용자 및 그룹이 올바르게 프로비저닝되었는지 확인합니다.
  3. 확인되면 사용자 및 그룹 매핑 모두에 대해 Delete 작업을 활성화합니다.
문제 해결은 SAML SSO FAQ를 참조하세요. SCIM 설정에 문제가 있으면 [email protected]로 LangChain 지원 팀에 문의하세요.

​
Okta 구성 단계

Okta Lifecycle Management 제품을 사용해야 합니다. 이 제품 계층은 Okta에서 SCIM을 사용하는 데 필요합니다.
지원되는 기능
  • 사용자 생성
  • 사용자 속성 업데이트
  • 사용자 비활성화
  • 그룹 푸시
  • 사용자 가져오기
  • 그룹 가져오기
1단계: Okta Integration Network에서 애플리케이션 추가하기
SAML(클라우드) 또는 OIDC가 있는 OAuth2.0(자체 호스팅)을 통해 SSO 로그인을 이미 구성한 경우 이 단계를 건너뜁니다.
클라우드의 경우 SAML SSO 설정 또는 자체 호스팅의 경우 OAuth2.0 설정을 참조하세요. 2단계: API 통합 구성하기
  1. General 탭에서 1단계의 지침에 따라 LangSmithUrl이 입력되었는지 확인합니다.
  2. Provisioning 탭에서 Integration을 선택합니다.
  3. Edit을 선택한 다음 Enable API integration을 선택합니다.
  4. API Token의 경우 위에서 생성한 SCIM 토큰을 붙여넣습니다.
  5. Import Groups를 선택한 상태로 유지합니다.
  6. 구성을 확인하려면 Test API Credentials를 선택합니다.
  7. Save를 선택합니다.
  8. API 통합 세부 정보를 저장한 후 왼쪽에 새 설정 탭이 나타납니다. To App을 선택합니다.
  9. Edit을 선택합니다.
  10. Create Users, Update Users 및 Deactivate Users에 대해 Enable 체크박스를 선택합니다.
  11. Save를 선택합니다.
  12. Assignments 탭에서 사용자 및/또는 그룹을 할당합니다. 할당된 사용자는 LangSmith 그룹에서 생성되고 관리됩니다.
3단계: 사용자 프로비저닝 설정 구성하기
  1. 프로비저닝 구성: Provisioning > To App > Provisioning to App에서 Edit을 클릭한 다음 Create Users, Update User Attributes 및 Deactivate Users를 선택합니다.
  2. <application_name> Attribute Mappings에서 아래와 같이 사용자 속성 매핑을 설정하고 나머지는 삭제합니다:
SCIM Okta User Attributes Mapping 4단계: 그룹 푸시하기
Okta는 그룹 이름 자체 외에는 그룹 속성을 지원하지 않으므로 그룹 이름은 그룹 명명 규칙 섹션에 설명된 명명 규칙을 반드시 따라야 합니다.
Okta의 Enable Group Push 지침에 따라 이름 또는 규칙별로 푸시할 그룹을 구성합니다.

​
기타 ID 공급자

다른 ID 공급자는 테스트되지 않았지만 SCIM 구현에 따라 작동할 수 있습니다.
Edit the source of this page on GitHub.
Connect these docs programmatically to Claude, VSCode, and more via MCP for real-time answers.
⌘I