システム管理者として Admin Console で最初におこなうことが、エンドユーザーを認証するための ID システムの定義と設定です。アドビ製品とサービスのライセンスを購入した後、ライセンスをエンドユーザーにプロビジョニングする必要があります。そのためには、ユーザーを認証する方法が必要です。
アドビは、エンドユーザーの認証に使用できる次の ID タイプを提供しています。
- Adobe ID
- Enterprise ID
- Federated ID
組織が個別にアカウントを所有し、ドメイン内のユーザーを管理する場合は、Enterprise ID または Federated ID（シングルサインオン）を使用してください。
ここでは、Enterprise ID または Federated ID を使用してエンドユーザーを認証するために必要な ID システムの設定方法を説明します。
注意：
このドキュメントに記載されているディレクトリの設定とドメインの設定の手順は完全に切り離されています。つまり、これらの手順は順序を問わず、並行しておこなうこともできます。ただし、電子メールのドメインをディレクトリにリンクするためには、両方の手順を完了する必要があります。
Adobe ID
エンドユーザーによって作成、所有、管理されます。認証はアドビによって実行され、ID はユーザーによって管理されます。ユーザーは、自分の ID に関連付けられたファイルやデータを完全に制御できます。ユーザーはアドビから追加の製品やサービスを購入することもできます。管理者は、ユーザーを組織に参加するよう招待したり、対象ユーザーを削除したりできますが、ただし、ユーザーを Adobe ID アカウントからロックアウトすることはできません。管理者がアカウントを削除したり、管理を引き継いだりすることもできません。Adobe ID の使用を開始するために必要な設定は特にありません。
次の要件やシナリオに該当する場合には、Adobe ID を使用することが推奨されます。
- ユーザーが ID を作成、所有、管理できるようにする場合
- ユーザーが他のアドビ製品やサービスを購入または新規登録できるようにする場合
- Enterprise ID や Federated ID を現在サポートしていない他のアドビサービスをユーザーが使用することが想定される場合
- ユーザーが既に Adobe ID を所有し、ファイル、フォント、設定などのデータが関連付けられている場合
- 教育用環境で学生が卒業後も Adobe ID を保持できる場合
- 組織が管理するドメインの電子メールアドレスを使用していない契約社員やフリーランサーがいる場合
- Adobe グループ版契約がある場合は、この ID タイプを使用する必要があります。
Enterprise ID
組織によって作成、所有、管理されます。Enterprise ID のホストと認証は Adobe がおこないますが、ID は組織が保持します。エンドユーザーは新規登録して Enterprise ID を作成したり、Enterprise ID を使用して Adobe からの追加製品およびサービスを利用したりすることはできません。
Enterprise ID は、管理者が作成してユーザーに発行します。管理者は、アカウントを借用するか、Enterprise ID を削除して関連するデータへのアクセスを完全にブロックすることにより、製品およびサービスへのアクセスを取り消すことができます。
次の要件やシナリオに該当する場合には、Enterprise ID を使用することが推奨されます。
- ユーザーが使用するアプリケーションやサービスを厳格に管理する必要がある場合
- ID に関連付けられたファイルやデータに緊急にアクセスする必要がある場合
- ユーザーアカウントを完全にブロックまたは削除する機能が必要な場合
Federated ID
組織によって作成、所有され、フェデレーションを通じてエンタープライズディレクトリにリンクされます。資格情報は組織が管理し、SAML2 ID プロバイダー（IdP）を使用してシングルサインオンを処理します。
次の要件やシナリオに該当する場合には、Federated ID を使用することが推奨されます。
- 組織のエンタープライズディレクトリに基づいてユーザーをプロビジョニングする場合
- ユーザーの認証を管理する場合
- ユーザーが使用するアプリケーションやサービスを厳格に管理する必要がある場合
- Adobe ID の新規登録に使用する電子メールアドレスと同じアドレスの使用をユーザーに許可する場合
注意：
ID プロバイダーは TLS 1.2 に準拠している必要があります。
認証ドメイン
この設定を担当するユーザー
ドメインを使用する ID タイプ
ユーザー ID は、認証ソースに対して検証されます。Enterprise ID や Federated ID を使用するには、ドメインを追加して固有の認証ソースを設定します。例えば、電子メールアドレスが john@example.com の場合、example.com がドメインですが、ドメインを追加すると、そのドメイン上の電子メールアドレスを使用して Enterprise ID や Federated ID を作成できるようになります。ドメインは、Enterprise ID か Federated ID のいずれかで使用できますが、両方に同じドメインを使用することはできません。ただし、複数のドメインを追加することはできます。
組織はドメイン管理を検証する必要があります。組織では、複数のドメインを追加することもできます。ただし、同じドメインは 1 回しか追加できません。一部のパブリックドメインや一般的なドメイン（gmail.com や yahoo.com など）は追加できません。
ID タイプについて詳しくは、ID タイプの管理を参照してください。
Enterprise ID または Federated ID を使用するにはまず、ドメインをリンクできるディレクトリを設定します。
ディレクトリを設定するには、次の操作をおこないます。
- Admin Console でディレクトリを作成します。
- （Federated ID のみ）アドビがディレクトリをプロビジョニングします。これには通常最大 48 時間かかります。
- Enterprise ID の ID タイプを設定する場合は、電子メールのドメインをディレクトリにリンクします。
- （Federated ID のみ）アドビがディレクトリをプロビジョニングした後、ディレクトリの SAML 設定を構成します。
ディレクトリの作成
-
Admin Console にログインし、設定／ID に移動します。
注意：
Federated ID のディレクトリをプロビジョニングするには、通常最大 48 時間かかります。完了すると、電子メールで通知されます。
シングルサインオンの構成（Federated ID のディレクトリの場合に必須）
ディレクトリのプロビジョニング完了を通知する電子メールをアドビから受け取ったら、ディレクトリの SAML 設定を構成します。
組織がシングルサインオン（SSO）を構成して有効化すると、その組織のユーザーは企業の資格情報を使用してアドビのソフトウェアにアクセスできるようになります。ここでは、ユーザーは単一の資格情報を使用して、アドビのデスクトップアプリケーション、サービスおよびモバイルアプリにアクセスできます。
Adobe Admin Console を使用すると、企業ユーザーは既存の企業 ID を使用して認証をおこなえます。アドビの Federated ID は、シングルサインオン（SSO）ID 管理システムと連携します。シングルサインオンは、エンタープライズ ID 管理システムとアドビのようなクラウドサービスプロバイダーを結び付ける業界標準プロトコルである SAML を使用して有効化されます。
SSO により、サービスプロバイダー（アドビ）と貴社の ID プロバイダー（IdP）の間で認証情報を安全に交換することが可能になります。サービスプロバイダーがユーザー認証のため、IdP にリクエストを送信します。認証が完了したら、ユーザーログインのため IdP によってレスポンスメッセージが返されます。
アドビソフトウェアに SSO をセットアップするには、IT 管理者は以下の要件を満たす必要があります。
- SAML 2.0 の理解
- ID プロバイダー（IdP）が SAML 2.0 をサポートし、少なくとも以下を備えている必要があります。
- IDP 証明書
- IDP ログイン URL
- IDP バインディング：HTTP-POST または HTTP-Redirect
- Assertion Consumer Service URL
- TLS 1.2 が有効
- ドメインのクレーム処理のための DNS 構成へのアクセス
ユーザーがログインできるようにするために、IdP のログイン URL を外部からアクセス可能にする必要はありません。ただし、アクセスを組織の内部ネットワーク内に限定した場合、ユーザーがアドビ製品にログインできるのは、組織の内部ネットワークに直接接続しているか、WiFi や VPN 経由で接続しているときに限られます。ログインページへのアクセスを HTTPS 経由に限定することは必須ではありませんが、セキュリティ上の理由からは推奨しています。
注意：
現時点で、アドビは IdP-Initiated SSO をサポートしていません。
SSO 統合をテストする必要がある場合は、組織で所有するテストドメインをクレームすることをお勧めします。これは、ID がそのテストドメインで設定されている ID プロバイダーを組織が所有していれば実行できます。これによって、ドメインのクレームや構成プロセスに慣れるまで、統合をテストした後で、メインのドメインをクレームできます。
すでに ID プロバイダー（IdP）をお持ちの場合は、Okta が提供する SaaS SAML 2.0 コネクタを使用して SSO を簡単に構成できます。
注意：
Okta は、1 つの ID プロバイダーとして、多くのベンダーの中から選択できます。
-
Admin Console にログインし、設定／ID に移動します。
-
IDP 証明書：IdP が SAML レスポンスまたはアサーションの署名に使用する証明書（.cer）をアップロードするには「アップロード」をクリックします。
証明書がない場合は、証明書ファイルをダウンロードする手順について ID プロバイダーにお問い合わせください。
証明書のヒント：
- PEM（Base 64 encoded X.509）形式
- .cer ファイル拡張子（.pem または .cert ではない）で指定
- 暗号化されていない
- SHA-1
- 複数行形式（単一行は失敗する）
- 少なくとも 3 年の継続が必要（有効期間中のメンテナンスの手間を省き、セキュリティが確保される）
注意：
Federated ID ハンドシェイクのアドビ側で使用されている Okta 証明書は 20 年の証明書です。これにより、Adobe/Okta によって強制的におこなわれるのではなく、ユーザーの都合で証明書のローテーションを行えます。
IDP バインディング：SAML プロトコルメッセージの送信方法を選択します。
- HTTP-Post を使用して、XHTML フォームを使い、ブラウザー経由で認証リクエストを送信します。IdP が、XHTML フォームを含むドキュメントにより応答します。
- HTTP-Redirect を使用して、HTTP GET リクエストのクエリ文字列にある SAMLRequest 文字列パラメーターを通じて承認リクエストを送信します。IdP が、URL の SAMLResponse 文字列パラメーターにより応答します。
-
「メタデータをダウンロード」をクリックします。
メタデータファイルがローカルディスクにダウンロードされます。このファイルを使用して、ID プロバイダーとの SAML 統合を構成します。
ID プロバイダーは、シングルサインオンを有効にするためにこのファイルが必要です。
警告：
一般的な SAML ID プロバイダー（OpenAthens、Shibboleth など）は、ユーザー名（通常、電子メールアドレス）を「指定なし」の形式の NameID として送信します。また、属性 FirstName、LastName、Email を送信します（大文字と小文字は区別されます）。
これらの属性は、Admin Console を使用して設定されたエントリに一致する必要があります。これらの属性が、SAML 2.0 コネクタ構成の一部として送信されるように IDP で構成されていない場合、認証は機能しません。
-
ID プロバイダーとの SSO 構成が完了した後、Admin Console にログインし、設定／ID に移動します。
エンドユーザーは、Admin Console で設定したドメインに対して認証されます。
ドメインを設定するには、次の操作をおこないます。
- Admin Console にドメインを追加する
- 特別な DNS レコードを追加して、ドメインの所有権を検証するための準備をする
- ドメインを検証する
ドメインを追加する
Admin Console に追加するドメインは、同じ IdP で登録する必要はありません。ただし、これらのドメインをディレクトリにリンクするときに、各 IdP からそれぞれ別のディレクトリにドメインをリンクさせる必要があります。
ドメインが既に別の組織の Admin Console に追加されている場合は、Admin Console に追加できません。ただし、そのドメインへのアクセスを要求することはできます。
-
Admin Console にログインし、設定／ID に移動します。
（DNS トークンを使用して）ドメインの所有権を実証する
組織はドメインの所有権を実証する必要があります。組織は、Admin Console に必要な数のドメインを追加できます。
Admin Console では、1 つの DNS トークンを使用してすべてのドメインの所有権を実証できます。また、Admin Console では、サブドメインの DNS 検証は不要です。つまり、DNS トークンを使用してドメインの所有権を実証すれば、そのドメインのサブドメインが Admin Console に追加されると同時に、すべて自動的に検証されます。
-
クレームするドメインが自社の所有するドメインであることを証明するには、生成された DNS トークンを含む TXT レコードを追加する必要があります。厳密な手順はドメインホストによって異なりますが、一般的なガイドラインをドメインの所有権の確認に示します。
-
手順を完了するには、DNS サーバーに追加で情報を入力する必要があります。効率的に作業できるように、事前に DNS マネージャーに連絡してください。
アドビは、ドメインの DNS レコードを定期的にチェックします。そして、DNS レコードが正しい場合は、ドメインは自動的に検証されます。Admin Console にログインして、手動ですぐにドメインを検証することも可能です。ドメイン検証を参照してください。
ドメイン検証
これで、Admin Console の必要なディレクトリに検証されたドメインをリンクできます。
警告：
同じドメインを複数のディレクトリにリンクすることはできません。また、現在のところ、ドメインとディレクトリ間のリンクを削除するには、アドビのサポートにお問い合わせください。このため、ドメインとディレクトリ間のリンクを計画してから、次の手順を開始してください。
1 つのドメインの所有権をクレームできるのは 1 つの組織のみです。そこで、次のシナリオについて考えてみます。
Geometrixx という会社には複数の部署があり、各部署には独自の Admin Console があります。また、いずれの部署でも、geometrixx.com ドメインを使用した Federated ID をユーザー ID として使用したいと考えています。この場合、各部署のシステム管理者は、このドメインを認証のためクレームする必要があります。Admin Console は、ある組織のドメインが別の組織の Admin Console に追加されるのを防ぎます。ただし、1 つの部署により追加された後、他の部署は、組織の Admin Console に代わってそのドメインがリンクされているディレクトリへのアクセスを要求することができます。
ディレクトリの信頼性により、ディレクトリの所有者は他のシステム管理者（共同利用権所有者）を信頼することができます。その後、Admin Console の共同利用権を所有する組織は、信頼されたディレクトリ内の任意のドメインにユーザーを追加できます。
まとめると、Admin Console で Enterprise ID または Federated ID を使用する場合は、組織に関連付けられたドメインを追加する必要があります。このドメインが既に別の組織によって追加されている場合、そのドメインに含まれるディレクトリへのアクセスを共同利用権所有者として要求する必要があります。
ディレクトリへのアクセスを要求するには、上のドメインの設定にある、ドメインを追加する手順を参照してください。
警告：
ディレクトリの所有者が、そのディレクトリへのアクセス要求を承認すると、共同利用権を所有する組織はそのディレクトリに関連付けられているすべてのドメインにアクセスできるほか、以後そのディレクトリに関連付けられるすべてのドメインにもアクセスできます。このように、ドメインとディレクトリのリンク計画は、組織の ID システムを設定する上で不可欠な手順です。
アクセスを要求する
Admin Console に既存のドメインを追加する場合は、次のメッセージが表示されます。
このドメインへのアクセスを要求すると、送信者の名前、電子メール、組織名が所有者組織のシステム管理者と共有されます。
ディレクトリのタイプ（Enterprise または Federated）は、所有者組織がおこなった設定によって決まります。そのため、所有者組織によって選ばれたタイプのディレクトリを使用する必要があります。
ドメインは既に所有者によって設定されているため（詳しくは、ドメインの設定の「ドメインの所有権を実証する」を参照）、共同利用権所有者は特に何もおこなう必要がありません。アクセス要求が所有者によって承認されると、共同利用権を所有する組織は所有者組織が構成したとおりに、ディレクトリとすべてのドメインにアクセスできます。
要求のステータスを確認する
共同利用権を取り消す
所有者組織のシステム管理者は、所有しているディレクトリへのアクセス要求を承認するか拒否するかを選択できます。
所有するディレクトリへのアクセス要求の電子メールを受け取ったら、その電子メール内から要求の承認または拒否を選択できます。また、「アクセス要求」タブに移動してクレーム要求を管理することもできます。
アクセス要求を承認する
要求を拒否する
アクセスを取り消す
暗号化キーを有効にする
ディレクトリを削除する
Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。