はじめに
第5回はOpenAMの認証方式について解説します。
OpenAMはさまざまな認証モジュールを提供しており、それらを組み合わせて企業のニーズに合った認証方式を実現することができます。認証モジュールには、RDBMSのユーザデータで認証する「JDBC認証」や、Windowsドメインのアカウントで認証する「Windows Desktop SSO認証」などがあります。OpenAM 10.0からは、FacebookなどのOAuth 2.0プロバイダーで認証を行う「OAuth 2.0クライアント認証」や、不正アクセスを禁止する「アダプティブリスク認証」(リスクベース認証)なども追加されました。
今回はまず、OpenAMが提供する認証モジュールとそれをどのように利用するかについて説明します。そしてその応用として一般的な企業で認証を行う際に必要となりそうなセキュリティ要件を例示し、それを満たすための認証モジュールの設定と動作確認を行います。
対象読者
- SSOとOpenAMについてより理解したい方
- OpenAMの導入を検討している方
- OpenAMが提供する認証モジュールについて知りたい方
- OpenAMの多要素認証の設定方法について知りたい方
OpenAMが提供する認証モジュール
OpenAM 10.0では、以下の認証モジュールが提供されています。
認証モジュール名 | 概要 |
Active Directory | Active Directoryで管理されたユーザで認証を行うための認証モジュールです。 |
HOTP | HMACワンタイムパスワード(HOTP)認証モジュールは、データストア認証モジュールと連携して動作し、ユーザのメールアドレスや電話番号にワンタイムパスワードを送信します。 |
HTTP基本 | HTTPで定義される認証方式の一つであるBasic認証を使用する認証モジュールです。認証ダイアログで入力したIDとパスワードが適正であるか、LDAP認証モジュールを使って検証します。 |
JDBC | MySQLやOracle DBなどのRDBMSで管理されたユーザで認証を行うための認証モジュールです。 |
LDAP | OpenLDAPやOpenDJで管理されたユーザで認証を行うための認証モジュールです。 |
MSISDN | Mobile Station Integrated Services Digital Network(MSISDN)認証モジュールは、携帯電話などの端末に関連付けられたMSISDN番号を使用して、非対話的な認証を可能にします。 |
OAuth 2.0 | OAuth 2.0のクライアントアプリケーションとなり、 FacebookやWindows Liveなどに認証を依頼することができます。 |
RADIUS | Remote Authentication Dial In User Service(RADIUS)認証モジュールは、 RADIUSサーバによるユーザ認証を実行します。 |
SAE | Secure Attribute Exchange(SAE)認証モジュールは、既存のアプリケーションなどで認証されたユーザの認証情報をOpenAMにセキュアに転送する場合に使用されます。 仮想フェデレーションでも使用されます。 |
SecurID | SecurID認証モジュールは、RSA SecurIDによるユーザ認証を実現します。 |
Windows NT | Windows NT認証モジュールは、Microsoft Windows NTサーバによる認証を行うことができます。 |
WindowデスクトップSSO | WindowsデスクトップSSO認証モジュールは、Kerberos認証を使用します。 Kerberos Distribution Center(KDC)で認証されたユーザは、 ログインの条件を再度提示しなくてもOpenAMに認証されます。 |
WSSAuth | Webサービスセキュリティ認証(WSSAuth)モジュールは、WebサービスクライアントからWebサービスプロバイダへのリクエストに含まれる認証トークンを検証します。 |
アダプティブリスク | 不正アクセスのリスクに配慮した認証モジュールです。 ログインユーザの地理的位置情報や、アクセス状況やIPアドレス、ブラウザの設定情報などからリスクを評価し、不正アクセスを防止します。 |
データ ストア |
デフォルトの認証モジュールです。ディレクトリサーバで認証を行います。 |
メンバーシップ | ログイン画面に「新規ユーザ」ボタンが追加され、OpenAMに未登録のユーザが自身の情報を入力して新規ユーザ登録できるようになります。 |
証明書 | X.509デジタル証明書を利用することで、ユーザ名とパスワード(またはその他の資格情報)を必要とせずに、セキュアな認証ができます。 |
匿名 | 有効にすると、ユーザはanonymousユーザとしてOpenAMにログインできるようになります。 |
連携 | フェデレーション(連携)モジュールは、SSOプロトコル(SAML、SAMLv2、ID-FF、およびWS-Federation)のメッセージを検証した後、ユーザセッションを作成するためサービスプロバイダによって使用されます。 |
上記認証モジュールで要件を満たせない場合は、独自の認証モジュールを開発して組み込むこともできます。認証モジュールの構成要素であるclassファイルやxmlファイルを単一のjarファイルにまとめて、OpenAMのライブラリディレクトリにデプロイすると、管理コンソールに設定画面が表示されます。そこで必要な設定を行うことにより、ユーザがログインする際にその認証モジュールによる認証を要求できるようになります。
多要素認証
OpenAMは複数の認証モジュールを組み合わせることで、よりセキュアな認証を可能にする「多要素認証」機能を実装しています。この認証の組み合わせを「認証連鎖」といいます。図1は認証連鎖の設定例です。
認証連鎖内の各認証モジュールには、実行後の動作を決定する「条件」を設定します。条件には以下の4種類があります。
条件 | 実行後の動作 |
オプション (optional) |
認証モジュールの成功は必須ではありません。成功するかどうかに関係なく、リスト内の次の認証モジュールに進みます。 |
十分 (sufficient) |
認証モジュールの成功は必須ではありません。成功すると、リスト内の次の認証モジュールに進みません。失敗すると、リスト内の次の認証モジュールに進みます。 |
必須 (requisite) |
認証モジュールの成功が必要です。成功すると、リスト内の次の認証モジュールに進みます。失敗すると、リスト内の次の認証モジュールに進みません。(※1) |
必要 (required) |
認証モジュールの成功が必要です。成功するかどうかに関係なく、リスト内の次の認証モジュールに進みます。(※1) |
図1で示した認証連鎖を設定した場合、各認証の成否と全体の結果は以下のようになります。
認証の成否 | ||||||||
独自開発認証(必要) | 成功 | 成功 | 成功 | 成功 | 失敗 | 失敗 | 失敗 | 失敗 |
Windows NT認証(十分) | 成功 | 失敗 | 失敗 | 失敗 | 成功 | 失敗 | 失敗 | 失敗 |
Windows Desktop認証(必須) |
|
成功 | 成功 | 失敗 |
|
成功 | 成功 | 失敗 |
LDAP認証(オプション) |
|
成功 | 失敗 |
|
|
成功 | 失敗 |
|
全体の認証結果 | 成功 | 成功 | 成功 | 失敗 | 失敗 | 失敗 | 失敗 | 失敗 |
2~4回の認証が求められ、その中の一部で失敗があっても全体としては成功となることもあります。
OpenAM 10.1以前のバージョン(10.1含む)では、「requisite」「required」の日本語訳が誤って「必要」と「必須」となっており、意味が逆転していました。このバグはOpenAM 10.2から修正されています。認証連鎖を設定する際はバージョンに留意してください。