認証と認可の基本

認証と認可は、ほとんどのアプリケーションスイートで重要なロールを担っています。このページでは、その概念と用語の一般的な概要を説明します。このテーマを初めて学習する場合、あるいは復習したい場合に役立ちます。一般的な理解に自信がある場合は、認証と承認がCXoneでどのように機能するかの学習に進むことができます。

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

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

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

ユーザーの立場からすると、ユーザーは単にログインするだけです。認証と認可は、ユーザーのログインを成功させるために背後で行われます。ログインの最初、ユーザーは未認証の状態です。つまり、システムがユーザーのIDを知らない状態です。ログインの終わりには、ユーザーは認証と認可の両方を受けています。つまり、システムは、ユーザーが誰で、どのようなアクセス権を持つべきかを知っています。

システムは、ユーザーの認証と認可を行うために、以下のことを行います。

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

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

3. IDプロバイダーを使用して資格情報を検証します。IDプロバイダーは、資格情報を含む、ユーザーおよびIDに関する情報を保持する別のシステムです。

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

認証に関連する用語

IDプロバイダー

IDプロバイダー（IdP）は、ユーザーのIDを確立するシステムです。以下のようなものがあります。

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

IdPには、ホスティング型とクラウド型があります。ホスト型IdPとしては、MicrosoftADFSやShibbolethが一般的です。Microsoft Azure AD、Okta、Pingは多数のクラウドIdPの1つです。

認証プロトコル

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

認証フロー

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

• SP主導：認証は、サービスプロバイダーまたはアプリケーションによって開始されます。ユーザーは資格情報を入力し、アプリケーションはIDの検証のために外部IdPに通信します。これは最も一般的なフローです。
• IdP主導型：ユーザーはまずIdPにログインし、IdPがユーザーを確認した後にアプリケーションを起動します。

フェデレーテッドID管理

フェデレーテッドID管理は、FIMまたはフェデレーションと呼ばれることもあります。これは、1つ以上のアプリケーションの認証を提供するために、単一の外部IdPを使用するプロセスの包括的な用語です。フェデレーションは一般に、何らかの方法で時間制限されます。たとえば、ユーザーは仕事を始めるときに一度ログインします。これによって、その日使用する全てのアプリケーションに対して認証が行われます。しかし、翌日には再びログインして再認証する必要があります。前日にログアウトしていないとしてもです。

シングル・サインオン

シングルサインオン（SSO）は、1回のログインで複数のアプリケーションやシステムにアクセスできるようにするために使用されます。たとえば、あるユーザーがMicrosoft 365にログインすると、会社が許可した全てのMicrosoftアプリケーションにアクセスできるようになります。SSOという用語がフェデレーションに使われることもありますが、この2つのコンセプトはまったく同じものではありません。

多要素認証

多要素認証（MFA）は、基本的なユーザー名/パスワード認証に、もう1つのセキュリティレベルを追加するものです。MFAでは、IdPがユーザーのIDを確認したと見なす前に、ユーザーがコードを入力するか、質問に答えるか、トークンを使用することが要求されます。

信頼

認証において、信頼とは、アプリケーションまたはシステムと外部IdPが共有する情報または知識を指します。この知識によって両者の関係が確立され、互いが相手からの通信を正確で真実のものとして信頼できることを知ります。信頼がどのように確立されるかは、認証プロトコルに依存します。次の例は、OpenID ConnectおよびSAML 2.0に基づいています。

OpenID Connect

発行者に基づいてOpenID Connectを信頼します。発行者はURLのような値です。これはIDプロバイダーを確立します。たとえば、GoogleはOpenID Connectをサポートしており、発行者はhttps://accounts.google.comです。

発行者に基づいて、いくつかの追加設定項目があります。たとえば、OpenID Connectでは、信頼はパブリック/プライベート証明書署名によって確立されます。これは、JWKSと呼ばれる業界標準を使用しています。そのため、パブリック証明書の取得方法は設定により決定されます。

ほとんどのIDプロバイダーは、発行者に 「/.well-known/openid-configuration」を付けており、この情報を見つけやすくしています。Googleのドキュメントは以下で見つかります: https://accounts.google.com/.well-known/openid-configuration。

SAML 2.0

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

• エンティティ識別子 -アプリケーションまたはシステムがそのIDを確認するために確立した値

• エンドポイントURL -認証リクエストを受け取る外部IdPが決定する値

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

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