SAML を使用した認証とアクセス制御

アクセス・ポリシーを定義し、組織の SAML を管理するための手順と方法。

SAMLを使用すると、組織は既存のIDプロバイダ（IdP）を使用して、Tulipユーザーの認証とアクセス権を管理できます。このガイドでは、エンタープライズ・レベルのSAMLインストールの発見と実装のプロセスを詳しく説明します。単一サイトについては、こちらのサポート記事を参照してください。

高レベルのプロセス

事前作業

• Tulip ユーザ・ロールを理解する。
• 従業員を役割ベースのグループにバケットする。
• 組織内で誰がIdPとTulipアカウントを設定するかを特定する
• 既存のユーザーを移行する必要があるかどうかを判断する

新しいサイト

• Tulipがお客様のサイトでSAMLを有効にします。
• 組織が（IdPとTulipの両方で）SAMLを構成し、ユーザーにアクセスを許可する。

新規サイトの作成プロセス

Tulip Customer Success Manager に、SAML で新しいサイトを作成したい旨のリクエストを送信する。以下を提供する必要があります：

• サイト名と URL
• ログインして SAML を構成する組織の担当者の名前と電子メール。

Tulip がサイトを作成し、SAML を有効にする。

構成担当者は、サイトにログインするための電子メールを受け取り、ここで説明するように SAML を構成する。担当者は、以下に定義する 2 つのアクセス戦略に基づいてサイトを構成する。

ユーザによるアクセスを確実にテストする。

:::(Info) (注:) 完了したら、アカウント所有者は、SAML を構成した人のユーザ・アカウントを削除する必要がある。その担当者が将来にわたって SAML を保守する場合は、その担当者にアカウント所有者アクセス権を与え、将来 の構成のために SAML でサインインする必要がある。

Tulip が作成した SAML 証明書は、1 年ごとに失効する。Tulip 社は、証明書をローテーションする 2 週間前にチームに通知します：

アクティブ・サイトSAML変換プロセス

上記と同じですが、SAML を有効にする前に、既存のユーザをすべて Tulip アカウントから SAML アカウントに変換する必要があります。そのためには、すべてのユーザの電子メールとIdP が提供するNameId のリストが必要である。構成担当者と協力して、ダウンタイムを最小限に抑えて変換を行う。既存のユーザーが不要な場合は、単純にすべてのユーザーを削除することができます。これらのユーザーにリンクされているCompletionなどの既存のデータは、新しいユーザーには移行されないことに注意してください。ドキュメントはこちら

参考文献

Tulip for Azure Active Directoryの設定方法はこちらをご覧ください。

アクセスの設定

LTS 6

LTS 6のWorkspacesのリリースに伴い、SAML認証戦略が変更され、組織はITに不必要な負担をかけることなくユーザーを管理できるようになりました。

SAML の変更点

制御モード

Tulip Control Mode は、Tulip に初めてログインしたときにのみ、ユーザの Tulip ロールとワークスペースが SAML 属性マッピングから取得される現在の動作である。Tulipで非アクティブ化されたユーザーはログインできません。 IdP制御モードとは、ユーザーが認証に成功するたびに、再アクティブ化されることを意味します。TulipのロールとワークスペースはIdPから更新されます。

デフォルトのロールマッピング

最初のログインでは、すべてのユーザーにデフォルトのアクセスレベル（プレイヤーアクセス権を持つビューア）が与えられます。アカウントの所有者は、適切なレベルにロールを調整する必要があります。

アクセス制御

ユーザーがTulipにアクセスするために特定の値を持つ必要があるアクセス制御属性を追加することができます。これは、役割やワークスペースに関係なく、誰がTulipにアクセスできるかを決めたい、デフォルトマッピングのシナリオに特に関連します。

例えば

• ユーザーはTulipAccessControl属性がTrueに設定されていなければなりません。
• ユーザーは、属性TulipAccessControlを通して公開されるグループTulipUsersに属していなければなりません（以下の例を参照してください）。

