• ID プロバイダの設定
  • Azure
  • Google ワークスペース
  • Okta
  • OneLogin
  • メタデータを使う
  • ID プロバイダの管理
    • IDプロバイダの変更
    • メールドメインの変更
• GitLab の設定
• ユーザーアクセスと管理
  • ユーザー属性
  • 既存の GitLab.com アカウントに SAML をリンクします。
  • SAMLを使ってGitLab.comにサインインします。
  • ユーザー SAML アイデンティティの管理
    • ユーザーNameIDの変更
  • SAML 応答からのユーザー設定
    • サポートされるユーザー属性
    • SAML 応答の例
  • 検証済みドメインを使用したユーザー電子メール確認のバイパス
  • ユーザーのアクセスをブロック
  • アカウントのリンク解除
• SSOの実施
  • ウェブ・アクティビティ実施のためのSSOのみ
• 関連するトピック
• トラブルシューティング

GitLab.comグループのためのSAML SSO

GitLab 11.0で導入されました。

ユーザーはSAMLアイデンティティプロバイダを通してGitLabにサインインできます。

SCIMはユーザーをGitLab.com上のグループと同期させます。

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

最上位グループのみに SAML SSO を設定できます。

ID プロバイダの設定

SAML標準は、GitLabで様々なIDプロバイダを使えることを意味します。あなたのIDプロバイダには、関連する文書があるかもしれません。それは、一般的なSAMLドキュメントであったり、GitLabに特化したものであったりします。

アイデンティティ・プロバイダを設定する際には、よくあるイシューを避けるため、また使用される用語のガイドとして、以下のプロバイダ固有のドキュメントを使用してください。

リストにない ID プロバイダについては、ID プロバイダの設定に関するインスタンス SAML ノートを参照して、プロバイダが必要とする可能性のある情報の追加ガイダンスを得ることができます。

GitLab は以下の情報をガイダンスのためだけに提供しています。SAMLアプリの設定について質問がある場合は、プロバイダのサポートに問い合わせてください。

アイデンティティ・プロバイダの設定にイシューがある場合は、トラブルシューティング・ドキュメントを参照してください。

Azure

AzureをIDプロバイダとしてSSOを設定します：

1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
2. 設定]、[SAML SSO] の順に選択します。
3. このページの情報に注意してください。

4. Azureにアクセスし、アプリケーションのSSO設定の指示に従ってください。以下のGitLabの設定はAzureのフィールドに対応しています。

   GitLab 設定	Azure フィールド
   識別子	識別子（エンティティID）
   アサーション コンシューマー サービス URL	返信URL（アサーションコンシューマーサービスURL）
   GitLab シングルサインオン URL	サインオンURL
   アイデンティティ・プロバイダのシングルサインオンURL	ログインURL
   証明書フィンガープリント	サムプリント

5. 以下の属性を設定する必要があります：
   • Unique User Identifier (Name identifier)をuser.objectIDに設定します。
   • nameid-formatをpersistentに変更します。詳細は、ユーザー SAML ID の管理方法を参照してください。
   • サポートされる属性への追加のクレーム。

6. ID プロバイダが、既存の GitLab アカウントをリンクするためのプロバイダ主導のコールを持つように設定されていることを確認してください。

7. オプション。グループ同期を使用する場合は、必要な属性に合わせてグループクレームの名前をカスタマイズします。

グループの SAML SSO を使用した Azure での SCIM プロビジョニングのデモをご覧ください。このビデオのobjectID マッピングは古いものです。代わりにSCIM ドキュメントに従ってください。

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

Google ワークスペース

Google WorkspaceをIDプロバイダとして設定します：

1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
2. 設定]、[SAML SSO] の順に選択します。
3. このページの情報に注意してください。

4. GoogleをIDプロバイダとしてSSOを設定する手順に従ってください。以下のGitLabの設定はGoogleワークスペースのフィールドに対応しています。

   GitLab 設定	Googleワークスペース欄
   識別子	エンティティID
   アサーション コンシューマー サービス URL	ACS URL
   GitLab シングルサインオン URL	開始URL
   アイデンティティ・プロバイダのシングルサインオンURL	SSO URL

5. GoogleワークスペースはSHA256フィンガープリントを表示します。GitLab がSAML を設定するために必要な SHA1 フィンガープリントを取得します：
   1. 証明書をダウンロードします。

   2. 次のコマンドを実行します：

      openssl x509 -noout -fingerprint -sha1 -inform pem -in "GoogleIDPCertificate-domain.com.pem"
      

