はじめに
Hello, Qiita!
大変なことを始めてしまいました。ブログというものを書くこと自体が初めてなのですが、細々とやっていきたいと思います。
なんで今OpenAM？
一言で言うと、仕事で検証することになっただけです。その過程で得た知識を吐き出そうかなぁと思いました。
私は業界で言うところの情シスの人間なのですが、最近は会社のIT企画のお手伝いのような仕事をしています。その業務の中で、全社の共通ID基盤として「OpenAM使えそう！」と血迷ったことを自分が言い出したので、言い出しっぺがそのまま検証することになったというわけです(´；ω；｀)ﾌﾞﾜｯ
何を伝えたいのか？
OpenAM使ってID基盤作りたいとか、シングルサインオンしたいとか、多要素認証したいと考えている人は結構いるのじゃないかなぁ？と勝手に想像しています。そんな人達に「あ〜、なんだかわたしでもできそう〜(๑•̀ㅂ•́)و✧」って思ってもらえると嬉しいです。この業界で働きはじめて数年目ぐらいのわたしでも、「あ、なんだかできちゃいそう〜(゜∀。)」ぐらいには感じています。
会社ではどんな課題があって、OpenAMを使おうとしているのか？
ここは口外すると会社に怒られるのかなぁ？正直、よくわからないです。けれども、そこそこの規模の会社だと、こういう共通の課題はあると思いますので、共感を得るためにも、やんわりお話することにします。
- 会社のアプリ数がいっぱいあって死にそう
- 認証をまとめたい
- 認証の強度を統一したい
- 役職、職種、雇用形態に合わせたアクセス制御をしたい
- パスワード忘れ対応などの運用業務をなくしたい
- なんちゃってSSO、オレオレSSOを強い意志を以って駆逐したい（趣味）
- クラウドのアプリが勝手に増えた
- だからといって、セキュリティ強度を下げたくない
- 事業部ごとに増えるので、シャドウITになりがち
- 外から社内のアプリを（ちゃんと）使いたい
- それなりの認証をして、アプリを使わせたい
- 抜け道をなくす
- これからつくるアプリのために
- 内製することも多いので、ID全般の実装を共通化したい
- ネイティブアプリやシングルページアプリケーションも増えそう
- 共通コンポーネントって予算取りにくい
- 商用製品バーン！って導入するとか絶対予算取れない
- うちの会社だけかもしれませんが...
他にもありますが、大まかにはこのような感じです。こうやって箇条書きにすると、課題のヤバさが伝わりにくいですね。まぁいっか・・・。
OpenAMとは？
それでは1日目の本題に入ります。まず、wikipediaで聞いてみます。
OpenAMは、オープンソースのアクセス管理、エンタイトルメント、フェデレーション·サーバーのプラットフォームである。
2010年2月にForgeRockは、現在Oracleではプロジェクトでの開発中止が決定されたOpenSSOの開発とサポートを、Sunから継続することを発表。ForgeRockは、OracleがOpenSSOの製品名で権利を保持するため、製品名をOpenAMに変更した。
ForgeRockは、Sun Microsystemsのオリジナルのロードマップを提供し続けることを発表している。
オリジンはSun Microsystemsが開発していたOpenSSOで、OpenAMはそのForkみたいな感じですかね？Forgerockに開発が引き継がれた後も、継続してOSSとして公開されていますが、製品版みたいなのもあるみたいです。ライセンスはCDDLです。
余談ですが、わたしの同年代の人たちはSun Microsystemsって知らないらしいですね。わたしは学校の先生がSunの狂信者だったので、知っていました。おじさま連中からすると、ジェネレーションギャップを感じるようです。
わたしは、wikipediaじゃ分かりにくかったので、OpenAMを使ってシステムインテグレーションしてる企業さんのサイトとかを使って概要を理解しました。
本当はもっと色々できるんだけど、初めて触る人にわかりやすいようにシングルサインオンというキーワードを使って解説していますね。ちなみにシングルサインオンとは、
シングルサインオン（英語：Single Sign-On、略称：SSO）は、一度のユーザ認証処理によって独立した複数のソフトウェアシステム上のリソースが利用可能になる特性である。この特性によって、ユーザはシステムごとにユーザIDとパスワードの組を入力する必要がなくなる。
という定義です。UXの向上という特性が挙げられていますが、認証が一元化されることによる運用や監査の省力化や開発スピードの向上などの特性も挙げられるかと思いました。
OpenAMでできること
では、具体的に何ができるのかについて、まとめてみました。
- Authentication（認証）
- ユーザーやデバイス、アプリの認証ができる
- 認証機能を組み合わせて提供できる（Multi Factor Authentication）
- 認証をしにきたユーザーの送信元IPとかで、認証の切り替えができる（Adaptive Risk）
- Authorization（認可）
- だれが、どの情報リソースにアクセスできるかを制御できる
- Federation（フェデレーション）
- 認証したユーザーの属性を他所のアプリに連携できる
- 他所のアプリは連携してもらった属性を信頼して認証できたことにする（SSO）
- 連携した属性をエージェントやリバースプロキシでバイパスして、他所のアプリにSSOすることもできる
- Audit Logging（監査ログ）
- AuthenticationとかAuthorizationとかFederationのログがしっかり残せる
- Session Management（セッション管理）
- 払い出すトークンやセッション種別ごとに有効期限をきめれる
- 特定のユーザーに払い出したトークンやセッションを無効化できる
- High Availability
- 冗長構成できる
- ステートフルだけど、レプリケーションでがんばっている
太字のところは賛否両論ありそうだなぁと思いました。よく、シングルサインオンの方式として、
- エージェント型
- リバースプロキシ型
- フェデレーション型
という形で紹介されています。ただ、少し勉強した程度のわたしの所感ですが、
- フェデレーション
- SAML 1.1/2.0
- OpenID Connect 1.0
あたりが「シングルサインオンする」という目標を達成する、フェデレーションという唯一無二の手段であり、エージェント型とかリバースプロキシ型というのは**「なんでか知らないけど、フェデレーションできないすごく可哀想なレガシー（笑）なアプリ」を救済するための措置というかゴリ押し**でしか無いのかなぁ？と整理しています。なんだか、フェデレーションと並べて扱うのには理由があるのでしょうか？歴史的な背景（若しくは闇）があるのでしょうか？知っている人がいたら教えてください。
ひとり OpenAM Advent Calendar 2016 はじまります
仕事ではじめたOpenAMのお勉強ですが、やっていくうちにID基盤がちゃんとある企業って結構イケてるんじゃないか？と思えてきました。例えば、IT導入の身動きが取りやすくなったり、ユーザーによく使ってもらえるアプリを作れたり、監査の対応が省力化できるといった色々な効果が恩恵として受けられるのでは無いかと...甘いかなぁ？
ただ、本Advent Calendarは「○○やってみた」的な記事が並ぶと思いますが、読者にこの効果を少しでも感じてもらえるように記事を書ければと思います。
がんばるぞーヽ(｀д´；)ﾉ
おまけ
仕事柄、他社のエンジニアの方とお話することが多いのですが、OpenAMの話をするとたまに昔ひどい目にあった話を聞かされます。なんだかbuggyだったみたいですね。今もそうなんでしょうか。これも昔話知っている人がいたら教えてください。