freedom-man.com

ブログは俺のセーブポイント

Tag: openam (page 1 of 2)

OpenAMでHOTP認証してみる【GoogleAuthenticator編】

前回はOpenAMでOATHのTOTP認証をやりました。

今回はGoogleAuthenticatorでHOTP認証をやってみます。

※設定は前回とほとんど同じなので省略しまくってます。

 

HOTPの仕組みに関しては以下のリンクが詳しいです。

OSSによるアイデンティティ管理(2):不正ログインを食い止めろ! OpenAMで認証強化 (2/2) – @IT

 

参考URL↓

Configure OpenAM to use OATH for Strong Authentication – OpenAM – Confluence 

 

1. SecretKeyの生成

任意の秘密鍵を生成し、それぞれのbase16エンコード、base32エンコードの値を取得します。

 

2. OpenAMの設定

アクセス制御>対象のレルム>データストア>embedded を選択して

LDAPユーザ属性のroomNumberを追加します。

openam-ldapsetting4

アクセス制御>対象のレルム>認証 のモジュールインスタンスでOATHの設定を変更

openam-hotp-setting

前回からの変更点は

使用するアルゴリズム→HOTP

カウンタ属性名→roomNumber

の部分です。

 

3. LDAPの設定

前回同様にLDAPサーバに接続して対象のユーザのtitle属性とroomNumber属性を追加・変更します。

ads-ldap-hotp

秘密鍵のbase16エンコード値をtitleに入力して、roomNumberは0を入力してください。

 

4. Google Authenticatorの設定

今回のQRコードのURL値は以下の形式になります。

これをGoogle AuthenticatorのQRコードリーダで読み込ませるか、以下のように手入力でセットします。

googleauthenticator-hotp-manual

 

あとは前回同様、ログイン画面でOTPコードを送信すれば認証完了となります。

OpenAMでTOTP認証してみる。

OpenAMの多要素認証シリーズとしてTOTP認証をやってみます。

TOTP認証に関しては以下のサイトが詳しいです。

OSSによるアイデンティティ管理(2):不正ログインを食い止めろ! OpenAMで認証強化 (2/2) – @IT

 

今回は以下のサイトに従って設定していきます。

Google Authenticator and OpenAM – OpenAM – Confluence

 

1. SecretKeyの生成

適当なSecretKeyを決めてbase16エンコード、base32エンコードした値を生成します。

例えば”test12345abcdefg”というキーであれば

base16エンコード値→74657374313233343561626364656667

base32エンコード値→ORSXG5BRGIZTINLBMJRWIZLGM4======

となります。

 

各エンコード値は以下のサイトで簡単に生成できます。

http://online-calculators.appspot.com/base16/

http://online-calculators.appspot.com/base32/

※秘密鍵を第三者に渡すことになるので検証用にお使いください。

2. OpenAMの設定

アクセス制御>対象のレルム>データストア>embedded を選択し

LDAPユーザ属性にtitleとdescriptionを追加します。

openam-ldapsetting2

openam-ldapsetting3

次に アクセス制御>対象のレルム>認証 のモジュールインスタンスでOATHをクリックします。

openam-totp-authmodules

OATHを以下のように設定します。

openam-oathsetting

今回は検証用なので秘密鍵は8桁にしちゃってますが、本番用はもっと大きい桁数(デフォルト32桁)にしてください。

秘密鍵の属性にtitle、最終ログイン時間属性にはdescriptionを割り当てます。あとはデフォルト通り。

※検証用なので属性はテキトーです。

 

また、TOTPのタイムステップ感覚とタイムステップ数ですが

今回利用するGoogle Authenticatorはトークンの生成間隔が30秒なのでデフォルト通りでOKです。

 

最後に認証連鎖を設定します。

こんな感じの認証連鎖を作成↓

openam-totp-authchain

組織認証設定を変更

openam-totp-orgsetting

3. LDAPの設定

OpenAMのデータストア(LDAP)にアクセスしてtitle属性に秘密鍵を格納します。

LDAPにアクセスする手段としてGUIツールのApache Directory Studioを利用します。

 

まず、メニューからLDAP>New Connectionを選択します。

ads-ldapmenu

ホスト名とポートを設定します。ポート番号はデフォルト50389です。

※検証用なので非SSLになっています。

ads-ldapconnection1

バインドするユーザとパスワードを入力します。

デフォルトでは以下のようになります。

BindDN:cn=Directory Manager

Bind password:adminのパスワード

ads-ldapconnection2

BaseDN等を設定します。

ads-ldapconnection3