6. これらの値を設定します：
   • プライマリ電子メールの場合email.
   • ファーストネームの場合:first_name.
   • 姓の場合:last_name.
   • 名前IDフォーマットの場合:EMAIL.
   • NameID については、Basic Information > Primary email。詳細については、ユーザー SAML ID の管理を参照してください。
7. ID プロバイダが、既存の GitLab アカウントをリンクするためのプロバイダ主導のコールを持つように設定されていることを確認してください。

GitLab SAML SSO ページで、Verify SAML Configuration を選択する際、NameID のフォーマットをpersistentに設定することを推奨する警告を無視してください。

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

Google ワークスペースに SAML を設定し、グループ同期を設定する方法のデモをご覧ください。

Okta

OktaをIDプロバイダとしてSSOを設定します：

1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
2. 設定]、[SAML SSO] の順に選択します。
3. このページの情報に注意してください。

4. Okta で SAML アプリケーションを設定する手順に従ってください。

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

   GitLab 設定	Oktaフィールド
   識別子	オーディエンスURI
   アサーション コンシューマー サービス URL	シングルサインオンURL
   GitLab シングルサインオン URL	ログインページURL(アプリケーションログインページの設定)
   アイデンティティ・プロバイダのシングルサインオンURL	アイデンティティ・プロバイダ・シングル・サインオンのURL

5. OktaシングルサインオンURL]フィールドで、[受信者URLと送信先URLにこれを使用する]チェックボックスを選択します。

6. これらの値を設定します：
   • アプリケーションユーザー名（NameID）：Custom user.getInternalProperty("id").
   • Name ID Format:Persistent。詳細は、ユーザー SAML ID の管理を参照してください。
7. ID プロバイダが、既存の GitLab アカウントをリンクするためのプロバイダ主導のコールを持つように設定されていることを確認してください。

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

SCIM を含む Okta SAML セットアップのデモについては、Demoを参照してください：Okta Group SAML & SCIM setupをご覧ください。

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

OneLogin

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

OneLoginをIDプロバイダとして設定するには：

1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
2. 設定]、[SAML SSO] の順に選択します。
3. このページの情報に注意してください。

4. OneLogin genericSAML Test Connector (Advanced) を使用する場合は、OneLogin SAML Test Connector を使用してください。以下の GitLab 設定は、OneLogin のフィールドに対応しています：

   GitLab 設定	OneLoginフィールド
   識別子	オーディエンス
   アサーション コンシューマー サービス URL	受信者
   アサーション コンシューマー サービス URL	ACS（コンシューマ）URL
   アサーション・コンシューマ・サービスURL（エスケープ版）	ACS（コンシューマ）URLバリデータ
   GitLab シングルサインオン URL	ログインURL
   アイデンティティ・プロバイダのシングルサインオンURL	SAML 2.0 エンドポイント

5. NameID にはOneLogin IDを使用します。詳細は、「manage user SAML identity」を参照してください。

6. ID プロバイダが、既存の GitLab アカウントをリンクするためのプロバイダ主導のコールを持つように設定されていることを確認してください。

メタデータを使う

いくつかの ID プロバイダを設定するには、GitLab メタデータ URL が必要です。このURLを見つけるには

1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
2. 設定]、[SAML SSO] の順に選択します。
3. GitLab メタデータの URL をコピーします。
4. ID プロバイダのドキュメントに従い、メタデータ URL が要求されたら貼り付けてください。

GitLab メタデータ URL をサポートしているかどうか、ID プロバイダーのドキュメントを確認してください。

ID プロバイダの管理

IDプロバイダーを設定したら、次のことができます：

• IDプロバイダの変更
• メールドメインの変更

IDプロバイダの変更

別の ID プロバイダに変更できます。変更プロセス中、ユーザはどの SAML グループにもアクセスできません。これを緩和するには、SSO 実施を無効にします。

ID プロバイダを変更するには

1. 新しい ID プロバイダでグループを設定します。
2. オプション。NameID が同一でない場合は、ユーザーのNameID を変更します。

メールドメインの変更

ユーザーを新しいメールドメインにマイグレーションするには、ユーザーに次のように指示します：

