前回の記事では「認証基盤」「アイデンティティ管理」から、「IAMシステム」の成立に至るまでの流れを概観した。今回は、いまIAMシステムが迎えている変化を、いくつかの代表的なニーズを元に解説する。
クラウドサービス活用への対応
従業員のアカウント／アクセス管理は、エンタープライズにおけるIAM適用の基本形である。IAMを従業員の業務環境に導入することにより、企業は、日々の業務における利便性とセキュリティの両面を向上させることができる。このIAMが対象とするシステムは、従来は基本的には企業内にあった。しかし、各種クラウドサービスが一般的になるに従い、管理すべき範囲は企業外システムへも広がっている。
自社所有ではないクラウドサービスのアカウント／アクセスをIAMの傘下に収めるためには、企業内システムとは異なる点に注意が必要となる。まず、これらサービスは社外に存在するため、ドメインをまたがるシングル・サインオン（SSO）やアカウント改廃の同期は、社内ネットワークを越えて処理せざるを得ない。またクラウドサービスの実装・運用は、そのサービス事業者が主体であり、通常は事業者が個々のユーザー企業のIAMシステムの都合に合わせてカスタマイズすることはない。
これらの制約から、企業内のIAMとクラウドサービスとの連携には、ドメインがまたがってもSSOが実現可能な「アイデンティティ（ID）連携」機能や、HTTP経由でアカウント改廃のリクエストをやり取りするための「ユーザー・プロビジョニングのためのWeb API」（以下「プロビジョニングAPI」と表記）機能が使われるようになってきている（図1）。
ID連携では、クラウドサービスからの「認証依頼」を受けたIAMシステムがユーザー認証を行い、その「認証結果」をクラウドサービスに返却する。この「認証結果」に含まれるのは、クラウドサービスにおけるユーザー識別子であり、ユーザー認証に用いたアカウント名やパスワードはクラウドサービスに流れない。そのため、パスワードはもちろんのこと、例えば従業員が社内で使っているユーザーIDも、クラウドサービス側に流れることはない。IAMとクラウドサービスとの間のリクエスト／レスポンスが利用者のクライアント環境（例: Webブラウザー）を介して行われるため、社内外の通信が制限されている環境においても適用しやすい、という特徴もある。
クラウドサービス事業者が公開するプロビジョニングAPIでやり取りする方式も、REST（Representational State Transfer）スタイルやJSON形式といった、連携しやすいものであることが多く、企業側のIAMからの接続が比較的容易になっている。
現在では、Google Apps、Salesforce.com、Office 365、Amazon AWSなど、エンタープライズ向けの大手クラウドサービスのほとんどがID連携やプロビジョニングAPIに対応している。また国内でも、cybozu.com（サイボウズ）やクリプト便（NRIセキュアテクノロジーズ）、チャットワークなど、対応する事業者が増えつつある。