Access Controlを使用する場合は、Tulipにアクセスできるすべてのユーザーに定義された属性と値を追加するよう、IdPチームに依頼する必要があります。

ワークスペース

ワークスペースについての詳細はこちらをご覧ください。

ロール属性と同様に、ユーザーをワークスペースにマッピングするオプションが提供されます。

SAML カスタムワークスペースマッピング

最初のログイン時に、ユーザはワークスペース属性に提示されたグループに基づいてワークスペース・アクセスが割り当てられる。この時点以降、Tulip はそのユーザのワークスペース属性を読み込まなくなり、ワークスペースの変更はアカウント所有者がプラットフォームで行う必要があります。

:::(Info) (注）この方法を選択した場合、Tulipへのアクセスを必要とするすべてのユーザーに適切なワークスペースを追加するよう、IdPチームに依頼する必要があります：

デフォルトワークスペースマッピング

初回ログイン時に、すべてのユーザーに選択したデフォルトのワークスペースへのアクセス権が付与されます。その後、アカウント所有者がワークスペースのアクセス権を調整できます。

アクセスグループの作成

カスタムロールマッピングオプションの場合（LTS 6以前のデフォルト）

標準化されたTulipのアクセスグループを作成します：

すべてのユーザーは、IdPのユーザー名とパスワードで認証された後、Tulipが権限を決定するために使用する、IdPで指定されたロール属性が必要です。また、このRoleフィールドを使用して、標準的な命名規則を使用して、どのサイトにアクセスできるかを決定することもできます。Roleフィールドは単なるセット変数でもかまいませんが、ユーザーをTulipの特定のグループに割り当て、それらを属性にマッピングすることをお勧めします。

ロール

ここでチューリップのアクセスロールを確認してください。すべてのユーザーは少なくとも1つのロールが必要です。ユーザーが複数のロールを持つ場合、Tulipは最も高いアクセス権を持つロールを選択します。

ロールの例は、アカウント所有者です。

:::(Info) (注:) アカウント所有者は、サイトごとに少なくとも1人必要です：

サイト

組織に2つのサイトがあり、それぞれにTulipインスタンスがあるとします。

それぞれのサイトを場所（それぞれテキサスとロンドン）で表すことができます。

2つのサイトを組み合わせる

この2つのサイトを組み合わせて、ユーザーを割り当てるためのグループマトリックスを作成できます。Tulipでフィルタリングしやすいように、Tulipで値を付加または前置することをお勧めします。

コンベンション:tulip-siteRole

| | | --- | --- | | | acme-texas.tulip.co | acme-london.tulip.coco｜｜アカウントオーナー｜tulip-texasAccountOwner｜tulip-londonAccountOwner｜｜アプリケーションスーパーバイザー｜tulip-texasApplicationSupervisor｜tulip-londonApplicationSupervisor｜｜ビューアー｜tulip-texasViewer｜tulip-londonViewer｜｜オペレーター｜tulip-texasOperator｜tulip-londonOperator｜｜・・・。| | |

Jane Smithがテキサスサイトのサイトリーダーである場合、彼女をtulip-texasAccountOwner グループに割り当てます。Jane SmithがLondonサイトのビューアクセスも必要な場合は、tulip-londonViewerという グループに追加します。

これらのグループをTulipの属性として公開します。

IdPでは、Janeはtulip-roleという属性を持ち、接頭辞 "tulip-"を含むグループのメンバーとしてマッピングされます。JaneがTulipにサインインすると、tulip-role属性にはtulip-texasAccountOwnerとtulip-londonViewerの2つの値が設定されます。

グローバルロール

例えばビューアとして、グローバルアクセスロールを作成したい場合もあるでしょう。その場合の書式は

tulip-globalViewer

:::(Info) (注:) グローバル・ビューワー・グループのメンバーであるユーザーが、より多くのアクセス権を持つロールを持つサイトにログインした場合、Tulipはそのユーザーに利用可能な最高のアクセス権を与えます：

お探しのものは見つかりましたか？

community.tulip.coで質問を投稿したり、他の人が同じような質問に直面していないか確認することもできます！