Admin Console を使用すると、エンタープライズユーザーは、既存の ID 管理システムとシングルサインオン(SSO)対応管理システムを組み合わせて、アドビエンタープライズ製品の認証を実行できます。シングルサインオンは、エンタープライズ ID 管理システムとアドビのようなクラウドサービスプロバイダーを結び付ける業界標準プロトコルである SAML を使用して有効化されます。SSO により、サービスプロバイダー(アドビ)と貴社の ID プロバイダー(IdP)の間で認証情報を安全に交換することが可能になります。サービスプロバイダーがユーザー認証のため、IdP にリクエストを送信します。認証後、IdP はユーザーログインのためレスポンスメッセージを返します。詳しくは、シングルサインオンの構成を参照してください。

計画

アドビでは、次の ID タイプを提供しています。

  • Enterprise ID:組織がアカウントを作成し、所有します。アカウントは、クレームされたドメインに作成されます。アドビが資格情報を管理し、ログインを処理します。
  • Federated ID:組織がアカウントを作成、所有して、フェデレーションを通じてエンタープライズディレクトリにリンクし、企業または教育機関が資格情報を管理して、シングルサインオンを通じログインを処理します。
  • Adobe ID:アカウントはユーザーが作成、管理します。資格情報の管理とログインの処理は、アドビがおこないます。

はい。クレームされた同じドメイン内でなければ、Enterprise ID、Federated ID、Adobe ID から複数種類を選択いただけます。

Enterprise ID と Federated ID はドメインレベルで排他的です。そのため、いずれか一方しか選択できません。Adobe ID は、Federated ID または Enterprise ID とともに使用できます。

例えば、エンタープライズで 1 つのドメインのみをクレームした場合、IT 管理者は、Enterprise ID または Federated ID のいずれかを選択できます。エンタープライズ内で組織が複数のドメインをクレームした場合、IT 管理者は 1 つのドメインで Adobe ID と Enterprise ID を使用し、別のドメインで Adobe ID と Federated ID を使用する、といったことが可能です。つまり、各ドメインについて、Adobe ID と Enterprise ID の組み合わせ、または Adobe ID と Federated ID の組み合わせを使用できることになります。

Federated ID でのアドビライセンスの管理は、より高速かつ簡単で、安全性に優れています。

  • IT 管理者が、認証とユーザーライフサイクルを管理します。
  • ユーザーをエンタープライズディレクトリから削除すると、ユーザーは、デスクトップアプリケーション、サービスまたはモバイルアプリケーションにアクセスできなくなります。
  • Federated ID を使用すると、組織は既存のユーザー ID 管理システムを活用できます。
  • ユーザーが組織の標準の ID システムを使用できるため、IT 管理者は別途パスワード管理プロセスを管理する必要がありません。

ログイン時に、ユーザーは、組織の一般的な使い慣れたシングルサインオンの操作にリダイレクトされます。

はい。同じドメインを使用して、Enterprise ID から Federated ID に切り替えることができます。詳しくは、ディレクトリ間でドメインを移動する方法を参照してください。

はい。Adobe で SAML 2.0 に準拠した ID プロバイダーを利用してエンタープライズディレクトリとそのログインおよび認証インフラストラクチャをフェデレーションすることができます。

いいえ。Federated ID でドメインをクレームした場合、そのドメイン内の電子メールアドレスを含む既存の Adobe ID が変更されることはありません。Admin Console 内の既存の Adobe ID はそのまま保持されます。

アセットの移行のプロセスは自動化されています。このプロセスを開始すると、お客様の Adobe ID アカウントに現在保存されているすべてのサポートされたコンテンツは、Enterprise ID または Federated ID アカウントへの移行されます。詳しくは、アセットの自動移行を参照してください。

アドビの Federated ID の実装では承認をサポートしています。認証は ID プロバイダー(IdP)が対応します。

エンタープライズ組織であれば、(Active Directory などの企業 ID 構造を利用する)認証サービスとアドビ製品との関連付けを作成できます。これにより、エンタープライズ組織は認証を提供できます。アドビでパスワードが保存されることはありません。また、IT 管理者は Admin Console を通じて Federated ID のパスワードのリセットや、ユーザー名の編集を実行することはできません。

はい、Admin Console 内からユーザーの読み込み機能を使用できます。詳しくは、複数ユーザーの追加を参照してください。