1. 新しい電子メールをプライマリ電子メールとしてアカウントに追加し、それを確認します。
2. オプション。アカウントから古いEメールを削除します。

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

GitLab の設定

IDプロバイダをGitLabで使えるように設定したら、GitLabがそれを認証に使うように設定しなければなりません：

1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
2. 設定]、[SAML SSO] の順に選択します。
3. フィールドを入力します：
   • ID プロバイダのシングルサインオン URL］フィールドに、ID プロバイダの SSO URL を入力します。
   • Certificate fingerprint（証明書の指紋）フィールドに、SAML トークン署名証明書の指紋を入力します。
4. 既定のメンバーシップ・ロール」フィールドで、新規ユーザに割り当てるロールを選択します。デフォルトのロールはゲストです。GitLab 13.3以降では、グループオーナーはGuest以外のデフォルトメンバーシップロールを設定することができます。そのロールは、グループに追加された全てのユーザーの開始ロールになります。
5. Enable SAML authentication for this groupチェックボックスを選択します。
6. オプション。を選択します：
   • このグループの Web アクティビティに SSO 認証のみを適用します。
   • このグループのGitアクティビティに対してSSOのみの認証を強制します。詳細については、SSO 実施のドキュメントを参照してください。
7. 変更を保存を選択します。

GitLabの設定にイシューがある場合は、トラブルシューティングドキュメントを参照してください。

ユーザーアクセスと管理

• GitLab 13.7で導入されたSAMLユーザープロビジョニング。
• GitLab 14.0 で導入された、SAML SSOまたは SCIM プロビジョニングによって作成された GitLab ユーザーは、]で表示されます。エンタープライズバッジで表示されます。

グループSSOが設定され有効になると、ユーザーはアイデンティティプロバイダのダッシュボードからGitLab.comグループにアクセスできるようになります。SCIMが設定されている場合は、SCIM ページのユーザーアクセスを参照してください。

ユーザーがグループSSOでサインインしようとすると、GitLabは以下に基づいてユーザーの検索または作成を試みます：

• SAML アイデンティティが一致する既存のユーザーを探します。これは、ユーザーがSCIMによってアカウントを作成したか、グループの SAML IdP でサインインしたことがあることを意味します。
• 同じメールアドレスを持つ競合するユーザがいない場合は、新しいアカウントを自動的に作成します。
• 同じメールアドレスで競合するユーザーがいる場合、ユーザーをサインインページにリダイレクトします：
  • 別のメールアドレスで新しいアカウントを作成します。
  • 既存のアカウントにサインインして、SAML ID をリンクします。

ユーザー属性

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

• ユーザーのメールアドレスは、emailあるいはmail属性とすることができます。
• ユーザ名はusernameまたはnickname属性です。どちらか一方だけを指定してください。

詳しくは、セルフマネジメント GitLab インスタンスで使用できる属性を参照ください。

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

GitLab 15.7で導入されたRemember meチェックボックス。

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

1. GitLab.com アカウントにサインインします。必要に応じてパスワードをリセットします。
2. サインインするグループのGitLab シングルサインオン URLを探してアクセスします。グループのオーナーは、グループのSettings > SAML SSOページでこれを見つけることができます。サインインURLが設定されていれば、ユーザーはIDプロバイダーからGitLabアプリに接続することができます。
3. オプション。Remember meチェックボックスを選択すると、GitLabに2週間サインインしたままになります。SAMLプロバイダーとの再認証をより頻繁に求められる場合があります。
4. 作成者を選択します。
5. プロンプトが表示されたら、ID プロバイダの認証情報を入力します。
6. GitLab.com にリダイレクトされ、グループにアクセスできるようになります。今後は、SAMLを使ってGitLab.comにサインインすることができます。

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

その後にGitLab.comを訪れる際には、SAML を使ってサインインするか、リンクを直接訪れてサインインすることができるはずです。強制 SSOオプションがオンになっている場合は、ID プロバイダを通してサインインするようにリダイレクトされます。

SAMLを使ってGitLab.comにサインインします。

1. ID プロバイダにサインインします。
2. アプリのリストから “GitLab.com” アプリを選択します。(名前は ID プロバイダーの管理者が設定します)。
3. GitLab.com にサインインし、グループにリダイレクトされます。

ユーザー SAML アイデンティティの管理

GitLab 15.5で導入されたSAML APIを使ったSAML IDの更新。

