社内に多数のWebアプリケーションが乱立し、それぞれが異なったユーザー認証を採用しているため、ユーザーの利便性が損なわれていることがあります(サイト毎のユーザーID・パスワードを覚えなければならない、異なったサイトに行くたびにユーザー認証が必要)。これを解決するために、ユーザー認証を一元化する手段としてオープンソースのシングルサインオンのプロダクトOpenAMを用い、既存のWebアプリケーションをどのような手順でシングルサインオン化できるかを2回にわたって紹介します。 今回はOpenAMのエージェントを用い、Webアプリケーションのソースコードを改変する手法を見ていきます。 OpenAMとは OpenAM は、旧サン・マイクロシステムズ社のOpenSSOの流れをくむWebアプリケーションのシングルサインオンを実現するための認証基盤で、現在はForgeRock社において開発され、CDDL
SSOの構成 SSOを実現するシステムは、一般的にリバースプロクシ型とエージェント型に分類されます。この分類に従えばOpenSSOはエージェント型です。 しかし一般的なエージェント型から受ける印象とは少し違い エージェントに相当するモジュールがpolicy agentとして提供されているので(apacheのモジュールやtomcatのフィルタ)、対応済みのWebサーバやアプリケーションサーバであればSSO対象Webアプリにエージェントのコードを組み込む必要はありません (後述するように)policy agentをモジュールとして組み込んだapacheをリバースプロクシにすれば、リバースプロクシ型としてOpenSSOを動かせます 個人的に、この分類はそれほど重要だとは思っていません。より重要な分類は、SSO対象アプリ側のコードに「手を入れる必要があるか否か」の分類の方です。これは後述します。
はじめに 複数のWEBサービスをシングルサインオン(SSO)でというのは 最近は普通になってきてますね。googleしかり。facebookしかり。 この認証というのが実はとっても複雑なんですね。 知らない人が取り組もうとするとまず用語がわけわからんくてやめます。 さらに認証といってもいろいろな方式があって、さらに流行り廃りもあり 1年前の情報ページが古くて使えないなんてザラ。 完全に初心者キラーな無理ゲー状態です。 今回は認証?なにそれ?なエンジニアでも とっても苦労しながらなんとかSSO作れたぞ、という記録を公開したいと思います。 なお、2014年10月に試してますから! 上述したとおり、認証絡みはすっぐ情報古くなるんでそこんとこ踏まえて 読んでいただければと思います。 なお、認証関連のワードがどんどん出てきますがあまり説明しません。 なぜなら私もよくわかってないので。 やること We
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く