GitLab.comグループのSAML SSO

プラン: Premium、Ultimate
提供形態: GitLab.com

自己管理型GitLabについては、SAML SSO for GitLab Self-Managedを参照してください。

ユーザーは、SAML Identity Providerを使用してGitLabにサインインできます。

SCIMは、GitLab.comのグループとユーザーを同期します。

SCIMアプリでユーザーを追加または削除すると、SCIMはGitLabグループからユーザーを追加または削除します。
ユーザーがまだグループメンバーでない場合は、サインインプロセスの一部としてユーザーがグループに追加されます。

SAML SSOは、トップレベルグループに対してのみ設定できます。

Identity Providerを設定する

SAML標準は、GitLabで幅広いIdentity Providerを使用できることを意味します。Identity Providerには関連ドキュメントがある場合があります。一般的なSAMLドキュメントの場合もあれば、GitLabを対象とする場合もあります。

Identity Providerを設定するときは、使用される用語のガイドとして次のプロバイダー固有のドキュメントを参照して、一般的な問題を回避してください。

リストにないIdPについては、プロバイダーが必要とする可能性のある情報に関する追加ガイダンスとして、インスタンスSAMLのIdentity Provider設定に関する注記を参照してください。

GitLabは、ガイダンスのみを目的として、次の情報を提供します。SAMLアプリの設定に関する質問がある場合は、プロバイダーのサポートにお問い合わせください。

Identity Providerの設定で問題が発生した場合は、トラブルシューティングのドキュメントを参照してください。

Azure

AzureをIdentity ProviderとしてSSOを設定するには:

上部のバーで、検索または移動先を選択して、グループを見つけます。
設定 > SAML SSOを選択します。
このページにある情報を書き留めます。

Azureに移動して、非ギャラリーアプリケーションを作成し、アプリケーションのSSOを設定します。次のGitLab設定はAzureフィールドに対応しています。

GitLab設定	Azureフィールド
識別子	Identifier (Entity ID)
アサーションコンシューマサービスURL	Reply URL (Assertion Consumer Service URL)
GitLabシングルサインオンURL	Sign on URL
Identity ProviderのシングルサインオンURL	Login URL
証明書フィンガープリント	Thumbprint

次の属性を設定する必要があります。
- **一意のユーザー識別子（名前ID）**をuser.objectIDにします。
  - 名前識別子形式をpersistentにします。詳細については、ユーザーSAMLアイデンティティの管理を参照してください。
- 追加のクレームをサポートされる属性に追加します。
Identity Providerが、プロバイダーによって開始された呼び出しで既存のGitLabアカウントにリンクするように設定されていることを確認します。
オプション。グループ同期を使用している場合は、グループクレームの名前を必要な属性と一致するようにカスタマイズします。

SCIM Provisioning on Azure Using SAML SSO for Groups Demo（グループのSAML SSOを使用したAzureでのSCIMプロビジョニングのデモ）をご覧ください。この動画では、objectIDマッピングは古くなっています。代わりに、SCIMドキュメントに従ってください。

詳細については、Azure設定の例を参照してください。

Google Workspace

Google WorkspaceをIdentity Providerとして設定するには:

上部のバーで、検索または移動先を選択して、グループを見つけます。
設定 > SAML SSOを選択します。
このページにある情報を書き留めます。

GoogleをIdentity ProviderとしてSSOを設定するための手順に従います。次のGitLab設定はGoogle Workspaceフィールドに対応しています。

GitLab設定	Google Workspaceフィールド
識別子	Entity ID
アサーションコンシューマサービスURL	ACS URL
GitLabシングルサインオンURL	Start URL
Identity ProviderのシングルサインオンURL	SSO URL

証明書を取得すると、Google WorkspaceでSHA256フィンガープリントが表示されます。後でSHA256フィンガープリントを生成する必要がある場合は、フィンガープリントを計算するを参照してください。
これらの値を設定します。
- プライマリメールの場合: email。
- 名の場合: first_name。
- 姓の場合: last_name。
- 名前ID形式の場合: EMAIL。
- NameIDの場合: Basic Information > Primary email。詳細については、サポートされる属性を参照してください。
Identity Providerが、プロバイダーによって開始された呼び出しで既存のGitLabアカウントにリンクするように設定されていることを確認します。

