認証
概要
Pega Platform™での認証は、IDが確認されたユーザーやシステムしかアプリケーションにアクセスできないようにするものです。
認証は、識別(ID)と検証(V)の2つのステップで構成されています。
- 識別とは、自分が誰であるかをシステムに伝えることであり、通常はユーザー名を入力することです。
- 検証とは、ユーザー本人であることを証明することです。通常、ユーザーとアクセスするシステムとの間で共有される秘密のパスフレーズを通して行われます。
Pega Platformの認証には次のものがあります。
- ユーザーログイン
- プラットフォームへの外部サービスリクエスト
- 外部サービスへのプラットフォームリクエスト
すべての認証サービスでPRAuthサーブレットを使用しています。
ただし、Pega Platformの以前のバージョンとの下位互換性のために、PRAuthの代わりにPRServletを使用して認証できます(つまり、ログインURLに/prweb/PRServletが含まれます)。 認証タイプに関する詳細については、「Application URL patterns for various authentication service types」を参照してください。
ユーザーログイン
ユーザーは、ログイン情報を入力するか、シングルサインオン(SSO)を使用し、ブラウザーを利用してアプリケーションにログインします。
Authentication Service
Authentication Serviceは、外部のIDプロバイダーやシステムでユーザーを認証するために使用されます。
Authentication Service機能を使用して、デフォルトの認証プロセスを上書きまたは拡張できます。 Authentication Serviceを作成することで、事前認証と事後認証のアクティビティを使用するなど、デフォルトの機能よりも専門的な認証要件を実装できます。
Authentication Serviceは、Data-Admin-AuthServiceクラスのインスタンスです。 すべての認証サービスでPRAuthサーブレットを使用しています。
デフォルトのサーブレットであるPRAuthには、統合された認証ゲートウェイが用意されており、新しい認証サービスを実行するためにprweb.xmlを編集したり、サーバーを再起動したりする必要はありません。
ただし、Pega Platformの以前のバージョンとの下位互換性のために、PRAuthの代わりにPRServletを使用して認証できます(つまり、ログインURLに/prweb/PRServletが含まれます)。 PRServletを使用する場合、セキュリティーポリシーのランディングページにあるさまざまなコントロールを使用して、セキュリティーポリシーを有効にします。 認証タイプに関する詳細については、「Application URL patterns for various authentication service types」を参照してください。
次の表は、Pega Platformでサポートしているユーザーログイン用のプロトコルを示しています。
認証タイプ | プロトコル |
---|---|
SAML 2.0 | SAML 2.0プロトコルをサポートする、Microsoft Active Directoryなどの外部IDプロバイダー |
OpenID Connect | OpenID Connect(OIDC)プロトコルをサポートする外部IDプロバイダー |
Basic credentials | ユーザーIDとパスワードは、Pega Platformデータベースまたはその他の内部/外部データソースに保存されます。 注:本番環境では、Basic Credentials認証タイプは推奨されません。 |
Token credentials | 外部IDプロバイダーまたはPega PlatformのOAuth 2.0認証レイヤーで検証されるトークン(オフラインのモバイルアプリケーションでよく使用されます) |
Anonymous | セッションの途中までは検証が行われません。 たとえば、認証されていないユーザーは、ショッピングカートに商品を追加し、チェックアウト時にログイン情報を入力できます。 |
Custom | カスタム認証サービスを設定して、IDプロバイダー内に保存されている情報を使用して、Pega Platformにおけるユーザーの役割や権限を決定できます。 認証サービス(SAML 2.0、OpenID Connect、トークンログイン情報など)を使用して、シングルサインオン(SSO)ソリューションを実装できます。 認証サービスルールフォームで簡単な選択肢を使用して、多要素認証などのポリシーを実装することで、アプリケーションの安全性を向上させます。 |
Kerberos | Kerberosは、秘密鍵暗号方式を使用してクライアントサーバーノードの通信をセキュリティで保護するネットワーク認証プロトコルです。 ユーザーのKerberosログイン情報を使用して外部システムに接続し、そのシステムの認証を行うことができます。 |
たとえば、ユーザーまたは従業員が特定のアプリケーションで認証を行うと、組織のMicrosoft Active Directoryで定義されている役割がユーザーまたは従業員に割り当てられます。 PegaアプリケーションのオペレーターIDレコードを開発者またはユーザーのアクセスグループで手動で変更する必要はなく、SAML2.0またはカスタムタイプの認証サービスで実行できます。
サービスルールを通したPega Platformへの外部サービスリクエスト
外部システムやアプリケーションでは、Pega PlatformまたはPega Platformアプリケーション内で定義されたRESTサービスを呼び出し、ケース情報を取得できます。 このタイプの認証では、サービスタイプとサービスパッケージのインスタンスを使用します。 サポートされている認証フォームの例には次のものがあります。
- 基本認証
- OAuth 2.0
- Custom authentication
コネクタールールを通した外部サービスへのPega Platformリクエスト
Pega Platformアプリケーションは、外部RESTサービスコールを呼び出して情報を取得するために、外部システムまたはアプリケーションの認証を行う必要があります。 このタイプの認証では、認証プロファイルとOAuthプロバイダーのデータインスタンスを使用します。 サポートされている認証フォームの例には次のものがあります。
- 基本認証
- NT LANマネージャーログイン情報(NTLM)
- OAuth 1.0とOAuth 2.0
認証プロファイル
Pegaが他のアプリケーションと通信を行う場合、データとメッセージを安全に移動させる必要があります。 認証プロファイルは、他のアプリケーションとの通信のセキュリティを管理するために使用されます。
Pegaの認証プロファイルは、通信を保護するためにコネクターやサービスルールで参照されます。 ただし、特定の目的のために作成される認証プロファイルはほとんどありません(Microsoft Azure認証プロファイルなど)。
認証プロファイルデータインスタンスは、Connect CMIS、Connect dotNet、Connect HTTP、Connect JMS、Connect REST、Connect SAP、およびConnect SOAPの各ルールのService タブと、FTP ServerルールのEnvironment タブで指定できます。
認証プロファイルのタイプには次のものがあります。
認証プロファイルタイプ | 使用するタイミング |
---|---|
Basic | 基本HTTP認証ログイン情報 |
NTLM | NT LANマネージャーログイン情報 |
OAuth 1.0a | OAuth 1.0認証 |
OAuth 2.0 | OAuth 2.0認証 |
Amazon Web Services(AWS) | Amazon S3 BLOBストレージリポジトリ |
Microsoft Azure | Azure BLOBストレージリポジトリ |
Data-Admin-Security-AuthenticationProfileクラスには、認証プロファイルデータインスタンスが含まれます。
認証サービス | 認証プロファイル |
---|---|
認証サービスをアプリケーションに設定することで、検証されたIDを持つユーザーとシステムのみが、アプリケーション、ウェブページ、API、およびデータにアクセスできるようにします。 |
この機能は、統合コネクターを介した外部システムへの統合リクエストを安全な方法で認証するために使用されます。 |
たとえば、ユーザーがクレジットカードアプリケーションにログインして残高やトランザクションを確認する場合、アプリケーションは認証サービスを利用してユーザーのIDやログイン情報を検証します。 | たとえば、クレジットカードアプリケーションが、カードのトランザクションを取得するために外部アプリケーションに接続する場合、外部システムまたは外部アプリケーションは、認証プロファイルを使用して、リクエストを認証します。 |
このトピックは、下記のモジュールにも含まれています。
- 認証スキームの定義 v3