ID管理、認証基盤について思うところ
これまで製造業2社の情シスを10年以上やってきたのですが、アプリケーション側と認識が合わない（ID管理、認証基盤がすべてアカウント管理を行ってくれるという夢）ことがよくあったので、そのあたりを紐解きながら、ID管理、認証基盤の役割を説明します。
さらに、ID管理、ID管理システムというキーワードに含まれる要素を網羅しています。この領域は、提案ベンダーの注力するポイントによってカバー範囲が大きく異なるので、ベンダー提案を受ける際に意識してもらえればと思います。
1.ID視点で見た時のアプリケーションの要素
ID厨側からは、アプリケーションを次の要素に分解します。
・認証/認証用データ
IDとパスワードの入力を求めてくる部分です。多要素認証、二段階認証はこの部分に該当します。
・認可/認可用データ
アクセス許可を実施する部分です。このグループに所属している人は利用できる、このロールが割り当てられている人は利用できる、参照のみ、更新可能などなど、を制御する部分です。
・アプリケーションロジック/アプリケーションデータ
アプリケーションのメイン機能です。
2.認証基盤
・課題認識
それぞれのアプリケーションでIDとパスワードが別管理、覚えられない。
それぞれのアプリケーションでIDとパスワードを入力する必要があり手間。
・認証基盤/SSO（シングルサインオン）
（いろいろ割愛するが）IDとパスワードの管理を認証基盤で一元管理を行い、アプリケーションには認証済みのIDを提示します。これを実現するプロトコルにSAML/OpenID Connectがあります。（SSOを実現する別方法には、リバースプロキシタイプ、エージェントタイプなどがあります）
これから導入するシステムは、SAML/OpenID Connectが必須と言ってもいいと思います。
・アプリケーション側に訴えたいポイント
SAML/OpenID Connectに対応してください。
SAML/OpenID Connectに対応したからといって、アプリケーションのID管理（アカウント）が無くなる訳ではありません。
認証用データ（アカウント）は、アプリケーション側に引き続き必要です。無くなりません。（認証時にアカウント登録がない場合、自動的にアカウント作成を行うアプリケーションがあることはある。例：Salesforce、SAML 用のジャストインタイムプロビジョニング）
アプリケーションの目的によっては、アカウントはアプリケーションデータの一部とも考えられます。例えばスケジュールアプリの場合、他人のスケジュールを表示できたりします。この場合、あらかじめ他人のアカウントデータが登録されていないと実現できない機能だと思います。
3.ディレクトリ
・課題認識
アプリケーション毎にアカウント登録が必要。担当者が辛い。
アプリケーション側に意識があり、（鮮度はさておき）アカウント管理運用が実施されているだけまし。アカウント管理が実施されていない場合、めんどくさい事態になることもある。
・ディレクトリサービス
（これだけではないが）アカウントデータを一元管理するディレクトリサービスを構築して、アカウント管理を一元化します。
ディレクトリサービスのよくある実装例は、ActiveDirectory、OpenLDAP、ApacheDS（LDAPプロトコルを話せるやつ）となります。RDBというケースもあるかと思いますが、それはディレクトリとは呼ばないような。。。
アプリケーション側は、LDAPプロトコルを通して、都度問い合わせる or すべてを取り込む といったことを行って下さい。
・アプリケーション側に訴えたいポイント
とあるクラウドサービス（自称、国産）に対して、アカウント管理はどうするんですか？と質問したところ（フィクションだといいですね）
・ドメイン参加してもらえれば、ADのアカウントと連携できます。（クラウドサービスなのにドメイン参加とは・・・）
・初回はCSVで一括登録できます。通常運用では画面から1件ずつ登録してください。（つらい・・・）
・LDAPを利用する場合、SAMLは使えません（そんなのって・・・ヤダ）
ぜひLDAPプロトコルで連携できるようにして下さい。
4.ID管理/ID管理システム
・課題認識
そもそもアカウント登録作業ってめんどくさいよね。手間だよね。自動化したいよね。
・ID管理システム
ID管理システムには、大きく3つの要素があります。
IDライフサイクル管理
源泉情報（人事DB、派遣社員DBなど）と連携して、人事イベントをアカウントへ反映させます。
プロビジョニング
ID管理システム（だけではないが）から、アカウント関係のデータをアプリケーションへ配信する。この部分のプロトコルにSCIMがあります。SCIMに対応するアプリケーションはまだまだ稀で、独自APIというケースが多いです。独自APIでもあればいい方です。多くの場合で、魔法のCSVで連携することになります。
ID管理システム側としては、プロビジョニング先の追加はかなり大変です。（必要なデータが揃っているか、不足はどうやって収集するか、インターフェースの開発、、、など）なので、ディレクトリへのプロビジョニングは責任を持つので、アプリケーションはディレクトリを参照して下さい。となって欲しいです。
監査ログ、ワークフロー
社内システム利用のために会社ごとに決められた手続きをシステム化、自動化します。さらに内部統制のエビデンスとしての活用します。
ID管理システム側としては、必要性は理解しますが、プロビジョニングと同様にアプリケーションの追加に弱いです。ID管理システムのパッケージとして必要な機能というのはわかりますが、積極的には使いたくないです。別の全社共通ワークフローシステムのようなもので担保していただきたいです。
・アプリケーション側に訴えたいポイント
ID管理は大事ですが、ID管理システムにまとめる思想は勘弁してもらいたいです。アプリケーション展開や改善のスピードを維持するためには、アプリケーションごとでやっていただいたほうがいいと思います。
ID管理のための源泉情報、ディレクトリは提供しますので、うまく使ってやって下さい。
Appendix.IDaaS（Identity as a Service）
AzureAD（Microsoft）、Cloud Identity（Google）、Okta、、、などがあります。IDaaSがカバーする範囲、カバーできない範囲がそれぞれありますので注意して下さい。
例えば、IDaaSにAzureAD、アプリケーションにG Suiteを連携させた場合
・G SuiteのID管理は、AzureADを通して連携可能だが、AzureAD側のライフサイクル管理はどうするか？
・グループのプロビジョニングも可能だが、実運用に耐えられる機能があるか？
・G Suite側の認可データの管理をどうする？グルーピングのメンテナンスをどうするか？
まとめ
特にまとめらしいものはありませんが、ID管理の中で意識してもらいキーワードは、認証・認可、ディレクトリ、IDライフサイクル管理です。