GitLab SAML SSOページで、SAML設定の検証を選択したときに、NameID形式をpersistentに設定することを推奨する警告を無視します。

詳細については、Google Workspace設定の例を参照してください。

Google WorkspaceでSAMLを設定し、グループ同期を設定する方法のデモをご覧ください。

Okta

OktaをIdentity ProviderとしてSSOを設定するには:

上部のバーで、検索または移動先を選択して、グループを見つけます。
設定 > SAML SSOを選択します。
このページにある情報を書き留めます。

OktaでSAMLアプリケーションを設定するための手順に従います。

次のGitLab設定はOktaフィールドに対応しています。

GitLab設定	Oktaフィールド
識別子	Audience URI
アサーションコンシューマサービスURL	Single sign-on URL
GitLabシングルサインオンURL	Login page URL（Application Login Page設定の下）
Identity ProviderのシングルサインオンURL	Identity Provider Single Sign-On URL

OktaのSingle sign-on URL（シングルサインオンURL）フィールドで、Use this for Recipient URL and Destination URL（これを受信者URLおよび宛先URLに使用する）チェックボックスをオンにします。
これらの値を設定します。
- **アプリケーションユーザー名（NameID）**の場合: カスタムuser.getInternalProperty("id")。
- 名前ID形式の場合: Persistent。詳細については、ユーザーSAMLアイデンティティの管理を参照してください。
- メールの場合: user.emailなど。
- 追加の属性ステートメントについては、サポートされる属性を参照してください。
Identity Providerが、プロバイダーによって開始された呼び出しで既存のGitLabアカウントにリンクするように設定されていることを確認します。

App Catalogで利用可能なOkta GitLabアプリケーションは、SCIMのみをサポートします。SAMLのサポートは、イシュー216173で提案されています。

SCIMを含むOkta SAML設定のデモについては、Demo:Okta Group SAML & SCIM setup（デモ: OktaグループSAMLとSCIMの設定）をご覧ください。

詳細については、Okta設定の例を参照してください。

OneLogin

OneLoginは、独自のGitLab（SaaS）アプリケーションをサポートしています。

OneLoginをIdentity Providerとして設定するには:

上部のバーで、検索または移動先を選択して、グループを見つけます。
設定 > SAML SSOを選択します。
このページにある情報を書き留めます。

OneLoginの一般的なSAML Test Connector (Advanced)を使用する場合は、OneLogin SAML Test Connectorを使用する必要があります。次のGitLab設定はOneLoginフィールドに対応しています。

GitLab設定	OneLoginフィールド
識別子	Audience
アサーションコンシューマサービスURL	Recipient
アサーションコンシューマサービスURL	ACS (Consumer) URL
アサーションコンシューマサービスURL（エスケープされたバージョン）	ACS (Consumer) URL Validator
GitLabシングルサインオンURL	Login URL
Identity ProviderのシングルサインオンURL	SAML 2.0 Endpoint

NameIDには、OneLogin IDを使用します。詳細については、ユーザーSAMLアイデンティティの管理を参照してください。
必須およびサポートされる属性を設定します。
Identity Providerが、プロバイダーによって開始された呼び出しで既存のGitLabアカウントにリンクするように設定されていることを確認します。

詳細については、OneLogin設定の例を参照してください。

Keycloak

KeycloakをIdentity Providerとして設定するには:

上部のバーで、検索または移動先を選択して、グループを見つけます。
設定 > SAML SSOを選択します。
このページにある情報を書き留めます。
KeycloackでSAMLクライアントを作成するための手順に従います。

次のGitLab設定はKeycloakフィールドに対応しています。

GitLab設定	Keycloakフィールド
識別子	Client ID
アサーションコンシューマサービスURL	Valid redirect URIs
アサーションコンシューマサービスURL	Assertion Consumer Service POST Binding URL
GitLabシングルサインオンURL	Home URL

