書いてってリクエストされたので、書きます

2020.07.29

神々からいろんなお知恵を授かったので一部修正しています

主な修正点はOIDCのグルーピングと権限周りについてです。こちらできないと書きましたが、OIDCのclaimとして存在しているのでSP側で対応していれば可能なようです。できるかどうかはSP(サービスの対応次第)

最初に言いたい

このnoteはSSOから始まり、SAMLとかIdPだとかOIDC・OAuthだとか最終的にはProvisioningまでと用語はたくさん出てきますが、技術的な部分はほぼ削ってます。そして、情シス目線でコンシューマーサービスを利用したい・制御したいという立場で書いてます。tCサービスではまた違う角度でみる必要があるので、気をつけてください。あくまでこれは情シス目線

Tech寄りの要素が知りたくなったら他で調べてみてください。このnoteは、認証認可っていろいろ種類があるみたいだけど、その中でなんで情シスが導入するべきなのはSAMLなの?IdP導入する理由って何?その先は何があるのか?です。

そして書いた私が勤務している会社では、まだIdP導入できてません、なので当然SAML無理、SSOできない。早く入れたい。じゃないと私が腐って死ぬ。

情シスの仕事はパスワードをリセットすることでもアカウントを作成することでもない

情報システム部門として働いてる人で、まずこの部門を志望した動機が人のアカウントを作成したいからとか、パスワードをリセットしたからとかでは大体ないと思うのですが、実際、情シスとしてまず配属された時、会社の全体象を知るためなどにヘルプデスク的な役割や、サービスのアカウント作成をまかされる人は多いと思います。

ですが、情シスの本来の業務はアカウント作成でもなく、パスワードをリセットすることではありません。

本来の情シスの仕事は社内のIT周りの推進を行うことです。いかに、自社に合わせた最適なIT構成を構築していくのか?今後スケールアップを目指しているのであればセキュリティの向上をしないといけないかもしれないし、エンプラレベルの会社であれば、オンプレ資産だって持っていていてもおかしくないので、それをいかにクラウドにスライドしていくのか?

そういう今のスタンダード、これからのスタンダードに合わせていくかを考えるのが、情シスの仕事になるんじゃないかなぁ、知らんけど。

なんで情シスはSSOできるようにするべきなのか、その中でもSAMLなのか

ちょっとTechな話と言うかそもそも論を書いていきます。そもそもSAMLとは何か?です

SMALの正式名称は、Security Assertion Markup Languageといいます。

SAMLはOASISによって策定されたXMLをベースにしたIdentity Management の標準規格であり、さむるって読みます。かわいいよね。

SSOの正式名称はSingle Sign-Onです。ここで気をつけた方がいいのは、SAMLでできる機能の一つにSSOがありますが、SSOはSAMLじゃないとできないかと言われるとそれも違って、あくまで、1つのIDとパスワードで複数のサービスにログインできることができる仕組みを言います。

なので、Windows認証やリバースプロキシ型など、SAML以外にもSSOができる認証はあるので、人と話していて前提が違うとお互いがクエスチョンマーク浮かべることになるので、SSOと言わずに、SAMLを使ったSSOの場合は、SAMLと言った方が早いと思います。SSOはえすえすおーって読みます。やっぱりかわいい。

では、最近サービスでよく見かける、GoogleでログインとかFacebookでログインっていうのは、何かというとOAuth 2.0というアクセストークンを取得するための認証規格です。統制部分などが行えるようになった拡張した規格がOIDCと呼ばれ、正式名称はOpenID Connectという名称になります。

SAMLとOIDCの大きな違いですが、SAMLの場合はユーザーマスタがあり尚且つ、認証基盤(IdPと呼びます)があり、認証基盤のXMLベースの証明書とSSOしたいサービス(SPと呼びます)の証明書を事前に管理者が設定し、認証基盤とサービスにユーザーがいることでSSOができます。

OIDCは、証明書はいらない代わりに、サービス側が各リソースサーバにTokenを発行し、そのTokenでユーザーデータを取得してSSOが可能となります。リソースサーバというのは、Googleだったり、Facebookだったり、「〇〇で認証する」の〇〇がリソースサーバにあたります。この時、サービス側にユーザーが存在しなくても、初回のログインでユーザーが作成されます。

SAMLとOIDCでは開発の容易さでは、OIDCの方が容易でありそもそも、企業などではない限り、ユーザーマスタや認証基盤なんぞ存在しないので、一般的にtCサービスでは、OIDCを利用しているのでよく見かけるのは、OIDCを利用した認証になります。

では、そんな中、なぜOICDではなくSAMLなのかって話に戻ります。

本題のなんで情シスはSSOできるようにするべきだし、その中でもSAMLなのか(2回目)

やっとこのnoteの本題です。

大体の会社がGoogle(G Suite)を利用してるし、「Googleでログイン」のOIDCでいいじゃんって思うかもしれません。

それ以外にも、多くのサービスはSSOが可能なプランはエンタープライズライセンスだったりと、いきなり最上プランになり、自分達が欲しい機能以上の機能が無駄について高い。私はただSSOしたいのに。みたいな、そんなこともあり、OIDCでいいと思うかもしれません。

ですが、OIDCのコンシューマー向けではない点は、会社という組織で必ずあるライフサイクルを回すのが困難・そしてグルーピング・権限管理がサービスに依存していること、コンシューマー向けのサービスがOIDCよりもSAMLに対応している場合が多いからです。