いいえ。アドビは ID プロバイダーとやり取りしますが、エンタープライズディレクトリを直接扱いません。ただし、エンタープライズディレクトリから Admin Console へのユーザー/グループ情報の読み込みはサポートしています。詳しくは、複数ユーザーの追加を参照してください。

Adobe では、すべての大規模法人の管理者は Adobe ID を Federated ID へ切り替えるようお勧めしています。Adobe ID を Federated ID に移行するには、こちらの手順をご利用ください。

Adobe は一般的に採用されている安全な業界標準である Security Assertion Markup Language(SAML)を使用しています。これにより、SSO の実装は、SAML 2.0 をサポートする ID プロバイダーと簡単に統合されます。

SAML 2.0 に準拠している IdP は次のとおりです。

  • Okta
  • Oracle Identity Federation
  • Microsoft ADFS
  • Microsoft Azure AD*
  • Google フェデレーション* 
  • Ping Federate
  • 外部の署名された証明書を使用した Salesforce IdP
  • CA Federation
  • ForgeRock OpenAM
  • Shibboleth
  • NetIQ Access Manager
  • OneLogin
  • Novell Access Manager

注意:

*ID プロバイダーが Microsft Azure AD または Google の場合は、SAML ベースの方法を省略し、Azure AD コネクタまたは Google フェデレーション SSO を使用して、Adobe Admin Console で SSO をそれぞれ設定してください。これらの設定は、Adobe Admin Console を使用して確立および管理され、ユーザー ID と資格の管理には同期メカニズムが使用されています。

はい、SAML 2.0 プロトコルに準拠している限り統合は可能です。

はい、また ID プロバイダーは SAML 2.0 に準拠している必要があります。

SAML ID プロバイダーに必要な最小要件は、次のとおりです。

  1. IDP 証明書
  2. IDP ログイン URL
  3. IDP バインディング:HTTP-POST または HTTP-Redirect
  4. IDP の Assertion Consumer Service URL(SAML リクエストと中継状態を受け入れることができる必要があります)

詳しくは、ID プロバイダーにお問い合わせください。

いいえ。2048 ビットの証明書が破損したことはありません。また、唯一 768 ビットの証明書のクラッキングにも成功した人でさえ(Lenstra のグループ)、同じハードウェアで 1024 ビットの証明書をクラッキングするには(2048 ビットの証明書をクラッキングするよりは、およそ 32,000,000 倍も簡単ですが)、1000 年以上かかると言われています。

様々な長さの証明書をクラッキングするのにかかる時間の最新の見積もりデータについては、上記のリンク先 Web サイトを参照してください。これらの証明書がどのくらい安全かを示す図(正確ですが、マーケティング指向)についても、上記 Web サイト(または後援している数学の Web サイト)をご覧ください。

いいえ。この制限は、ブラウザーとサーバーの間の通信のパイプをエンコードするために使用される証明書に設定されています。これらの IdP 証明書は、そのエンコードされたパイプを経由したデータに署名する(エンコードではない)ために使用されます。ブラウザーではこれらの証明書が認知されません。これらは Adobe とお客様の IdP 間でのみ使用されます。

商用の 2048 ビットの証明書は、年間 10 ドルで入手できます。また、IdP で使用する証明書は、自己署名できます。これは、オープンソースソフトウェアで無料で生成できることを意味します。

いいえ。2 つのレイヤーで強力に暗号化され、IdP の ID がチェックされるため、IdP を偽装する前にクラッキングする必要があります。また、どちらのレイヤーでも、自己署名できません。つまり、暗号化を強制する証明書だけでなく、証明書を生成した署名者の証明書もクラッキングする必要があるということです。

プレミアムサポート用の電話番号と電子メールアドレスについては、アカウント管理者に送信された案内メールと添付の PDF を参照してください。

同じ URL エンドポイントを複数のディレクトリに対して使用することができます。ただし、フェデレーションメタデータは、IdP ごとに別々に管理されます。そのため、共通 IdP エンドポイントは、コンテンツの異なる要求を処理する必要があります。

はい、ディレクトリの SAML 統合でユーザー名形式が使用されており、Admin Console 上のユーザー名が、提供されている永続的 ID と同じ場合はサポートされます。ただし、これをおこなうには、ユーザーが Admin Console に同期される時点で、永続的 ID が用意されている必要があります。これは一般的なシナリオではないため、実際には、NameID 要素の永続的形式はサポートされません。

いいえ。Admin Console では、NameID 要素値がユーザー名として使用され、NameQualifier は無視されます。