KeycloakでGitLabクライアントを設定します。
1. Keycloakで、Clients（クライアント）に移動し、GitLabクライアントの設定を選択します。
2. Settings（設定）タブのSAML capabilities（SAML機能）セクションで、次のようにします。
  1. Name ID format（名前ID形式）をpersistentに設定します。
  2. Force name ID format（名前ID形式の強制）をオンにします。
  3. Force POST binding（POSTバインディングの強制）をオンにします。
  4. Include AuthnStatement（AuthnStatementを含める）をオンにします。
3. Signature and Encryption（署名と暗号化）セクションで、Sign documents（ドキュメントに署名）をオンにします。
4. Keys（キー）タブで、すべてのセクションが無効になっていることを確認します。
5. Client scopes（クライアントスコープ）タブで、次のようにします。
  1. GitLabのクライアントスコープを選択します。スコープの名前はhttps://gitlab.com/groups/your-group-name-dedicatedのようになるはずです。
  2. Configure a new mapperを選択し、開いたウィンドウでUser Attributeを選択します。
  3. Add mapperページで、名前、User Attribute、およびSAML Attribute Nameフィールドをemailに設定します。
  4. Saveを選択します。
Keycloakからクライアント情報を取得します。
1. アクションドロップダウンリストで、アダプター設定のダウンロードを選択します。
2. アダプター設定のダウンロードダイアログで、ドロップダウンリストからmod-auth-mellonを選択します。
3. ダウンロードを選択します。
4. ダウンロードしたアーカイブを解凍し、idp-metadata.xmlを開きます。
5. Identity ProviderのシングルサインオンURLを取得します。
  1. <md:SingleSignOnService>タグを探します。
  2. Location属性の値を書き留めます。
6. 証明書フィンガープリントを取得します。
  1. <ds:X509Certificate>タグの値を書き留めます。
  2. 値を別のファイルにコピーし、PEM形式に変換します。これを行うには、ファイルの先頭に-----BEGIN CERTIFICATE-----を、ファイルの末尾に-----END CERTIFICATE-----を新しい行として追加します。
  3. フィンガープリントを計算します。

アサーションを設定する

これらの属性では大文字と小文字は区別されません。

少なくとも、次のアサーションを設定する必要があります。

NameID。
メール。

オプションで、SAMLアサーションの属性としてユーザー情報をGitLabに渡すことができます。

ユーザーのメールアドレスは、email属性またはmail属性にすることができます。
ユーザー名は、username属性またはnickname属性にすることができます。これらのいずれか1つだけを指定する必要があります。

使用可能な属性の詳細については、GitLab Self-ManagedのSAML SSOを参照してください。

メタデータを使用する

一部のIdentity Providerを設定するには、GitLabメタデータURLが必要です。このURLを見つけるには:

上部のバーで、検索または移動先を選択して、グループを見つけます。
設定 > SAML SSOを選択します。
指定されたGitLabメタデータURLをコピーします。
Identity Providerのドキュメントに従い、要求されたらメタデータURLを貼り付けます。

Identity ProviderがGitLabメタデータURLをサポートしているかどうかを確認するには、そのドキュメントを確認してください。

Identity Providerを管理する

Identity Providerを設定した後、次のことができます。

Identity Providerを変更します。
Eメールのドメインを変更します。

Identity Providerを変更する

別のIdentity Providerに変更できます。変更処理中、ユーザーはSAMLグループにアクセスできません。これを軽減するには、SSOの強制を無効にすることができます。

Identity Providerを変更するには:

新しいIdentity Providerでグループを設定します。
オプション。NameIDが同一でない場合は、ユーザーのNameIDを変更します。

Eメールドメインを変更する

ユーザーを新しいEメールのドメインに移行するには、次の手順を実行するようにユーザーに指示します。

新しいメールをアカウントにプライマリメールとして追加して、検証します。
オプション。アカウントから古いメールを削除します。

NameIDがメールアドレスで設定されている場合は、ユーザーのNameIDを変更します。