まず、前者のライフサイクルを回すのが困難なことについてです

例えば、「Googleでログイン」したユーザーは、一回ログインした時点でアクティブユーザーとしてサービス側に登録されます。その後、退職してG SuiteのアカウントやGoogleアカウント自体を削除したとしてもアクティブユーザーとしてサービス側に登録され続けます。情シスなど、サービスの管理者が退職した時点で管理者がサービス側にいるユーザーを削除しない限り一生アクティブユーザーとして残り続けます。

SAMLもSAMLのみであれば、同じことなのですが、SAMLを対応しているサービスの場合は、プロビジョニングとデプロビジョニングの機能を利用することで、解消することができます。こちらに関しては後述します。

なので、OIDCに関しては、管理者がメンテを行わない限り無尽蔵にユーザーが増え続けるということになります。なので、SAMLできるプランは高いからOIDCできるプランでいいやーみたいなプランの選び方をして、適切な処理を管理者が行わなかったら、結果としてSAMLが可能なプランが買えるくらいには金額が言ってしまう可能性もあります。棚卸し本当大切

次に、グルーピング・権限管理がサービス側の対応次第という点です

これは、IdPを導入することでできるが、OIDCではサービスによってできないという話になります。

OIDCでグループ制御を行う場合はAzureなど、グループ情報を持っているリソースサーバでサービスが対応している場合は、グループ制御が行えます。また、そうでないと場合、Facebookなど、グループ情報を持っていないリソースサーバで、サービス側がグループ制御が行える場合は、まず全てのユーザーは初回は平等な権限でのアクセス権でログインすることになります。その後、管理者が、権限を絞る・または管理者レベルまで変更するなどをします。

IdPの場合はまずマスタがありそこに大体のグループを入れる属性値があるので、そこにグループ情報が入っていて、サービス側でも対応してれば SSOしたタイミングでグループ情報が渡される状況になります。

このグループは、サービスの権限ごとにグループを作ることが可能になります。

また、職種によってグループを作るというアプローチも可能です。

エンジニアグループが使うサービスはこのサービス、営業グループが使うのはこのサービスなどとグルーピングすることが可能です。

そしてIdPを導入したすると、SAMLの設定をしたサービスをみるポータルサイトもIdPの一部として提供されます。これはそのSAMLの設定をしていても、グループや人単位で割り当てられたサービスのみを表示します。

なので、例えば営業として新しく入った人を営業グループに入れて、サービスにもユーザー作成をしてあげれば、その人に営業が利用するサービスについて情シスが案内することは、「そのポータル画面に表示されているサービスが営業が使うサービスです。実際の利用方法は営業グループの人に聞いてみてください」という案内になります。

また、IdPとサービスが限られますが、Provisioning機能を利用すればサービスに割り当てしてるグループにユーザーを追加してあげるだけで、サービスに自動的にユーザーが作成されるので、サービス側にユーザーを作成するという手間も省けます。

Provisioning機能は対応しているかはIdP毎、サービス毎に有無があります。アカウント作成まで行い、削除はできないもの、作成(Provisioning)から削除(Deprovisioning)まで行えるもの、これは全てサービス側次第になるので、どこまでどのような挙動で振る舞うのか、要確認すべき点です(ここら辺はSandBox環境等が作れるなら作って試すのが一番になります)

そして、Aサービスでは●IdPには対応しているが、×IdPには対応していないなどの場合もあるので、導入以前に事前に調査が必要です。

Provisioningは基本的に管理者が最も工数を少なくライフサイクルをうまく回す方法になるので、利用できるサービスは利用していきましょう。

コンシューマー向けのサービスがOIDCよりもSAMLに対応している場合が多い

これはこれ以上に書くことがあんまりないのですが、基本的にコンシューマー向けはSAML対応しているがOIDCは対応していないものが結構数あります。(当たり前ですが逆もあります)

サービスをよく使うのであれば、多い方に寄せてるのがユーザビリティを向上や、問い合わせの減少が見込めるのではないでしょうか？

またサービスによってはこのIdPでは、動作保証するが他はしない。なんてものもあるので、IdPの導入時に自社で利用してるサービス群がどの程度対応しているかや、ドキュメントの有無などを確認しておくのが良いかと思います。

SAMLの設定ははIdPやサービス毎に微妙に仕様や挙動が変わります。

何より管理者が事前に設定を行わないといけないが、その設定がナレッジとして少ない(IdPやサービスのドキュメントのみ)などで、一度設定でハマると解決するのが難しいなど、避けたくなることも確かです。

ですが、IdPの導入・SAML設定を行うことで、ヘルプデスクの問い合わせ現象やセキュリティの向上・適切なライフサイクルを維持することができるなど、メリットが多いので、私は早くIdP導入したい。

追加後の反省

これ書いていろんな方から教えてもらった事があったので、アウトプットしたら反応が返ってくる事、そしてちゃんと反映する大切さとアウトプットしたらまた学べる機会のボーナスタイムが来ることがわかったとのでちゃんとアウトパットしていこうと思いました。(ポジティブシンキングです

OAuth徹底入門 セキュアな認可システムを適用するための原則と実践

IT管理者のための情報セキュリティガイド (NextPublishing) Kindle版

脱オンプレミス! クラウド時代の認証基盤 Azure Active Directory 完全解説 マイクロソフト関連書

改訂新版クラウド環境におけるアイデンティティ管理ガイドライン Security Series (Security Series(NextPublishing))