各ユーザーの名、姓、および電子メールアサーションは必須です。しかし、それらがディレクトリのデータと一致する必要はありません。ただし、電子メールは各ユーザーに一意である必要があります。

はい。アドビは SHA256 証明書をサポートしています。詳しくは、ID の設定を参照してください。

はい。認証局(CA )の署名付き証明書をアドビカスタマーサポートに提供してください。アドビが代わりにアップロードします。

続行するには、Admin Console にログインし、サポートサポートの概要に移動して「ケースを作成」をクリックします。詳しくは、サポートケースの作成や管理の方法を参照してください。

Okta 証明書は、デフォルトで自己署名されています。例外として(おそらく有料で)、公的 CA によって署名された証明書を入手することもできます。

方法

アドビのデスクトップアプリケーション、サービスおよびモバイルアプリケーションでの SSO の設定の詳しい手順については、シングルサインオンの構成をご覧ください。

いいえ。Admin Console を通じてユーザーに通知を送信することはできません。企業のお客様の場合、アドビのソフトウェアおよびサービスで SSO を開始できるようになった後で、ユーザーに独自の通知を配信する必要があります。

いいえ。エンタープライズディレクトリからユーザー/ID を削除するか無効にした場合、ユーザー/ID は Admin Console から自動的に削除または無効化されません。ただし、ユーザーは Adobe Creative Cloud デスクトップアプリケーション、サービス、モバイルアプリケーション、または Acrobat DC アプリにログインすることができなくなります。ユーザー/ID は Admin Console から手動で削除する必要があります。

はい、Admin Console を使用して、ユーザー、グループおよび権限を管理する必要があります。ただし、Admin Console にグループを一度作成したら、ユーザーおよびグループの両方の情報を含む CSV ファイルをアップロードできます。これにより、ユーザーアカウントが作成され、指定されたグループに配置されます。

いいえ、Admin Console を使用して Federated ID のパスワードをリセットすることはできません。アドビではユーザーの資格情報を保存しません。ユーザーを管理するには ID プロバイダーを使用してください。

よくある質問:新しい認証プロバイダーへのディレクトリの移行

ここでは、SHA-2 認証または異なる認証プロバイダーへのディレクトリの移行に関する質問に回答します。

移行を開始する前に、移行手順に従うためのアクセス要件を満たしていることを確認します。また、組織のディレクトリをシームレスかつエラーなしに移行できるように、次の点を確認する必要があります。

  • 管理者は、IdP 設定上で新しい SAML アプリを作成して構成する必要があります。管理者が既存のアプリケーションを編集すると、アクティブな既存の設定が書き換えられるため、ダウンタイムが発生するだけでなく、Adobe Admin Console で使用可能な IdP 間を切り替える機能が無効になります。
  • 管理者は、必要なすべてのユーザーが、新しく作成した SAML アプリに割り当てられ、またはそれを使用できるかを確認する必要があります。
  • 管理者は、IdP の新しい認証プロファイルに設定されたユーザー名の形式が、ユーザーログイン用の既存のプロファイルで使用されている形式と一致していることを確認する必要があります。これには認証プロファイルで用意されたテスト機能を使用して検証できます。このテストリンクは、クリップボードにコピーし、他のユーザーと共有することで、それぞれのコンピューターから検証を実行できます。
  • 管理者は、アクティブ化の前に、ディレクトリの 2 ~ 3 のアクティブなアカウントを使用して、新しく追加した IdP をテストする必要があります。

この機能ではエラーログを使用できません。ただし、テストワークフローを使用することで、管理者がアクティブ化の前に関連するエラーを検証できます。 また、この機能に関する主な制限事項は以下のとおりです。

  • 1 つのディレクトリには最大 2 つの認証プロファイルを設定できますが、両方のプロファイルには異なる認証タイプを設定する必要があります。
    例えば、Microsoft Azure AD(Open ID Connect を使用)は他の SAML プロバイダーと共存できますが、Google(それ自体が SAML を使用)は、同じディレクトリ内で他の SAML プロバイダーと共存できません。
  • 管理者はこの機能を使用して、ID プロバイダーを移行し、ディレクトリ同期機能(Azure AD Connector および Google Connector)を有効にすることはできません。ただし、Microsoft Azure または Google を IdP として移行するお客様は、異なる形のユーザー管理方法を利用できます。詳しくは、Adobe Admin Console ユーザーを参照してください。