GitLab.com はユーザーを識別するために SAMLNameIDを使用します。NameIDは以下の通りです：

• SAML レスポンスの必須フィールドです。
• 大文字と小文字を区別します。

NameIDは必須です：

• ユーザーごとに一意であること。
• ランダムに生成される一意のユーザーIDのように、決して変更されない永続的な値であること。
• 大文字と小文字の間で変化する可能性のあるユーザー入力に依存してはいけません。

NameIDはメールアドレスやユーザ名であってはなりません：

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

NameIDの形式は、電子メールのように別の形式を必要とするフィールドを使用していない限り、Persistent でなければなりません。Transient 以外の書式を使用することもできます。

ユーザーNameIDの変更

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

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

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

1. 関連するユーザに、グループからアカウントのリンクを解除するよう依頼します。
2. 関連するユーザに、アカウントを新しい SAML アプリにリンクするよう依頼します。

特定のアイデンティティ・プロバイダに推奨される値とフォーマットの詳細については、アイデンティティ・プロバイダの設定をご覧ください。

SAML 応答からのユーザー設定

GitLab 13.7 で導入されました。

GitLab では、SAML レスポンスの値に基づいて特定のユーザー属性を設定することができます。既存のユーザーの属性は、そのユーザーが元々グループによってプロビジョニングされていた場合、SAMLレスポンスの値から更新されます。ユーザーがグループによってプロビジョニングされるのは、アカウントが作成されたときです：

• SCIM を介して。
• GitLab.com グループ用の SAML SSO で最初にサインインします。

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

• can_create_group-true またはfalse で、ユーザーが新しいグループを作成できるかどうかを示します。デフォルトはtrueです。
• projects_limit- ユーザーが作成できる個人プロジェクトの総数。値が0 の場合、ユーザーは個人ネームスペースに新しいプロジェクトを作成できません。既定値は10000 です。

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>

検証済みドメインを使用したユーザー電子メール確認のバイパス

GitLab 15.4で導入されました。

デフォルトでは、SAMLまたはSCIMでプロビジョニングされたユーザーは、本人確認のために確認メールが送信されます。その代わりに、カスタムドメインでGitLabを設定することができ、GitLabは自動的にユーザーアカウントを確認します。ユーザーには、エンタープライズ・ユーザーのウェルカム・メールが送られます。以下の両方が真である場合、確認はバイパスされます：

• ユーザーが SAML または SCIM でプロビジョニングされている場合。
• ユーザが検証済みドメインに属する電子メール・アドレスを持っていること。

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

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

• ユーザを (順番に) グループから削除します：
  1. IDプロバイダのユーザーデータストア、または特定のアプリのユーザーリスト。
  2. GitLab.com グループ。
• グループのトップレベルでグループ同期を使用し、デフォルトのロールを最小アクセスに設定すると、グループ内のすべてのリソースへのアクセスが自動的にブロックされます。

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

アカウントのリンク解除

ユーザーは、プロフィール・ページからグループの SAML リンクを解除できます。これは、以下の場合に役立ちます：

• グループに GitLab.com にサインインさせたくない場合。
• あなたのSAMLNameIDが変更されたため、GitLabがあなたのユーザーを見つけられなくなりました。

グループには少なくとも1人のオーナーが必要です。グループのオーナーが自分のアカウントだけである場合、アカウントのリンクを解除することはできません。その場合は、別のユーザーをグループのオーナーに設定してから、アカウントのリンクを解除してください。

たとえば、MyOrg アカウントのリンクを解除するには、次のようにします：

1. 左のサイドバーで、自分のアバターを選択してください。
2. プロフィールの編集を選択します。
3. 左サイドバーで「アカウント」を選択します。
4. サービスサインインセクションで、接続されているアカウントの横にある「切断」を選択します。

SSOの実施

• GitLab 11.8 で導入されました。
• GitLab 11.11では、GitLab UIで継続的に実施されるように改善されました。
• GitLab 13.8でタイムアウトのエクスペリエンスが改善されました。
• GitLab 13.8で、グループオーナーがSSOを経由しないように改善。
• GitLab 13.11で、この設定がオンになっている場合、Gitを使用するためにSSOセッションを開くことを強制するように改善。
• GitLab 14.7で、CI/CDジョブからのGitアクティビティに対してSSOチェックを行わないように改善しました。
• GitLab15.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 アイデンティティを持つユーザーが、組織のグループ階層内のグループやプロジェクトにアクセスする場合。ユーザーは、GitLab.comの認証情報を使用することで、SSOサインインなしで他のグループやプロジェクト、ユーザー設定を見ることができます。