EditOptionsはデフォルトのままでOKです。

ads-ldapconnection4

あとは接続して対象のユーザを ou=people, dc=openam, dc=forgerock, dc=org 内から探して

title属性に1で生成したbase16エンコードの秘密鍵を格納します。

ads-ldap-totp

 

4. Google Authenticatorのインストールと設定

まずは Google Authenticatorをインストールします。

次にGoogle Authenticatorに読み込ませるQRコードを生成します。

QRコードは以下のサイトで簡単に生成できます。

QR Code Generator – create QR codes for free (Logo, T-Shirt, vCard, EPS)

※秘密鍵を第三者に渡すのはキケンなので検証用にお使いください。

 

URLは以下の形式で入力します。

QRコードはこんな感じになります。

qrcode-totp-secretkey

Google Authenticatorを立ち上げるとアカウントの追加画面があるので

「バーコードをスキャン」を選択して上記のQRコードを読み込みます。

googleauthenticator-account

読み込むと自動的に秘密鍵が設定され以下のような画面が表示されます。

googleauthenticator-totp

この6桁の数字がTOTPになります。

 

QRコードを使わずに「提供されたキーを入力」で秘密鍵を手入力で設定してもOKです。

googleauthenticator-totp-manual

 

5. 動作確認

通常通りID/パスワードでの認証が完了するとOATH認証の画面が出ます。

openam-totp-authpage

ここでGoogle Authenticatorで取得したTOTPを入力すれば認証完了になります。

OpenAMでHOTP認証してみる【メール送信編】

これまでOpenAMでシングルサインオンをするためのパターンをいくつか紹介しました。

シングルサインオンは「一回ログインすれば複数のサービスを利用できる」ことが利点ですが

反面、「攻撃者にログインされると複数サービスを利用されてしまう」という欠点もあります。

この欠点を補うのが「多要素認証」になります。

 

今回は多要素認証の一つであるHOTP認証をOpenAMでやってみたいと思います。

 

参考URLはこちら

OSSによるアイデンティティ管理(2):不正ログインを食い止めろ! OpenAMで認証強化 (1/2) – @IT

OpenAMが提供する様々な認証方式 (1/4):CodeZine

Netforest Developer’s Note – OpenSSOでワンタイムパスワード

Chapter 2. Defining Authentication Services 

https://www.osstech.co.jp/_media/techinfo/seminar/openam-shibboleth.pdf

 

OpenAMの設定

アクセス制御>対象のレルム>認証 のモジュールインスタンスでHOTPをクリック。

openam-hotp-authmodules

今回はGmailのSMTPサーバを使うので以下のように編集。

ユーザ名/パスワードはそれぞれGmailのユーザ名/パスワードを入力する。

openam-hotpsetting

アクセス制御>対象のレルム>認証 の認証連鎖で新規の認証連鎖を作成

openam-authchain1

対象の認証連鎖の設定を以下のように編集します。

openam-hotp-authchain1

認証設定を以下のように変更します。

openam-hotp-core

上記設定で/openam/UI/LoginでログインするときにはHOTPの認証連鎖設定が適用され

/openam/consoleでログインすると きには通常のID/パスワード認証のみの設定が適用されます。

これにより、設定ミスによってadminがログインできない状態になることを防ぎます。

 

最後に アクセス制御>対象のレルム>対象>対象のユーザ でメールアドレスを設定openam-usermailsetting

 

動作確認

ログイン画面(/openam/UI/Login)でID/パスワード認証後、以下の画面が出てきます。

openam-hotp-authpage

OTPコードの要求をすると対象のユーザ(ログイン失敗したユーザ)のメールアドレスに

ワンタイムパスワードの通知メールが届きます。(自動送信も可能)

openam-otp-mail

あとはこのワンタイムパスワードを「OTPコードの入力」に入れてOTPコードの送信をすれば認証完了。

openam-hotp-authpage2

 

このHOTP認証モジュールではメール送信以外に

SMSを使って携帯電話にワンタイムパスワードを送ることも可能みたいです。

OpenAMでSSO【OpenIG編】

今回はOpenAM+OpenIG+PolicyAgentなSSOをやってみます。

以下のような構成になります。

openig-architecture

 

 

フローを簡単に説明すると

1. UserAgentがWebサーバにアクセス(初回)

2. Policy Agentがリクエストをインタラプト、Cookieが入っていないのでOpenAMに認証要求リダイレクト

3. OpenAMで認証後、Webサーバにリダイレクト

4. 認証されている(=Cookieが入っている)のでPolicy AgentはCookie値をOpenAMに問い合わせて

