認証設定の構成
TeamCity は内部データベースを介してユーザーを認証できます。また、システムに統合して、Windows ドメイン、LDAP、Git ホスティングプロバイダーなどの外部認証ソースを使用することもできます。
認証モジュール
認証は 管理 | 認証 ページで構成されます。 現在使用されている認証モジュールも表示されます。
TeamCity には、最も一般的なユースケースに対応するため、事前構成済みの認証オプション (プリセット) がいくつか用意されています。 プリセットは、TeamCity でサポートされている認証モジュールの組み合わせです：
TeamCity に初めてサインインすると、組み込み認証モジュールと Basic HTTP 認証モジュールを含むデフォルト認証が有効化されます。
既存の設定を変更するには、有効な認証モジュールの説明の横にある 編集 をクリックします。
別の事前設定されたスキームに切り替えるには、 プリセットを読み込む ボタンを使用します。
プリセットの使用
事前設定されたモジュールのセットをロードするには、 プリセットを読み込む ボタンを使用し、必要なオプションを選択して、変更を 適用 します。 次のプリセットを使用できます。
複数の認証モジュールの有効化
TeamCity では、複数の認証モジュールを同時に有効化できます。
ユーザーがサインインを試行すると、モジュールが一つずつ試されます。 いずれかのモジュールでユーザーが認証されるとログインは成功します。すべて失敗した場合、ユーザーは TeamCity にサインインできません。
内部認証と外部認証を組み合わせて使用することができます。 推奨される方法は、まず内部従業員用に LDAP 統合 を構成し、その後、外部ユーザー用に 組み込み認証を追加することです。 TeamCity 2020.2 以降では、OAuth サービス経由の認証も有効化できます。
モジュールを追加するには:
モジュールを追加 をクリックし、ドロップダウンメニューからモジュールを選択します。
モジュールを追加 ダイアログのチェックボックスを選択して、モジュールで使用可能なプロパティを使用します。
変更を 適用 および 保存 をクリックします。
一般認証設定
一般設定 ブロックでは、次のことができます。
サーバーでゲストログインを有効にし、ゲストユーザー名を変更します。 このオプションを有効にする前に、 セキュリティに関する注意事項を参照してください。
ログインフォームの表示をカスタマイズする: 紹介テキストを入力し、デフォルトのユーザー名/パスワードフィールドを非表示にします (サードパーティサービス経由の認証を使用する場合に便利です)。
プロジェクトごとの承認モードを有効にします。
二要素認証を有効にします。
すべての TeamCity ユーザーに対して メール検証を強制します。
現在サインインしているすべてのユーザーをログアウトし、すべての パーソナルアクセストークンを削除します。
ユーザー認証設定
TeamCity サーバーは初回起動時にユーザー (および管理者) がいない状態で起動するため、最初のユーザーには管理者アカウントの確認が求められます。 管理者アカウントの入力を求められない場合は、 管理者パスワードを取得する方法で解決策を確認してください。
TeamCity 管理者は、各ユーザーのプロファイリングページでそのユーザーの認証設定を変更できます。
TeamCity のユーザー一覧と認証モジュールは、外部資格情報をユーザーにマッピングするだけです。 つまり、入力された資格情報が同じ TeamCity ユーザーにマッピングされていれば、単一の TeamCity ユーザーが異なるモジュールを使用して認証できます。 認証モジュールには、外部ユーザーデータを TeamCity ユーザーにマッピングする方法の構成があり、一部では TeamCity ユーザーのプロファイリング上の外部ユーザーリンクデータを編集できます。
バンドルされた認証モジュールによるユーザーマッピングの処理
組み込み認証は、各ユーザーについて TeamCity が管理するパスワードを保存します。
Windows ドメイン認証では、デフォルトドメインを指定でき、ドメインアカウントのお名前が TeamCity ユーザーと同じであると想定されます。 ドメインアカウントは、ユーザープロファイルページで編集できます。
LDAP 統合では、ユーザーの LDAP エントリから TeamCity ユーザー名を取得するための LDAP プロパティを設定できます。
Git ホスティングプロバイダーに対応するモジュールを使用すると、管理者はユーザー名を使用してユーザーを外部アカウントにマッピングできます。 各ユーザーは、自分のプロファイルを プロフィール | 一般 | 認証設定 の外部 Git ホスティングアカウントに接続できます。
認証設定を変更する際は注意してください。認証モジュールの変更後に管理者がサインインできなくなる場合があります。
管理者の TeamCity ユーザー名が "jsmith" で、デフォルト認証を使用していたとします。 その後、認証モジュールが Windows ドメイン認証に変更されました (つまり、Windows ドメイン認証モジュールが追加され、デフォルトのモジュールが除去されました)。 たとえば、その管理者の Windows ドメインユーザー名が "john.smith" の場合、以後サインインできなくなります。既定の認証は無効になっているため使用できず、Windows ドメイン認証も Windows ドメインユーザー名が TeamCity ユーザー名と一致しないため使用できません。 とはいえ、ソリューションは非常に簡単です。管理者は スーパーユーザーアカウントを使用してサインインし、TeamCity ユーザー名を変更するか、自分のプロファイルページで Windows ドメインユーザー名を指定できます。
特殊なユーザーアカウント
デフォルトでは、TeamCity には最大権限を持つ スーパーユーザー アカウントと、最小権限を持つ ゲストユーザー があります。 これらのアカウントは、特定の人物に関連するものではなく、特別な使用例を目的としているため、 変更 ページやプロファイル情報などの個人設定はありません。
資格情報認証モジュール
組み込み認証
デフォルトでは、TeamCity は組み込み認証を使用し、ユーザーとそのパスワードを自身で管理します。
TeamCity に初めてサインインすると、TeamCity ユーザー名とパスワードを作成するよう確認され、それらは TeamCity に保存されて認証に使用されます。 TeamCity をインストールしてサインインした場合、組み込み認証が有効化されており、すべてのユーザーデータが TeamCity に保存されていることを意味します。
最初は、ユーザーデータベースは空です。 新しいユーザーは、 TeamCity 管理者によって追加されるか、認証モジュール設定で対応するオプションが有効化されている場合にユーザー自身が登録します。 新しく作成されたすべてのユーザーは すべてのユーザーグループに属し、このグループに割り当てられたすべてのロールを持ちます。 新しく登録されたユーザーに特定の ロールが必要な場合は、これらのロールを すべてのユーザー グループ経由で 付与する必要があります。
デフォルトでは、ユーザーは自分のプロファイルページで自分のパスワードを変更できます。
トークンベース認証
トークンベースの認証モジュールを使用すると、ユーザーは自分で作成および無効化できる アクセストークンを使用して認証できます。 この認証モジュールはデフォルトで有効になっています。
Windows ドメイン認証
Windows ドメインのお名前とパスワードを使用してユーザーがサインインできるようにします。 TeamCity はこれらの資格情報を確認します。サーバーは、ユーザーがサインインに使用するドメインを認識している必要があります。 ユーザー名でサポートされている構文は DOMAIN\ユーザー.お名前 または <ユーザー名>@<ドメイン> です。
ログインフォームを使用したサインインに加えて、 NTLM HTTP 認証シングルサインオンを有効化できます。
"Microsoft Windows Domain" プリセットを選択すると、Windows ドメイン経由のログインに加えて、 Basic HTTP および NTLM 認証モジュールがデフォルトで有効化されます。
デフォルトドメインの指定
ユーザーがユーザー名の一部としてドメインを指定せずにログインフォームを使用してシステムに入ることができるようにするには、次の手順を実行します。
管理 | 認証 に移動します。
Microsoft Windows ドメイン 認証の説明の横にある 編集 をクリックします。
デフォルトドメインフィールドに名前を設定します。
変更を 完了 および 保存 をクリックします。
ログイン時の新規ユーザー登録
デフォルト設定では、ユーザーがログインページから登録できます。 新規ユーザーの TeamCity ユーザー名は、その Windows ドメインアカウントと同じになります。
新しく作成されたすべてのユーザーは すべてのユーザー グループに属し、このグループに割り当てられたすべてのロールを持ちます。 新しく登録されたユーザーに特定の ロールが必要な場合は、これらのロールを すべてのユーザー グループ経由で 付与する必要があります。
ログイン時に新規ユーザー登録を無効にするには
管理 | 認証 に移動します。
Microsoft Windows ドメイン 認証の説明の横にある 編集 をクリックします。 ログインページからユーザー登録を許可するボックスをクリアします。
NTLM HTTP 認証の説明の横にある 編集 をクリックします。 ログインページからユーザー登録を許可するボックスをクリーンアップします。
Linux 固有の構成
TeamCity サーバーが Linux 上で実行されている場合、Windows ドメインログインには JCIFS ライブラリが使用されます。 これは、SMB (SMBv1) が有効化されている Windows ドメインサーバーのみをサポートします。 SMB2 はサポートされていません。
ライブラリは、 <TeamCity データディレクトリ>/config/ntlm-config.properties ファイルで指定されたプロパティを使用して構成されます。 ファイルへの変更は、サーバーを再起動しなくてもすぐに有効になります。
実行時に変更できない JCIFS ライブラリ設定、または HTTP NTLM 設定に影響を与える設定は、 -Djcifs.プロパティ JVM オプションを介して渡されるプロパティのファイルを介してのみ設定できます。
デフォルト設定が環境で機能しない場合は、利用可能なすべての構成プロパティについて JCIFS を参照してください。
ライブラリが認証先のドメインコントローラーを見つけられない場合は、WINS サーバーのアドレスを指定して ntlm-設定.プロパティ ファイルに jcifs.netbios.wins プロパティを追加することを検討してください。 その他のドメインサービス検出プロパティについては、 JCIFS を参照してください。
LDAP 認証
専用ページをご参照ください。
HTTP / SSO 認証モジュール
基本 HTTP 認証
基本 HTTP 認証の詳細については、 HTTP によるサーバーへのアクセスを参照してください。
NTLM HTTP 認証
専用ページをご参照ください。
Bitbucket Cloud
ユーザーは Bitbucket Cloud アカウントで TeamCity にサインインできます。
このモジュールを有効にする前に、ルートプロジェクトの設定で Bitbucket クラウド接続を構成し、Bitbucket で専用アプリケーションを構成する必要があります。
サインインするには、ログインフォームの上にある Bitbucket アイコンをクリックし、リダイレクト後に TeamCity アプリケーションを承認します。 Bitbucket メールを持つユーザーが登録されており、このメールが TeamCity 内 と Bitbucket の両方で検証されている場合、この Bitbucket アカウントは対応する TeamCity ユーザーにマッピングされ、サインインします。 それ以外の場合、 最初のログイン時に新しいユーザーの作成を許可する オプションが無効になっていない限り、TeamCity は新しいユーザープロファイルを作成します。 既存の TeamCity ユーザーをマッピングすることも、Bitbucket Cloud プロファイリングに対して可能です。
設定 | 説明 |
|---|---|
最初のログイン時に新しいユーザーの作成を許可する | デフォルトで有効になっています。 このオプションが無効な場合、提供された外部メールが認識されないと、TeamCity は新しいユーザーを作成しません。 公開されている TeamCity サーバーを使用しており、そのサーバーへのアクセスを制限したい場合に役立ちます。 |
任意の Bitbucket ユーザーのログインを許可 | デフォルトでは無効です。 このオプションが有効化されている場合、任意のワークスペースのユーザーが TeamCity サーバーにアクセスできます。 特定のワークスペースへのアクセスを制限するには、代わりに 認証を制限する設定を使用します。 |
認証を制限する | ワークスペース(英語)の ID のコンマ区切りのリスト。 このリストは、Bitbucket Cloud アカウントで TeamCity に登録または認証できるユーザー設定を、指定したワークスペースに制限します。 最初のログイン時に新しいユーザーの作成を許可する オプションと組み合わせると、この設定により、指定されたワークスペースのいずれかにメールを持ち、TeamCity にユーザーのプロファイリングを持たないユーザーを自動的に登録できます。 |
GitHub
ユーザーは GitHub.com および GitHub Enterprise アカウントで TeamCity にサインインできます。 TeamCity はこのタスク用に三つの独立したモジュールを提供します。
GitHub.com モジュールでは、ルートプロジェクトの OAuth GitHub.com 接続を作成する必要があります。
GitHub エンタープライズ モジュールでは、ルートプロジェクトの OAuth GitHub エンタープライズ接続を作成する必要があります。
GitHub アプリ モジュールでは、ルートプロジェクトの GitHub アプリを作成する必要があります。 この接続タイプは、GitHub.com と GitHub Enterprise の両方のユーザーが利用できます。
サインインするには、ユーザーはユーザー名フィールドの上にある GitHub アイコンをクリックする必要があります。 この GitHub メールを持つユーザーがすでに登録されており、そのメールが TeamCity 内 と GitHub の両方で検証されている場合、ユーザーの GitHub アカウントは対応する TeamCity ユーザーにマッピングされ、このユーザーはサインインします。
それ以外の場合、TeamCity は新しいユーザーのプロファイリングを作成します。 対応する認証モジュール設定でこの動作を無効にすることができます。 この場合、すでに登録されているユーザーのみがサインインできます。 既存の TeamCity ユーザーをマッピングすることも、GitHub.com プロファイリングに対して可能です。
3 つのモジュールはすべて同じ設定になっています。
設定 | 説明 |
|---|---|
最初のログイン時に新しいユーザーの作成を許可する | デフォルトで有効になっています。 このオプションが無効な場合、提供された外部メールが認識されないと、TeamCity は新しいユーザーを作成しません。 公開されている TeamCity サーバーを使用しており、そのサーバーへのアクセスを制限したい場合に役立ちます。 |
任意の GitHub ユーザーのログインを許可 | デフォルトでは無効です。 このオプションが有効化されている場合、任意の組織のユーザーが TeamCity サーバーにアクセスできます。 特定の組織へのアクセスを制限するには、代わりに 認証を制限する設定を使用します。 |
認証を指定した組織のユーザーに制限する | 組織(英語)の ID のコンマ区切りのリスト。 このリストは、GitHub アカウントで TeamCity に登録または認証できるユーザー設定を、指定した組織に制限します。 最初のログイン時に新しいユーザーの作成を許可する オプションと組み合わせると、この設定により、指定された組織のいずれかにメールを持ち、TeamCity にユーザーのプロファイリングを持たないユーザーを自動的に登録できます。 |
GitLab.com
バージョン 2020.2 以降、ユーザーは GitLab.com アカウントで TeamCity にサインインできます。
このモジュールを有効にする前に、ルートプロジェクトの設定で GitLab.com 接続を構成し、GitLab で専用アプリケーションを構成する必要があります。
サインインするには、ログインフォームの上にある GitLab アイコンをクリックし、リダイレクト後に TeamCity アプリケーションを承認します。 GitLab メールを持つユーザーが登録されており、このメールが TeamCity 内 と GitLab の両方で検証されている場合、この GitLab アカウントは対応する TeamCity ユーザーにマッピングされ、サインインします。 それ以外の場合、 最初のログイン時に新しいユーザーの作成を許可する オプションが無効になっていない限り、TeamCity は新しいユーザープロファイルを作成します。 既存の TeamCity ユーザーをマッピングすることも、GitLab.com プロファイリングに対して可能です。
設定 | 説明 |
|---|---|
最初のログイン時に新しいユーザーの作成を許可する | デフォルトで有効になっています。 このオプションが無効な場合、提供された外部メールが認識されないと、TeamCity は新しいユーザーを作成しません。 公開されている TeamCity サーバーを使用しており、そのサーバーへのアクセスを制限したい場合に役立ちます。 |
任意の GitLab ユーザーのログインを許可 | デフォルトでは無効です。 このオプションが有効化されている場合、任意のグループのユーザーが TeamCity サーバーにアクセスできます。 特定のグループへのアクセスを制限するには、代わりに 認証を制限する設定を使用します。 |
認証を制限する | グループ(英語)の ID のコンマ区切りのリスト。 このリストは、GitLab アカウントで TeamCity に登録または認証できるユーザー設定を、指定したグループに制限します。 最初のログイン時に新しいユーザーの作成を許可する オプションと組み合わせると、この設定により、指定されたグループのいずれかにメールを持ち、TeamCity にユーザーのプロファイリングを持たないユーザーを自動的に登録できます。 |
GitLab CE/EE
ユーザーは GitLab CE/EE アカウントで TeamCity にサインインできます。
このモジュールを有効にする前に、ルートプロジェクトの設定で GitLab CE/EE 接続を構成し、GitLab で専用アプリケーションを構成する必要があります。
サインインするには、ログインフォームの上にある GitLab アイコンをクリックし、リダイレクト後に TeamCity アプリケーションを承認します。 GitLab メールを持つユーザーが登録されており、このメールが TeamCity 内 と GitLab の両方で検証されている場合、この GitLab アカウントは対応する TeamCity ユーザーにマッピングされ、サインインします。 それ以外の場合、 最初のログイン時に新しいユーザーの作成を許可する オプションが無効になっていない限り、TeamCity は新しいユーザープロファイルを作成します。 既存の TeamCity ユーザーをマッピングすることも、GitLab CE/EE プロファイリングに対して可能です。
設定 | 説明 |
|---|---|
最初のログイン時に新しいユーザーの作成を許可する | デフォルトで有効になっています。 このオプションが無効な場合、提供された外部メールが認識されないと、TeamCity は新しいユーザーを作成しません。 公開されている TeamCity サーバーを使用しており、そのサーバーへのアクセスを制限したい場合に役立ちます。 |
任意の GitLab ユーザーのログインを許可 | デフォルトでは無効です。 このオプションが有効化されている場合、任意のグループのユーザーが TeamCity サーバーにアクセスできます。 特定のグループへのアクセスを制限するには、代わりに 認証を制限する設定を使用します。 |
認証を制限する | グループ(英語)の ID のコンマ区切りのリスト。 このリストは、GitLab アカウントで TeamCity に登録または認証できるユーザー設定を、指定したグループに制限します。 最初のログイン時に新しいユーザーの作成を許可する オプションと組み合わせると、この設定により、指定されたグループのいずれかにメールを持ち、TeamCity にユーザーのプロファイリングを持たないユーザーを自動的に登録できます。 |
バージョン 2022.10 以降、ユーザーは Google アカウントで TeamCity にサインインできます。
このモジュールを有効にする前に、ルートプロジェクトの設定で Google 接続を構成する必要があります。
サインインするには、ログインフォームの上にある Google アイコンをクリックし、リダイレクト後に TeamCity アプリケーションを承認します。 Google メールを持つユーザーが登録されており、このメールが TeamCity 内 で検証されている場合、この Google アカウントは対応する TeamCity ユーザーにマッピングされ、サインインします。 それ以外の場合、 最初のログイン時に新しいユーザーの作成を許可する オプションが無効になっていない限り、TeamCity は新しいユーザープロファイルを作成します。 既存の TeamCity ユーザーをマッピングすることも、Google プロファイリングに対して可能です。
設定 | 説明 |
|---|---|
最初のログイン時に新しいユーザーの作成を許可する | デフォルトで有効になっています。 このオプションが無効な場合、提供された外部メールが認識されないと、TeamCity は新しいユーザーを作成しません。 公開されている TeamCity サーバーを使用しており、そのサーバーへのアクセスを制限したい場合に役立ちます。 |
二要素認証をスキップする | 組織がユーザーの Google アカウントへのログインに 2FA をすでに要求している場合は、冗長な検証を減らすために、このオプションをオンにします。 ユーザーに追加の検証に合格してもらいたい場合は、この設定をオフにします。 詳細: 過剰な承認リクエストの削減。 |
gmail.com を含むすべてのドメインのユーザーがログインできるようにする | デフォルトでは無効です。 このオプションが有効化されている場合、任意のドメインのユーザーが TeamCity サーバーにアクセスできます。 特定のドメインへのアクセスを制限するには、代わりに 認証を制限する設定を使用します。 |
認証を制限する | 組織のドメインのコンマ区切りリスト。 例: このリストは、Google アカウントで TeamCity に登録または認証できるユーザー設定を、指定したドメインのユーザーに制限します。 最初のログイン時に新しいユーザーの作成を許可する オプションと組み合わせると、この設定により、指定されたドメインのいずれかにメールを持ち、TeamCity にユーザーのプロファイリングを持たないユーザーを自動的に登録できます。 |
JetBrains Space
このモジュールを有効化する前に、JetBrains Space で専用のアプリケーションを作成し、ルートプロジェクトの設定でそのアプリケーションへの接続を構成する必要があります。詳しくは こちらをご覧ください。
接続が構成されたら、 管理 | 認証 に移動して次のことを行います。
モジュールを追加 をクリックし、 JetBrains Space タイプを選択します。
最初のログイン時に新しいユーザーの作成を許可するかどうかを選択します。 公開されている TeamCity サーバーを使用しており、そのサーバーへのアクセスを制限したい場合に役立ちます。
ユーザーがログイン時に追加の 2FA 検証に合格するようにするには (Space へのログイン時に合格した場合でも)、 二要素認証をスキップする 設定のチェックを外します。 詳細: 過剰な承認リクエストの削減。
モジュールを保存します。
サインインするには、TeamCity ログインフォームの上にある JetBrains Space アイコンをクリックし、リダイレクト後に TeamCity アプリケーションを承認します。
Azure DevOps サービス
このモジュールを有効にする前に、ルートプロジェクトの設定で Azure DevOps Services インスタンスへの 専用接続を作成する必要があります。
設定 | 説明 |
|---|---|
二要素認証をスキップする | 組織でユーザーが Azure DevOps アカウントにログインする際に 2FA がすでに必要な場合は、冗長な検証を減らすために、このオプションをオンにします。 ユーザーに追加の検証に合格してもらいたい場合は、この設定をオフにします。 詳細: 過剰な承認リクエストの削減。 |
最初のログイン時に新しいユーザーの作成を許可する | デフォルトで有効になっています。 このオプションが無効な場合、提供された外部メールが認識されないと、TeamCity は新しいユーザーを作成しません。 公開されている TeamCity サーバーを使用しており、そのサーバーへのアクセスを制限したい場合に役立ちます。 |
すべての Azure ユーザーにログインを許可する | デフォルトでは無効です。 このオプションが有効化されている場合、任意の組織のユーザーが TeamCity サーバーにアクセスできます。 特定の組織へのアクセスを制限するには、代わりに 認証を制限する設定を使用します。 |
認証を制限する | Azure DevOps 組織のコンマ区切りのリスト。 このリストは、Azure アカウントで TeamCity に登録または認証できるユーザー設定を、指定した組織のユーザーに制限します。 最初のログイン時に新しいユーザーの作成を許可する オプションと組み合わせると、この設定により、指定された組織のいずれかにアカウントを持ち、TeamCity にユーザーのプロファイリングを持たないユーザーを自動的に登録できます。 |
サインインするには、TeamCity ログインフォームの上にある Azure DevOps アイコンをクリックし、リダイレクト後に TeamCity アプリケーションを承認します。
HTTP SAML 2.0
このモジュールは、 SAML 2.0 経由で TeamCity のシングルサインオン認証を有効化します。 Okta(英語)、 OneLogin(英語)、 AWS SSO(英語)、 AD FS 、その他の SSO プロバイダーをサポートすることが確認されています。
モジュールを有効にするには、 管理 | 認証 で:
モジュールを追加 をクリックし、 HTTP-SAML.v2 タイプを選択します。
設定を保存して、 管理 | SAML 設定 に移動します。
サービスプロバイダーの構成セクションの シングルサインオン URL (受取人) 値をコピーします。 これは、以下で説明するように、SSO アプリケーションの設定に入力する必要があります。
TeamCity で SAML 設定を構成する前に、SSO プロバイダー側で専用のアプリケーションを作成する必要があります。 Okta の場合の簡単な手順例を以下に示します。
Okta ダッシュボードで、 アプリケーション を開きます。
アプリ連携を作成 をクリックし、 SAML 2.0 タイプを選択します。
アプリ名を指定し、 SAML を設定 タブで、上記の手順のステップ 3 でコピーした TeamCity サーバーのシングルサインオン URL を入力します。
アプリを保存します。
アプリの設定の 代入 タブで、 割り当て をクリックし、TeamCity サーバーへのアクセスを許可する Okta グループのすべてのユーザーを選択します。
一般 タブで、 セットアップ手順を表示 をクリックします。 TeamCity にコピーする必要がある構成値が表示されます。
Okta の詳細な使い方は プラグインのリポジトリ(英語)にあります。 他の SSO プロバイダーの設定は異なる場合がありますが、主要なアクションは同じです。
アプリの設定に TeamCity シングルサインオン URL を入力します。
必要なすべての SSO ユーザープロファイルがアプリに関連付けられていることを確認します。
アプリの SSOURL、発行者 URL、証明書の値をコピーします。
アプリが作成されたら、TeamCity で SAML 設定 の構成に進みます：
設定 | 説明 |
|---|---|
ID プロバイダーの構成 | アプリの設定からコピーした SSOURL、発行者 URL、証明書の値を入力します。 オプションで、SSO プロバイダー側で証明書を更新しようとしているときはいつでも、追加の証明書をアップロードできます。 TeamCity に新しい証明書を事前に読み込んでおくと、更新中および更新後もプロバイダーとの信頼された接続を中断なく維持できます。 |
サービスプロバイダーの構成 | 受信側サーバー、つまり TeamCity の自動生成された SSO URL が含まれます。 この URL は、SSO プロバイダー側でこの統合を構成するときに入力する必要があります。 SAML 設定を初めて保存すると、TeamCity はそれらを SP メタデータ XML ファイルにエクスポートします。 このファイルへのダウンロードリンクは、この設定セクションにあります。 このファイルを SSO プロバイダー側にアップロードして、TeamCity 構成を自動的に適用できます。 |
ユーザーを自動的に作成する | TeamCity は、SAML 経由でサインインしているユーザーのメールがすでに何らかの TeamCity ユーザーのプロファイリングに属していることを検出した場合、そのユーザーとして認証します。 メールが認識されない場合、動作はこのオプションの値によって異なります。
|
ログインボタンラベル | ログインフォームの SSO ログインボタンの名前を定義します。 |
SAML 厳密モード | リクエスト URL が予想されるコールバック URL（Teamcity ルート URL として設定）に準拠していることを確認します。 追加のセキュリティチェックとして、本番環境でこのオプションを有効のままにしておくことを強くお勧めします。 |
SAML コールバック CORS ファイラー例外 | Teamcity の CORS フィルターに例外を追加します。 |
ログインフォームを非表示にする | TeamCity の内部ユーザー名とパスワードを含む通常のログインフォームを非表示にして、ユーザーが気を取られないようにできます。 |