以下のいずれか、または両方が真である場合、ユーザーは SAML アイデンティティを持っています：

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

ユーザーは訪問のたびにSSOを通してサインインするよう促されることはありません。GitLabはユーザーがSSOを通して認証したかどうかをチェックします。もしユーザーが最後にサインインしたのが24時間以上前であれば、GitLabはSSOを通して再度サインインするよう促します。

SSOは以下のように実施されます：

APIアクティビティに同様のSSO要件を追加するイシューが存在します。

ウェブ・アクティビティ実施のためのSSOのみ

Enforce SSO-only authentication for web activity for this group］オプションが有効な場合：

• すべてのメンバーは、既存のSAMLアイデンティティを持っているかどうかに関係なく、グループのリソースにアクセスするためにGitLabグループのシングルサインオンURLを使用してGitLabにアクセスする必要があります。
• SSOは、ユーザーが組織のグループ階層内のグループやプロジェクトにアクセスするときに強制されます。ユーザーは SSO サインインなしで他のグループやプロジェクトを見ることができます。
• ユーザーを手動で新規メンバーとして追加することはできません。
• オーナーロールを持つユーザーは、標準のサインインプロセスを使用して、トップレベルのグループ設定に必要な変更を行うことができます。
• 非会員またはサインインしていないユーザーの場合：
  • 公開グループリソースにアクセスしてもSSOは適用されません。
  • 非公開グループリソースにアクセスする場合は、SSOが適用されます。
• 組織のグループ階層にあるアイテムの場合、ダッシュボードの可視性は次のようになります：
  • To-Do リストの表示時に SSO が適用されます。SSO セッションの有効期限が切れている場合、To-Do 項目が非表示になり、アラートが表示されます。
  • 割り当てられたイシューのリストを表示すると、SSOが適用されます。SSOセッションの有効期限が切れている場合、イシューは非表示になります。イシュー414475は、課題が表示されるようにこの動作を変更することを提案しています。
  • あなたが担当者である、またはあなたのレビューが要求されているマージリクエストのリストを表示する場合、SSOは強制されません。SSO セッションの有効期限が切れていても、マージリクエストを見ることができます。

ウェブ アクティビティに対する SSO の強制は、有効にすると次のような効果があります：

• グループの場合、プロジェクトがフォークされていても、ユーザーはトップレベルグループ外でプロジェクトを共有できません。
• CI/CD ジョブに由来する Git アクティビティには SSO チェックが適用されません。
• 一般ユーザーと結びついていない認証情報（プロジェクトやグループのアクセストークン、デプロイキーなど）には、SSO チェックが適用されません。
• ユーザーは、依存プロキシを使用してイメージをプルする前に、SSO でサインインする必要があります。
• Enforce SSO-only authentication for Git and Dependency Proxy activity for this groupオプションを有効にすると、Git のアクティビティに関わるすべての API エンドポイントが SSO の適用対象となります。例えば、ブランチ、コミット、タグの作成や削除などです。SSHとHTTPS経由のGitアクティビティでは、ユーザーはGitLabリポジトリにプッシュしたり、リポジトリからプルしたりする前に、SSOを通じて少なくとも1つのアクティブなセッションがサインインしている必要があります。

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

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

関連するトピック

• 自己管理GitLabインスタンス用のSAML SSO
• 用語集
• SaaSと自己管理の認証比較
• インテグレーション認証で作成したユーザーのパスワード
• SAML グループ同期

トラブルシューティング

GitLabとIDプロバイダーの間で異なるSAML用語のマッチングが難しいと感じた場合：

1. アイデンティティ・プロバイダのドキュメントを確認してください。SAMLの設定例を見て、使用されている用語の情報を確認してください。
2. SAML SSO for self-managed GitLab instancesのドキュメントを確認してください。セルフマネージド GitLab インスタンスの SAML 設定ファイルは、GitLab.com のファイルよりも多くのオプションをサポートしています。セルフマネージド・インスタンス・ファイルに関する情報は、GitLab：
   • ExternalOmniAuth SAML documentation.
   • ruby-saml library.
3. プロバイダからの XML レスポンスを、内部テストで使用した XML の例と比較してください。

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