ユーザ名/パスワードを取得

5. Policy Agentが取得したユーザ名/パスワードをヘッダに入れてOpenIGにリクエスト

(パスワードは暗号化されている)

6. OpenIGはログイン画面がリクエストされた時のみヘッダからユーザ情報を取得し、認証リクエストを行う

(通常のフォームPOSTを模倣する)

7. Webアプリは認証リクエストを受け取り、ユーザ認証実行後OpenIG・Policy Agent経由で

UserAgentにレスポンスを返して認証終了

といった感じです。

 

OpenIGはリクエストのプロトコルやURI、ヘッダ等の情報やフォワードしたHTTPリクエストに対する

レスポンスの正規表現マッチングを使って処理を分岐させたり

HTTPクライアントとして動かしたりできるリバースプロキシソフトウェアになります。

 

今回はOpenIGを使ってOpenAMで認証されたユーザ名/パスワードでWebアプリにSSOするフローをやってみます。

※本記事ではOpenAMのユーザ名/パスワード=Webサイトのユーザ名/パスワードになることを想定しています。

 

参考URLは以下になります。

OpenAMによるシングルサインオン(2)リバースプロキシー編 – Tech-Sketch

OpenIG | LAJ技術ブログ

Chapter 5. Detailed Use Cases

Chapter 7. Tutorial On OpenAM Password Capture & Replay

Chapter 11. Configuration Templates

 

1. OpenIGのインストール

Javaのアプリケーションサーバで動作するらしいのでtomcat使ってやってみます。

ダウンロードはここから→https://forgerock.org/downloads/openig-builds/

 

展開したwarファイルをtomcatのルートに設置

tomcat実行ユーザのホームを/etc/passwdで調べて以下のディレクトリに設定ファイルを作成

 

あとはconfig.jsonの設定ファイルを書き換えていくだけでOK。(3を参照)

 

2. OpenAMの設定

Policy Agent編でのPolicy Agentの仕事はトークンの検証のみで良かったのですが

今回はユーザ情報をOpenIGに送る必要がある(OpenIGからOpenAMのユーザ情報を取得できない)ことから

エージェントが”OpenAMからユーザ情報を取得する”設定に書き換える必要があります。

 

アクセス制御>対象のレルム>エージェント>対象のエージェント で

アプリケーションタブをクリックしてセッション属性処理を以下のように編集

openam-openig-setting1

 

アクセス制御>対象のレルム>認証 で

すべてのコア設定をクリックして認証ポストプロセスクラスを以下のように編集

openam-openig-setting2

openam-openig-setting3

 

次にPolicy Agent→OpenIG間の通信でユーザのパスワードを暗号化する為の対称鍵(DES)を作成します。

DESキー作成のためのモジュールはOpenAMに入っているので以下を実行して暗号化の対称鍵を生成

 

設定>サーバー及びサイト>対象のサーバ>高度 で

生成した暗号化キーを追加

openam-openig-passwd

 