GitLabを設定する

GitLabでIdentity Providerを使用するように設定したら、認証に使用するようにGitLabを設定する必要があります。

上部のバーで、検索または移動先を選択して、グループを見つけます。
設定 > SAML SSOを選択します。
フィールドに入力します:
- アイデンティティプロバイダのシングルサインオンURLフィールドに、Identity ProviderからのSSO URLを入力します。
- 証明書のフィンガープリントフィールドに、SAMLトークン署名証明書フィンガープリントを入力します。
GitLab.comのグループの場合: デフォルトのメンバーシップロールフィールドで、以下を選択します。
1. 新しいユーザーに割り当てるロール。
2. SAMLグループリンクがグループに設定されているときに、マップされたSAMLグループのメンバーではないユーザーに割り当てるロール。
GitLab Self-Managedインスタンスのグループの場合: デフォルトのメンバーシップロールフィールドで、新しいユーザーに割り当てるロールを選択します。デフォルトロールはゲストです。そのロールは、グループに追加されたすべてのユーザーの開始ロールになります。
- GitLab 16.7以降では、グループのオーナーはカスタムロールを設定できます。
- GitLab 16.6以前では、グループオーナーは、デフォルトのメンバーシップロールとして、ゲスト以外のデフォルトのメンバーシップロールを設定できます。
このグループのSAML認証を有効にしますチェックボックスを選択します。
推奨。以下を選択します。
- GitLab 17.4以降では、Enterpriseユーザーのパスワードとパスキーの認証を無効にする。詳細については、Enterpriseユーザーのパスワードとパスキーの認証に関するドキュメントを参照してください。
- このグループのWEBアクティビティにSSOのみの認証を適用します。
- このグループのGitおよび依存プロキシのアクティビティに対してSSOのみの認証を実施する。詳細については、SSOの強制に関するドキュメントを参照してください。
変更を保存を選択します。

GitLabの設定で問題が発生した場合は、トラブルシューティングドキュメントを参照してください。

ユーザーアクセスと管理

グループSSOが設定され、有効になった後、ユーザーはIdentity ProviderのダッシュボードからGitLab.comグループにアクセスできます。SCIMが設定されている場合は、SCIMページのユーザーアクセスを参照してください。

ユーザーがグループSSOでサインインしようとすると、GitLabは次の情報に基づいてユーザーを検索または作成しようとします。

一致するSAMLアイデンティティを持つ既存のユーザーを検索します。これは、ユーザーのアカウントがSCIMによって作成されたか、グループのSAML IdPで以前にサインインしたことを意味します。
同じメールアドレスのアカウントがまだ存在しない場合は、新しいアカウントを自動的に作成します。GitLabは、プライマリとセカンダリの両方のメールアドレスを照合しようとします。
同じメールアドレスのアカウントが既に存在する場合は、サインインページにリダイレクトして、次の操作を行います。
- 別のメールアドレスで新しいアカウントを作成します。
- 既存のアカウントにサインインして、SAML IDをリンクします。

プロビジョニングの動作（制限付きアクセス）

この機能は機能フラグによって制御されます。詳細については、履歴を参照してください。

制限付きアクセスが利用可能なシートなしで有効になっている場合、SAMLを介してプロビジョニングされたユーザーには最小アクセスロールが割り当てられます。

詳細については、SAML、SCIM、およびLDAPによるプロビジョニングの動作を参照してください。

SAMLを既存のGitLab.comアカウントにリンクする

ユーザーがそのグループのエンタープライズユーザーである場合、以下の手順は適用されません。代わりに、EnterpriseユーザーはGitLabアカウントと同じメールアドレスを持つSAMLアカウントでサインインする必要があります。これにより、GitLabはSAMLアカウントを既存のアカウントにリンクできます。

SAMLを既存のGitLab.comアカウントにリンクするには:

GitLab.comアカウントにサインインします。必要に応じて、パスワードをリセットします。
サインインするグループのGitLabシングルサインオンURLを見つけてアクセスします。グループオーナーは、グループの設定 > SAML SSOページでこれを見つけることができます。サインインURLが設定されている場合、ユーザーはIdentity ProviderからGitLabアプリケーションに接続できます。
オプション。ログイン情報を記憶するチェックボックスを選択すると、GitLabへのサインイン状態が2週間維持されます。SAMLプロバイダーによる再認証が、より頻繁に求められる場合があります。
許可するを選択します。
プロンプトが表示されたら、Identity Providerで認証情報を入力します。
その後、GitLab.comにリダイレクトされ、グループにアクセスできるようになります。今後は、SAMLを使用してGitLab.comにサインインできます。

ユーザーが既にグループのメンバーである場合、SAML IDをリンクしてもロールは変更されません。

以降のアクセスでは、SAMLでGitLab.comにサインインするか、リンクに直接アクセスできるようになります。SSOの強制オプションがオンになっている場合は、Identity Provider経由でサインインするようにリダイレクトされます。

エンタープライズユーザーの自動IDリンク

Enterpriseユーザーがグループから削除された後、復帰した場合、エンタープライズSSOアカウントでサインインできます。Identity Providerのユーザーのメールアドレスが既存のGitLabアカウントのメールアドレスと同じままである限り、SSO IDはアカウントに自動的にリンクされ、ユーザーは問題なくサインインできます。この機能は、エンタープライズユーザーとして要求されたが、まだグループにサインインしていない既存のユーザーにも適用されます。

Identity Providerにサインインします。
アプリケーションのリストから、「GitLab.com」アプリケーションを選択します（名前は、Identity Providerの管理者によって設定されます）。
その後、GitLab.comにサインインすると、グループにリダイレクトされます。

ユーザーSAML IDの管理

GitLab.comは、SAML NameIDを使用してユーザーを識別します。NameIDは、次のとおりです。

SAML応答の必須フィールド。
大文字と小文字を区別しません。

NameIDは、次の条件を満たす必要があります。

各ユーザーに固有であること。
ランダムに生成された一意のユーザーIDなど、決して変更されない永続的な値であること。
以降のサインイン試行で完全に一致させる必要があります。大文字と小文字の間で変化する可能性のあるユーザーインプットに依存しないでください。

NameIDは、次の理由により、メールアドレスまたはユーザー名にしないでください。

メールアドレスとユーザー名は、時間の経過とともに変更される可能性が高くなります。たとえば、人の名前が変わる場合などです。
メールアドレスでは大文字と小文字が区別されないため、ユーザーがサインインできなくなる可能性があります。

NameID形式は、別の形式を必要とするメールなどのフィールドを使用していない限り、Persistentである必要があります。Transientを除く、任意の形式を使用できます。

ユーザーNameIDを変更する

グループオーナーは、SAML APIを使用して、グループメンバーのNameIDを変更し、SAML IDを更新できます。

SCIMが設定されている場合、グループオーナーはSCIM APIを使用してSCIM IDを更新できます。

または、ユーザーにSAMLアカウントの再接続を依頼します。

関係するユーザーに、アカウントをグループからアンリンクするように依頼します。
関係するユーザーに、アカウントを新しいSAMLアプリケーションにリンクするように依頼します。

GitLabにSSO SAMLを使用してサインインした後、NameIDの値を変更すると、設定が壊れ、ユーザーがGitLabグループからロックアウトされる可能性があります。

特定のIdentity Providerに推奨される値と形式の詳細については、Identity Providerのセットアップを参照してください。

SAMLレスポンスからEnterpriseユーザー設定を構成する

GitLabでは、SAML応答の値に基づいて、特定のユーザー属性を設定できます。既存のユーザーの属性は、そのユーザーがグループのEnterpriseユーザーである場合、SAML応答の値から更新されます。

サポートされているユーザー属性

