社内で使用するウェブアプリケーションを開発する場合、アプリケーションを利用するユーザーの認証機能をどのように実装するだろうか。
おそらく多くの場合は、「ユーザー名」と「パスワード」をセットにした「資格情報」を登録した専用のデータベース（ここでは資格情報が入ったデータベースを「IDストア」と呼ぶことにする）を用意し、ウェブフォーム画面で入力した資格情報と照合する方法を採用しているのではないだろうか。
確かにこれは昔からよく行われている方法であり、ある意味「枯れた運用方法」である。そのため、コストを抑えてユーザー認証機能を実装する場合には、いまでもよく採用される方法になる。
ウェブアプリケーション専用のIDストアを配置した様子
しかし、この方法は利用者にとって、まったくありがたくない仕組みでもある。なぜなら、ウェブアプリケーションにアクセスするための“専用の”ユーザー名とパスワードを覚えなければならないからだ。
Windows Serverを中心としたシステム管理を行っている環境であれば、間違いなくActive Directoryを使ってWindowsログオンの管理をしているはずだ。ところが、データベースに業務アプリケーションのための専用のIDを別に用意すると、ユーザーはActive Directoryと業務アプリケーション、2つのユーザー名とパスワードを覚えなければならなくなる。
2つぐらいは覚えておけるとは思うが、このように一元化されていないIDストアが時間の経過とともに3つ、4つと増え、結果IDストアの乱立を招き、ユーザー自身がID情報（ユーザー名／パスワード）を覚えきれなくなるという事態に発展するのである。
このような現象はインターネットの世界で私たちはすでに経験済みであり、同じことを社内システムでも繰り返してはならないと筆者は考えている。例えば、Microsoftアカウント、Apple ID、Googleアカウントなど、私たちの身の回りには驚くほどID情報があふれており、事実上インターネット上のID管理は破たんしている！
クラウドを活用すればIDストアの数は加速度的に増加
最近はクラウドコンピューティングの台頭により、社内システムとは別にクラウドのサービスを利用する機会も増えてきている。そして、クラウドサービスを活用すれば、必ずと言ってよいほど、そのクラウドサービス専用のIDストアを使うことになる。
コンシューマー向けのクラウドサービスであれば、FacebookのIDを利用してログオンを一元化する方法も一部で採用されているが、エンタープライズ向けには専用のIDストアが用意されていることが多い。そのため、企業が複数のクラウドサービスを利用するとなれば、その時点でさらに多くのIDストアを使わなければならなくなるのだ。
適切なID環境を実現するための3つのステップ
乱立するID環境に対して、すべてのIDストアを1つに集約し、一元管理ができればベストである。しかし、世の中にこれだけのIDストアが存在し、それぞれがイニシアチブを握ろうとする中で、1つのIDストアでクラウド／オンプレミスを問わず、すべてのITリソースのアクセス管理ができるようにすることはなかなか難しい。ここでは政治的な要因を挙げたが、ほかにも技術的な要因など、IDストアを一元化できない要因はさまざまだ。これについては別の機会に紹介したい。
そこで、複数のIDストア間で連携できるようにシステムを構成し、ユーザー自身は一度のログオン操作であらゆるITリソースにアクセスできるような環境を構築する方法を模索するべきだろう。
ということで、ここでは乱立するID環境をシェイプアップし、スリムなID環境に再構築するための3つのステップを紹介する。
ステップ1：余計なIDストアを作成しない
本稿の前半部分で例として挙げたような、ウェブアプリケーションによる特定のサービスのための専用IDストアを作るというのをまずはやめるべきである。すでに特定のサービス専用のIDストアがあるなら、別のIDストアと統合できないかどうかを検討してほしい。
例えば、WindowsのウェブサーバであるIIS（Internet Information Service）を利用しているのであれば、Active Directoryのユーザーアカウントをベースにしてアクセス管理を行うことができる。
ステップ2：既存ID環境の整理
社内にあるActive DirectoryですべてのID管理ができればベストだが、現実にはそうはいかない。そこでステップ2では、どうしても捨てられないIDストアがあるなら、そのIDストアに保存されているIDの必要性を確認しよう。この後、ステップ3で複数のIDストア間の連携を行うが、それぞれのIDの関係性を説明できないようなものがあれば、事前に整理しておこう。
不要なIDストアを削除したら、次に行うのは不要なIDの削除
ステップ3：ID連携機能の導入
それぞれのIDストア間でのID連携機能を実装する。ID連携機能を利用するときには、自分がログオンしたときの情報を利用し、ほかのIDストアが管理するITリソースへアクセスするため、例えば「わたしはActive Directoryに○○というユーザーとしてログオンした」という情報を、だれが見ても明らかなかたちで取得しなければならない。
これを実現するために、ID連携の世界では一般に「トークン」と呼ばれる、汎用的な情報を利用して「わたしは○○です」という情報の受け渡しを行っている（Active Directoryにログオンすると「トークン」を取得できるが、Active Directoryのトークンはドメインに参加しているサーバでしか利用できないので、Active Directoryのトークンとは別に汎用的に利用可能なトークンをID連携のために発行する）。
この汎用的なITシステムで利用できるトークンを発行するのが「Security Token Service（STS）」と呼ばれるサービスになる。
STSを利用して汎用的に利用可能なトークンを発行する
また、STSはトークンを発行するサービスのほか、ユーザーから提示されたトークンを受け取って内容を確認する役割も同時に備えている。
STSはトークンを発行する役割と、提示されたトークンの内容を確認する役割を備えている
STSはさまざまなベンダーから提供されているが、ここではWindows Serverの標準機能として提供されるSTSである「Active Directoryフェデレーションサービス（ADFS）」を例に解説する。
ADFSはActive Directoryでログオンしたユーザーの情報を基に汎用的なトークンを発行するSTSとしての役割を備えており、発行されたトークンは別のSTSに渡すことにより、別のIDストアのユーザーとして関連付けされ、ITリソースへのアクセスが許可される。
ADFSを利用したID連携。この図ではActive Directoryと資格情報DBが関連付けされている
これにより、IDストアが複数あっても、ユーザー自身はActive Directoryに一度ログオンするだけで、何度もログオン操作を行うことなく、さまざまなITリソースにアクセスできるようになる。
ここまで、3つのステップでID連携を実現する方法を見てきたが、ステップ1、ステップ2の段階でのID環境のスリム化については、企業内のリソースはできるだけActive Directoryを利用して、1つのIDストアでアクセス管理を行うように集約しておくことが望ましい。クラウドを活用するようになれば、ほとんどと言っていいほど別々のIDストアを使わざるを得ないからである。
そして、ステップ3でのID連携機能についてはADFSを使った方法を紹介したが、STS間の連携を行うにあたり、肝となるのはプロトコルの互換性である。ADFSの場合、WS-FederationまたはSAMLというプロトコルを採用しているが、ほかのSTSと組み合わせて利用するとき、これらのプロトコルが利用できるか、またはほかのプロトコルを利用するべきかなどについてチェックしながら、利用するSTSを決定するといいだろう。
