認証と認可の基本

認証と認可は、ほとんどのアプリケーションスイートにおいて重要な役割を果たします。 このページでは、これらの概念と用語の一般的な概要を説明します。 このテーマを初めて学習する方や、復習したい方にとって役立つ内容です。 一般的な理解に自信がある場合は、CXoneでの認証と認可の仕組みについての学習に進むことができます。

ユーザーが、CXoneを含め、アプリケーションスイートにログインするときは、通常、次の2つのステップを順番に実行します。

  • 認証 -ユーザーは本人か
  • 認可 -認証されたユーザーが要求するアクセスは正当か

すべてのユーザーは、CXoneにアクセスする前に、認証され認可される必要があります。

ユーザーは人である場合もあれば、アプリケーションである場合もあります。 たとえば、チャットボットやバーチャルアシスタントは、多くの場合、ユーザーアカウントによって実行されます。 ほとんどのアプリケーションスイートは、人とバーチャルユーザーに対して同じプロセスを使用します。 認証と認可に関するこのオンラインヘルプのページでは、ユーザーという用語を人とアプリケーションの両方に適用して使用しています。 相違がある場合は、明確に説明しています。

ユーザーの視点では、単にログインしているだけです。認証と認可は背後で行われ、ログインが成功するように働いています。 ログインの開始時点では、ユーザーは認証されていません。 つまり、システムがユーザーの身元を認識していない状態です。 ログインの完了時点では、ユーザーは認証され、かつ認可されています。 つまり、システムはユーザーが誰であるか、そしてどのアクセス権を持つべきかを認識しているということです。

システムは、ユーザーを認証し認可するために以下の処理を行います。

  1. 複数の認証プロセスがサポートされている場合、どの認証プロセスを使用するかを決定します。 多くのシステムは複数の方法をサポートしています。 たとえば、システムはユーザー名とパスワード、シングルサインオン、または多要素認証(MFA)を使用してユーザーを識別できます。 通常、ユーザーはログインページで認証オプションのリストから選択しますが、必要に応じてシステムが特定のプロセスを要求することもあります。

  2. 認証情報を収集します(たとえば、ユーザーにユーザー名とパスワードを要求します)。

  3. アイデンティティプロバイダーを使用して認証情報を確認します。 アイデンティティプロバイダーは、認証情報を含む、ユーザーとその身元に関する情報を管理する別のシステムです。

  4. 認証された個人またはプログラムを認可します。 ユーザーが認証されると、システムは認可サーバーを使用してそのユーザーにアクセス権を付与します。 システムはユーザーの役割と権限に基づいてアクセス権を付与し、 ユーザーが表示または使用を許可された機能にのみアクセスできるようにします。

認証に関連する用語

アイデンティティプロバイダー

アイデンティティプロバイダー(IdP)は、ユーザーの身元を確立するシステムです。 IdPは次のように分類されます。

  • 内部 - ユーザーがログインするシステムの一部です。 たとえば、ユーザーがFacebookにログインする際、FacebookのIdPを使用してFacebookアプリケーションに対する認証が行われます。
  • 外部 - ユーザーがログインするシステムとは別のシステムです。 たとえば、ユーザーがスマートフォンのアプリにログインする際に、FacebookのIdP認証を使用する場合です。

IdPはホスト型とクラウド型のどちらかです。 Microsoft ADFSやShibbolethは一般的なホスト型IdPです。 Microsoft Azure AD、Okta、Pingは多数あるクラウド型IdPの一例です。

認証プロトコル

認証プロトコルは、アプリケーションとIdP間、または異なるIdP間での通信を確立します。 OpenID ConnectやSAML 2.0は、認証プロトコルの例です。 認証プロトコルの中には、暗号化などの追加機能を提供するものもありますが、アプリケーションがそれらの機能を使用するかどうかは異なります。 システムが組み込みのIdPを使用している場合、認証プロトコルは考慮する必要がありません。

認証フロー

ほとんどの外部IdPは、認証プロセスにおいて以下の1つまたは両方のフローをサポートしています。

  • SP起動：サービスプロバイダーまたはアプリケーションによって認証が開始されます。 ユーザーが認証情報を入力し、アプリケーションが外部IdPに対して身元確認を行います。 これが最も一般的なフローです。
  • IdP起動：ユーザーが最初にIdPにログインし、その後IdPがユーザーを確認した後にアプリケーションを起動します。

フェデレーションアイデンティティ管理

フェデレーションアイデンティティ管理は、FIMまたはフェデレーションとも呼ばれます。 これは、1つの外部IdPを使用して1つ以上のアプリケーションに対して認証を提供するプロセスを指す包括的な用語です。 フェデレーションは通常、何らかの形で時間的な制約があります。 たとえば、ユーザーが仕事を始める際に一度ログインすると、 その日は使用するすべてのアプリケーションに対して認証が行われます。 しかし、前日にログアウトしていなくても、翌日には再認証のために再度ログインが必要になります。

シングルサインオン

シングルサインオン(SSO)は、1回のログインで複数のアプリケーションやシステムにアクセスできるようにする仕組みです。 たとえば、ユーザーがMicrosoft 365にログインすると、その会社が許可したすべてのMicrosoftアプリケーションにアクセスできるようになります。 SSOという用語はフェデレーションを指す場合もありますが、両者の概念は完全に同じではありません。

多要素認証

多要素認証(MFA)は、基本的なユーザー名とパスワードによる認証に、さらに1つのセキュリティレベルを追加する仕組みです。 MFAでは、IdPがユーザーの身元を確認する前に、ユーザーがコードを入力する、質問に答える、トークンを使用するなど、追加の認証ステップが求められます。

信頼

認証において、信頼とはアプリケーションやシステムと外部IdPが共有する情報や知識を指します。 この知識により、両者の間に関係が確立され、互いに正確で信頼できる通信が行えることを確認します。 信頼の確立方法は、使用する認証プロトコルによって異なります。 以下の例は、OpenID ConnectおよびSAML 2.0に基づいています。

OpenID Connect

OpenID Connectにおける信頼は、発行者に基づいています。 発行者はURLのような形式の値で、 これによってアイデンティティプロバイダーが確立されます。 たとえば、GoogleはOpenID Connectをサポートしており、その発行者はhttps://accounts.google.comです。

発行者に基づいて、いくつかの追加の設定項目があります。 たとえば、OpenID Connectでは信頼は公開/秘密証明書の署名によって確立されます。 これは、JWKSと呼ばれる業界標準を使用しています。 そのため、設定の一部として、これらの公開証明書がどのように取得されるかが決定されます。

ほとんどのアイデンティティプロバイダーは、発行者に「/.well-known/openid-configuration」を追加することで、この情報を取得できるようサポートしています。 Googleのディスカバリードキュメントはhttps://accounts.google.com/.well-known/openid-configurationにあります。

SAML 2.0

SAML 2.0において、信頼はエンティティ識別子に基づいています。 OpenID Connectとは異なり、エンティティ識別子と他の設定値との間には強い関係性はありません。 SAML 2.0で信頼を確立するためには、いくつかの設定パラメーターが使用されます。

  • エンティティ識別子 - アプリケーションやシステムが自らの身元を確認するために設定する値

  • エンドポイントURL - 外部IdPが認証リクエストを受信する場所として決定する値

  • アサーションURL - 外部IdPが認証応答を送信するアプリケーションやシステムが決定する値

  • 証明書 - 外部IdPが応答に署名するために使用するもの