can_create_group - エンタープライズユーザーが新しいトップレベルグループを作成できるかどうかを示すtrueまたはfalse。デフォルトはtrueです。
projects_limit - エンタープライズユーザーが作成できる個人プロジェクトの合計数。0の値は、ユーザーが自分の個人ネームスペースに新しいプロジェクトを作成できないことを意味します。デフォルトは100000です。
SessionNotOnOrAfter - ユーザーのSAMLセッションを終了する時期を示すISO 8601タイムスタンプ値。

SAML応答の例

SAML応答は、ブラウザのデベロッパーツールまたはコンソールで、base64エンコード形式で確認できます。任意のbase64デコードツールを使用して、情報をXMLに変換します。SAML応答の例を次に示します。

   <saml2:AttributeStatement>
      <saml2:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
         <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">user.email</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="username" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">user.nickName</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="first_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
         <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">user.firstName</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="last_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
         <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">user.lastName</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="can_create_group" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
         <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">true</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="projects_limit" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
         <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">10</saml2:AttributeValue>
      </saml2:Attribute>
   </saml2:AttributeStatement>

SAMLセッションのタイムアウトをカスタマイズする

デフォルトでは、GitLabのSAMLセッションは24時間後に終了します。SAML2 AuthnStatementのSessionNotOnOrAfter属性を使用して、この期間をカスタマイズできます。この属性には、ユーザーセッションを終了するタイミングを示すISO 8601タイムスタンプ値が含まれています。指定された場合、この値はSAMLセッションのデフォルトのタイムアウト（24時間）をオーバーライドします。

デフォルトでは、GitLabは7日間（10080分）の非アクティブ状態の後でセッションを終了します。SessionNotOnOrAfterタイムスタンプがこの時刻より後の場合、ユーザーはセッションが終了したときに再認証する必要があります。

レスポンス例

   <saml:AuthnStatement SessionIndex="WDE5aBYjNEj_9IjCFiK0E1YelZT" SessionNotOnOrAfter="2025-08-25T01:23:45.067Z" AuthnInstant="2025-08-24T13:23:45.067Z">
      <saml:AuthnContext>
         <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
      </saml:AuthnContext>
   </saml:AuthnStatement>

検証済みドメインによるユーザーメール確認を回避する

デフォルトでは、SAMLまたはSCIMでプロビジョニングされたユーザーには、IDを検証するための検証メールが送信されます。代わりに、GitLabをカスタムドメインで設定すると、GitLabはユーザーアカウントを自動的に確認します。ユーザーは引き続きEnterpriseユーザーのウェルカムメールを受信します。次の両方が当てはまる場合、確認は回避されます。

ユーザーはSAMLまたはSCIMでプロビジョニングされる。
ユーザーのメールアドレスが検証済みドメインに属している。

Enterpriseユーザーのパスワードとパスキーの認証を無効にする

前提条件:

Enterpriseユーザーが所属するグループのオーナーロールを持っている必要があります。
グループSSOを有効にする必要があります。

グループのすべてのエンタープライズユーザーのパスワード認証を無効にできます。これは、グループの管理者であるエンタープライズユーザーにも適用されます。この設定を構成すると、Enterpriseユーザーはパスワードの変更、リセット、またはパスワードによる認証ができなくなります。代わりに、これらのユーザーは以下で認証できます。

GitLab Web UIのグループSAML IdP。
グループでEnterpriseユーザーのパーソナルアクセストークンが無効になっている場合を除き、GitLab APIおよびHTTP基本認証を使用するGitのパーソナルアクセストークン。

Enterpriseユーザーのパスワードとパスキーの認証を無効にするには:

上部のバーで、検索または移動先を選択して、グループを見つけます。
設定 > SAML SSOを選択します。
設定の下で、Enterpriseユーザーのパスワードとパスキーの認証を無効にするを選択します。
変更を保存を選択します。

ユーザーアクセスのブロック

SAML SSOのみが設定されている場合に、ユーザーのグループへのアクセスを取り消すには、次のいずれかの操作を行います。

ユーザーを以下から（順番に）削除します。
1. Identity Providerのユーザーデータストアまたは特定のアプリケーションのユーザーリスト。
2. GitLab.comグループ。
最小アクセスに設定されたデフォルトロールを使用して、グループのトップレベルでグループ同期を使用し、グループ内のすべてのリソースへのアクセスを自動的にブロックします。

