今日やること

昨日の記事で挙げたPolicy Agentでできることから、下記の2つの動作を実際に確認していきたいと思います。

認証したユーザーの属性情報の連携ができる
Webサーバーの特定のリンクを踏むと、サインアウトできる

前準備

まず、検証用のアカウントを作成します。OpenAMの管理者コンソールにはアカウント管理のインターフェースがあるので、ここから作業を行います。

OpenAMの管理者アカウント（ユーザー名はamadmin）でサインインし、Top Level Realm => Applications => Subjectsとアクセスし、新規をクリックします。

アカウント作成の画面が表示されますので、下記のユーザーを作成します。

ID
- johnd
名
- john
姓
- doe
フルネーム
- john doe
パスワード
- （適当に）

こんな感じです。

認証したユーザーの属性情報の連携ができる

まず、ユーザーのアカウントの属性情報が連携できることを確認します。

プロファイル属性処理の設定

OpenAMの管理者アカウント（ユーザー名はamadmin）でサインインし、Top Level Realm => Applications => Web Agentsにアクセスし、昨日作成を行ったPolicy Agentの設定であるWebPolicyAgentForApache22をクリックします。

アプリケーションのタブからプロファイル属性処理をクリックします。

このプロファイル属性処理は、認証したユーザーのプロファイル属性（名や姓、設定していれば所属や役職）をHTTPのHEADERやCookieにセットするといった設定となります。
ここでは、試しにcn（氏名）、givenName（名）とsn（姓）を連携してみましょう。

こんな感じで書きます。

マップキー	マップ値
cn	CUSTOM-Common-Name
givenName	CUSTOM-Given-Name
sn	CUSTOM-Sir-Name

入力後はこんな感じです。

ヘッダーが連携されていることを確認するCGIをおく

この作業はPolicy AgentがインストールされたApacheが動いているサーバー（本記事ではweb.example.com）で行います。

適当にPerlで書き起こします。別にphpinfo()でも構わないと思います。

cat /var/www/cgi-bin/headerinfo.pl 
#!/usr/bin/perl --
use strict;
use warnings;
use CGI;

my $q = CGI->new;
my %headers = map { $_ => $q->http($_) } $q->http();

print $q->header('text/plain');
print "Got the following headers:\n";
for my $header ( keys %headers ) {
    print "$header: $headers{$header}\n";

CGIファイルに実行権限を付与します。

$ sudo chmod +x /var/www/cgi-bin/headerinfo.pl

PerlのCGIパッケージをインストールします。

$ sudo yum -y install perl-CGI

検証用アカウントでアクセス

ブラウザを立ち上げて、先ほど作成したCGIプログラムにアクセスします。本記事でのURLはhttps://web.example.com/cgi-bin/headerinfo.plとなります。

アクセスをするとOpenAMのサインページが表示されますので、検証用アカウント（ユーザー名はjohnd）でサインインします。

サインイン後、CGIプログラムが実行され、現在セットされているHTTP HEADERが表示されます。
設定を行った3つのCUSTOM HEADERがセットされていることが確認できますね。

軽くまとめ

プロファイル属性処理の設定を使うと認証済みユーザーの属性情報を連携できる
このHTTP HEADERを使って、アプリケーションの既存の認証を通したりできる（無理やりにでも）
- アプリケーションでHTTP HEADERをみて認証してもらうように既存の認証を変更してもらうとか
- Apache上でCGIプログラムを動かして、既存の認証フォームにPOSTしちゃうとか（代理認証とか呼ばれてるようです）

Webサーバーの特定のリンクを踏むと、サインアウトできる

次行ってみましょう。

実際的なことを考えると、Policy Agentが導入されるApacheやそのバックエンドのアプリケーションサーバーで動いているアプリケーションは既存のサインアウトの機能があるでしょう。
ただ、アプリケーションのサインアウトだけしても、OpenAMのセッションは生きているので、アプリケーションには認証なしでアクセスできてしまいます。ユーザーが意思を以ってサインアウトするのであれば、OpenAMのセッションも消して欲しいな～？...というようなニーズに応えられるのが、ここで紹介するシングルログアウトの機能です。

エージェントログアウトURL

それでは、設定していきます！
プロファイル属性処理の設定と同じように、OpenAMの管理者アカウント（ユーザー名はamadmin）でサインインし、Top Level Realm => Applications => Web Agentsにアクセスし、昨日作成を行ったPolicy Agentの設定であるWebPolicyAgentForApache22をクリックします。

その後、OpenAMサービスタブから、エージェントログアウトURLをクリックします。

ここではシングルログアウトするURLを設定します。認証済みのユーザーは、このPolicy Agentが導入されたWebサーバー上のURL にアクセスすると OpenAM セッションからログアウトされちゃいます。
本記事ではhttps://web.example.com/signoutと設定します。

エージェントログアウトURLにアクセス

それでは試してみましょう。
まず、普通にPolicy Agentが導入されたApacheにアクセスします。本記事ではhttps://web.example.com/となります。

OpenAMのサインイン画面が表示されますので、検証用アカウント（ユーザー名はjohnd）でサインインします。

サインインに成功すると、おなじみのApacheの画面が表示されます。
ここで、アドレスバーに先ほど設定したエージェントログアウトURLを入力し、アクセスを行います。本記事ではhttps://web.example.com/signoutとなります。

すると、無事にOpenAMのセッションも破棄された雰囲気の画面が表示されます。

デベロッパーツールで確認してみますと、きちんとブラウザのCookieストアからも消されてますね！

軽くまとめ

Policy Agentを導入済みのWebサーバーでシングルログアウトするためのURLを設定できる
認証済みのユーザーはそのURLを踏むとOpenAMのセッションが消されて、OpenAMのサインアウト画面にリダイレクトされる

ただ、単純にアプリケーションが本来持っているサインアウトURLを設定するのは難しいんじゃないかなぁ？やっぱり、Policy Agentによって、守られているとはいえ、アプリケーションのセッションも消してから、OpenAMのセッションを消す必要があるんじゃないかと。アプリケーションのセッションが残ったまんまだと、再度OpenAMで認証したとしても、前のアプリケーションのセッションを使いまわしてしまって、想定外のタイミングでアプリケーションのセッションタイムアウトが起こりそうだなぁ。望ましい設定としては、アプリケーションのサインアウトのURLじゃなくて、アプリケーションのサインアウト完了のURLかなぁ。

〆

今日はこのぐらいで！
明日はアクセス制御するためにポリシーと呼ばれている設定をいじってみる。

ばい！