また、XUIを使っているとパスワードがヘッダに付与されなかったりするみたいなので(参考URL

設定>認証>コア のXUIインターフェースを無効にしてください。

openam-xui

 

3. OpenIGの設定

今回は超簡単に特定のIDのformタグがあればPolicy Agentから取得した

ユーザID/パスワードを自動的にPOSTして認証を行うような設定にします。

config.jsonは以下のとおり

 

シーケンスはこんな感じ(テキトーです)

openig-sequence

 

CryptoHeaderFilterのkeyには2で作成した暗号化キーを設定してください。

上記設定ではhtmlの正規表現パターンマッチによりログイン画面の判定をしていますが

URLでの判定も可能なので、リクエストしたURLに応じて処理を分けるのも有りです。

 

また、今回は必要最低限のフォームデータをPOSTしていますが

通常formにはCSRFトークン等のnonceがCookieあるいはhiddenに埋め込まれていると思うので

その値を${exchange.response}のプロパティや正規表現を使ってセットする必要があります。

 

OpenIGからデータベースやテキストファイルにアクセスすることも可能なので

WebアプリとOpenAMのログインユーザのマッピングも可能です。

※通常のフォームPOSTなのでOpenAMのパスワードを利用しない場合は

Webアプリのユーザのパスワードを暗号化するなりしてどこかに保存しておかなければなりません。

 

config.jsonは複雑なので参考URLのChapter 11. Configuration Templatesをベースに作成 すると楽です。

 

4. Webサーバの設定

Apacheはポート80のリクエストをポート8080のOpenIG(tomcat)にフォワーディングする設定にします。

 

Policy Agentのインストール・設定は以前の記事を参照。

 

Python/Flaskのサンプルアプリは以下の通り。

ログイン画面出して認証するだけのプログラムです。面倒だったのでセッション立ててませんw

agent.py

templates/login.html

 

あとはagent.pyを稼働させてWebサイト(/login)にアクセスすると、クライアント側からは

Webサイトにアクセスする→OpenAMにリダイレクトして認証→Webサイトに自動認証

という流れで画面遷移し、SSOが実現できます。

 

OpenIG+Policy AgentはPolicy Agentのみのパターンとやっていることは同じですが

Policy AgentのパターンでWebアプリを改修しないといけない部分を

OpenIGが担っているのでWebサイト側は基本的には改修不要になります。

 

ただし上記例はWebとOpenAMのユーザ名とパスワードが一致している必要があり

一致していない場合はDBでマッピングする、Webアプリ内からOpenAMのREST API叩く等の

仕組みを検討する必要があります。

 

OpenAMでSSO【OpenID Connect編】

今回はOpenAMを使ってOpenID ConnectでSSOを実現したいと思います。

この方法だとPolicy Agentと同様にWebアプリの改修が必要になりますが

OpenID Connect準拠なのでセキュリティ等が担保されているのが利点です。

 

以下、参考URLになります。

最新のOpenAMを導入してOpenID Connect ServerとClientを実装する(IdP編)

OSSによるアイデンティティ管理(4):OpenAMのOpenID Connectへの対応 (3/3) – @IT

Chapter 3. Using RESTful Web Services 

Chapter 6. Configuring Policy Agent Profiles

Chapter 12. Managing OAuth 2.0 Authorization

 

SFDCにはOpenID ConnectのRP側の機能もあるので、SFDCとOpenAMをOpenID ConnectでSSOしてみます。

 

1. OpenAM側の設定

基本的に参考URL通りにやっておけばOKで

トップページからOAuth2の設定をクリックして作成

openam-oauth2setting

openam-oauth2-create

で、アクセス制御>対象のレルム>エージェント>OAuth2.0クライアントでエージェントを作成

openam-oauth2-agent

エージェントの名前がClientID、パスワードがClientSecretになります。

openam-oauth2-createagent

作成後に細かい設定ができます。

リダイレクトURI↓

openam-oauth2-redirecturi

スコープ↓

openam-oauth2-scope

デフォルトのスコープ↓

openam-oauth2-defaultscope

 

2. 簡単な動作確認

OpenAMのOAuthサーバの各エンドポイントは以下のURLにアクセスして取得します。

{OpenAMのURL}/.well-known/openid-configuration

 

{OpenAMのURL(ex. http://openam.example.com:8080/openam)}/oauth2/authorize?response_type=code&client_id={設定したエージェント名}&redirect_uri={設定したリダイレクトURI}&scope=profile%20openid

にアクセスしてログインを行うと以下の認可画面が出てきます。

openam-authpage

 

デザインが…とツッコミたい気持ちは抑えてAllowを押します。

そうすると指定したredirect_uriにcodeが返ってくるので

tokenエンドポイントの{OpenAMのURL}/oauth2/access_token に対して

client_id={設定したエージェント名}&code={取得したCode値}&grant_type=authorization_code&client_secret={設定したパスワード}&redirect_uri={設定したリダイレクトURI}

をPOSTします。

 

レスポンスはこんな感じ。

id_tokenはデコードするとこんな感じ。

 

3. Salesforceに対してSSOしてみる。

セキュリティのコントロール>認証プロバイダ から新規の認証プロバイダを作成

sfdc-authprovider

内容はこんな感じ

sfdc-openam-authprovideredit

作成するとURLが色々と設定されるので、コールバックURLをOpenAM側でも設定する

sfdc-openam-authprovidedr

openam-sfdc-redirecturi

 

 

これで設定は完了。

あとは既存ユーザをリンクするURLでOpenAMユーザとSFDCユーザのマッピングを行い

シングルサインオン初期化URLを使うなり、私のドメインから認証サービス追加するなりしてSSOできます。

 

SFDCはSAMLサポートしているのでOpenAM利用するんだったらSAMLの方で良いと思いますが

OpenID Connectの方は証明書の交換が必要ないので楽っちゃ楽です。

ただし、SFDCのOIDCはユーザの一括マッピングが厳しそうなので、そう考えるとSAMLになっちゃうんですが。

Older posts

© 2017 freedom-man.com

Theme by Anders NorenUp ↑