SCIMも使用している場合に、ユーザーのグループへのアクセスを取り消すには、アクセスの削除を参照してください。

アカウントのアンリンク

ユーザーは、プロファイルページからグループのSAMLをアンリンクできます。これは、次の場合に役立ちます。

グループがGitLab.comへのサインインを許可されないようにする場合。
SAML NameIDが変更されたため、GitLabがユーザーを見つけられなくなった場合。

アカウントのリンクを解除すると、そのユーザーにグループで割り当てられていたすべてのロールが削除されます。ユーザーがアカウントを再リンクする場合、ロールを再割り当てする必要があります。

グループには、少なくとも1人のオーナーが必要です。アカウントがグループ内の唯一のオーナーである場合、アカウントのアンリンクは許可されません。その場合は、別のユーザーをグループオーナーとして設定してから、アカウントをアンリンクできます。

たとえば、MyOrgアカウントをアンリンクするには:

右上隅で、アバターを選択します。
プロファイルを編集を選択します。
左側のサイドバーで、アカウントを選択します。
サインインに利用するサービスセクションで、接続されているアカウントの横にある切断を選択します。

SSOの強制

GitLab 15.5で、transparent_sso_enforcementフラグとともに、SSOの強制が有効になっていない場合でも透過的な強制を含めるように改善されました。GitLab.comで無効になりました。
GitLab 15.8で、GitLab.comでの透過的なSSOがデフォルトで有効になるようにで改善されました。
GitLab 15.10で一般提供になりました。機能フラグtransparent_sso_enforcementは削除されました。

GitLab.comでは、SSOが次の場合に強制されます。

SAML SSOが有効になっている場合。
組織のグループ階層内のグループとプロジェクトにアクセスするときに、既存のSAML IDを持つユーザーの場合。GitLab.comの認証情報を使用することで、ユーザーはSAML SSOを使用してサインインしなくても、組織外の他のグループやプロジェクト、およびユーザー設定を表示できます。

ユーザーは、次のいずれかまたは両方が当てはまる場合に、SAML IDを持ちます。

GitLabグループのシングルサインオンURLを使用してGitLabにサインインしたことがある。
SCIMによってプロビジョニングされた。

ユーザーはアクセスするたびにSSOによるサインインを求められることはありません。GitLabは、ユーザーがSSOを使用して認証されているかどうかを確認します。ユーザーが最後にサインインしてから24時間以上経過した場合、GitLabはSSOを使用して再度サインインするように求めます。

SSOは次のように強制されます。

プロジェクト/グループの表示レベル	SSOの強制設定	IDを持つメンバー	IDを持たないメンバー	メンバーではないか、サインインしていない
非公開	オフ	強制	強制されない	強制されない
非公開	オン	強制	強制	強制
公開	オフ	強制	強制されない	強制されない
公開	オン	強制	強制	強制されない

SSO強制はAPIリクエストには適用されません。ただし、パスワードベースのAPIアクセスを防ぐために、Enterpriseユーザーのパスワードとパスキーの認証を無効にすることができます。

イシューでは、APIアクティビティに対するSSO強制の追加が提案されています。

WEBアクティビティのSSOのみ強制

このグループのWEBアクティビティにSSOのみの認証を適用しますオプションが有効になっている場合:

すべてのメンバーは、既存のSAML IDを持っているかどうかに関係なく、GitLabグループのシングルサインオンURLを使用してGitLabにアクセスし、グループリソースにアクセスする必要があります。
SSOは、ユーザーが組織のグループ階層内のグループおよびプロジェクトにアクセスするときに強制されます。ユーザーは、SAML SSOを使用してサインインしなくても、組織外の他のグループやプロジェクトを表示できます。
ユーザーを新しいメンバーとして手動で追加することはできません。
オーナーロールを持つユーザーは、標準のサインインプロセスを使用して、トップレベルグループの設定に必要な変更を加えることができます。
メンバーではないユーザー、またはサインインしていないユーザーの場合:
- パブリックグループのリソースにアクセスする場合、SSOは強制されません。
- プライベートグループのリソースにアクセスする場合、SSOは強制されます。
組織のグループ階層内のアイテムの場合、ダッシュボードの表示レベルは次のようになります。
- To-Doリストを表示する場合、SSOが強制されます。SSOセッションが期限切れになるとTo Doアイテムが非表示になり、アラートが表示されます。
- 割り当て済みのイシューのリストを表示する際に、SSOが適用されます。SSOセッションが期限切れになると、イシューは非表示になります。イシュー414475では、イシューが表示されるように、この動作を変更することが提案されています。
- 自分が担当者またはレビュアーである場合、マージリクエストを表示する際に、SSOは強制されません。SSOセッションが期限切れになった場合でも、マージリクエストを表示できます。
- ゲスト、プランナー、レポーター、デベロッパー、メンテナー、またはオーナーロールを持つプライベートプロジェクトのスニペットを表示する場合、SSOは強制されません。

WEBアクティビティに対するSSOの強制を有効にすると、次の影響があります。

グループの場合、プロジェクトがフォークされている場合でも、ユーザーはトップレベルグループ外でグループ内のプロジェクトを共有できません。
CI/CDジョブから発生するGitアクティビティには、SSOチェックは強制されません。
通常のユーザーに関連付けられていない認証情報（たとえば、プロジェクトおよびグループアクセストークン、サービスアカウント、デプロイキー）には、SSOチェックは強制されません。
ユーザーは、依存プロキシを使用してイメージをプルするには、SSOを使用してサインインする必要があります。
このグループのGitおよび依存プロキシのアクティビティに対してSSOのみの認証を実施するオプションを有効にすると、Gitアクティビティに関連するAPIエンドポイントはすべてSSO強制の対象になります。たとえば、ブランチ、コミット、タグの作成または削除などです。SSHおよびHTTPS経由のGitアクティビティの場合、ユーザーがGitLabリポジトリにプッシュまたはプルするには、SSOを使用してサインインしたアクティブなセッションが少なくとも1つ必要です。アクティブなセッションは、別のデバイス上にある可能性があります。

ウェブアクティビティに対するSSOが強制されている場合、非SSOグループメンバーはすぐにアクセスを失うわけではありません。ユーザーは次のようになります。

アクティブなセッションを持っている場合、Identity Providerのセッションがタイムアウトするまで、グループへのアクセスを最大24時間継続できます。
サインアウトした場合、Identity Providerから削除された後はグループにアクセスできません。

リポジトリのミラーリングとSSO強制

このグループのGitおよび依存プロキシのアクティビティに対してSSOのみの認証を実施するを有効にすると、リポジトリのミラーリングはSSOセッション要件の対象となります。詳細については、プルミラーリング (SSO強制あり) を参照してください。

新しいIdentity Providerへの移行

新しいIdentity Providerに移行するには、SAML APIを使用して、すべてのグループメンバーのIDを更新します。

例:

メンテナンス期間を設定して、その時点でアクティブなユーザーがいないようにします。
各ユーザーのIDを更新するには、SAML APIを使用します。
新しいIdentity Providerを設定します。
サインインが機能することを確認します。

トラブルシューティング

GitLabとIdentity Provider間で異なるSAML用語を対応させるのが難しい場合:

Identity Providerのドキュメントを確認してください。使用する用語に関する情報について、SAML設定の例をご覧ください。
GitLab Self-ManagedドキュメントのSAML SSOを確認してください。GitLab Self-Managed SAML設定ファイルは、GitLab.comファイルよりも多くのオプションをサポートしています。GitLab Self-Managedインスタンスファイルに関する情報は、以下をご覧ください。
- 外部のOmniAuth SAMLドキュメント。
- ruby-samlライブラリ。
プロバイダーからのXMLレスポンスと、内部テストで使用されるXMLの例を比較します。

その他のトラブルシューティング情報については、SAMLのトラブルシューティングガイドを参照してください。