クラウドサービスが数多あると、それぞれのサービスごとにユーザー名/パスワードといった認証を管理することは大変苦痛です。
これまでグラニでは、ADFS + AzureAD を使って Identity Federation を構成していたのですが、先日 ADFS を完全撤廃して AzureAD を中心とする SSO 環境に移行しました。
今回は、ADFS や IDaaS (ここで上げているAzureAD 以外にも OneLogin、Okta、PingFederate などを含める) によるSSO に関してです。
目次
なぜ SSO や ID連携を行うのか
そもそも、各クラウドサービスはそれぞれユーザー名/パスワードがあります。それでは困るのでしょうか？私はこれに関して、
「1つ、2つのサービスなら問題無いが、10、20と利用サービスが増えていくと困る。」
と、考えています。私が働いているグラニにおいても、当初は SSO を入れていませんでしたが利用サービスが拡大し来たため途中からSSOを導入しました。
パスワード管理は苦痛以外の何者でもない
- いろいろなサービスを使う
- それぞれのサービスでユーザー名/パスワードを求められる
このような時に良く言われるのが、それぞれのサービスでパスワードを変えなさい ということです。それはいいと思いますし同意です。しかし多くのサービスごとのパスワードを覚えたり、いちいちパスワードマネージャーに登録するのは簡単ですが大変なことです。*1
このパスワード管理という苦痛から逃れる手段はないのでしょうか？
SSO による認証の一本化
そこで用いられるのが Single Sign On (SSO / シングルサインオン) や ID連携です。SSO/ID連携 に対応しているサービスであれば、自分のPC にログインや ID連携元サービスにログインするだけで自動的にログインされます。ユーザー名だけ覚えておけば一回の認証が全サービスのログインに利用されるのです。
SSOに関しては、いい記事も多くあります。
しかも、Windows 10 なら Windows Hello でカメラ認証、デバイスの指紋認証でパスワードすら隠せたら？最高ですね。
まとめると、次の2つが、SSO や ID連携 を行う理由です。
- SSO や ID連携によるパスワード管理からの解放
- よりセキュアな環境を透過的に提供する
SSO 対応はサービス利用指針の一つになりうる
SSO がきっちり出来ているサービスなら、各サービスでログインする必要する必要すらなく透過的にログインされます。適切な人がアクセスしてきたら、認証をバイパスできる。これが SSO のスバラしいところです。一度SSO や ID連携できているサービスを体感すると、ユーザー名/パスワードしか対応していないサービスは非常に残念に感じます。
グラニにおいてもSSO はかなり重視しており、利用しているサービスでSSO に対応していない場合はリクエストしています。
以下の記事は少し過激な表現のタイトルですが、個人的には大筋ずれずに同意です。
世の中の多くのサービスは 「SSO を有償の中でも最上位に近いプランでのみ提供」していますが、標準的に提供しているサービスは好感度が天井知らずですね。
前知識
本記事は幾つか用語に関して理解している前提で書いています。前提知識となる情報をここでまとめておきます。
IdM実験室は神サイトです。ADFSやAzureAD使ってないとしても追っておくと幸せになれます。海外含めてここ以上に素晴らしいIdP の連携に関するサイトはそうそうありません。すごいです。
認証方式
SSO や Identity Federation (ID連携) などと一言にいっても、SAML, OpenID 2.0, OpenID Connect, JWT など複数の認証方式があります。
どれがどう違うか理解していないと、「ID連携したいサービスは認証方式に対応していなかった！」ということになりかねないので注意です。
認証方式に関しては、以下のリンクが参考になります。
www.slideshare.net
www.slideshare.net
企業において SSO と呼ばれるのは、多くが SAML2.0 を認証方式としているように思います。
CP, RP, IdP, SP
SAML などで用いられる用語に、CP (Claim Party), RP (Relying Party), IdP (Identity Provider), SP (Service Provider) があります。
ADFS ではそれぞれが何か理解しておく方が捗ります。
一方で、AzureAD や OneLogin を中心とした場合はざっくり IdP と SP が何か理解しておけば構築や挙動の理解には概ね問題ないでしょう。*2
IdP や SP の通信の流れは認証方式によって異なります。SSO に関わる ID連携で一番多いのは SAML なので、次のリンクがわかりやすく素敵です。
SAML通信のデバッグ
特に SAML においては、SAML Request / SAML Response の通信がどう流れるかは大事です。SAML は HTTP ヘッダにリクエストやレスポンスが埋め込まれます。しかし「その内容は人間が読むにはデコードが必要」、「HTTP通信がPOSTやRidirectで連続するため連続的に追うのは困難」です。
私が知っている中では、SAML tracer というFirefox Add-on が神で最強です。SAML通信も追跡してくれるので検証時に役立つでしょう。
他に、SAMLリクエスト、レスポンスをデコードしてくれる Webサービスもありますが、あまりSAML Response とか載せたくないので悩ましいですね。
デコードは単純なのでC# でやるのもいいのですが、追跡となると面倒でしょう。
やはりFirefox プラグインが私の中では一番です。
IDaaS について
AzureAD、OneLogin、Okta、PingFederate など多くのサービスがあります。これらはIdPとして機能するので、接続したい外部サービスと SAML や OpenID Connect での連携をしてくれます。
IDaaS はいいぞ。
以前の構成
グラニではもともと、ADDS を中心として、 IdPにADFSとAzureAD を用いていました。
この構成は、スライドでいうところの 3. ハイブリッド① (クラウドAPL+ADFS) - ws-federation + 統合Windows認証) に該当します。*3
www.slideshare.net
IaaS(オンプレミス)環境では、ADFS や LDAP を使うことで IdP とすることができます。ADFS を使うことで、プラベートネットワーク(イントラネット)に配置した ADDS に外部サービスに直接繋がせることなく安全に ID連携できるわけです。
また、ADFSは要求規則を触ったりできるのでID連携のカスタマイズがある程度自在です。*4
しかしADFS を持つことは良いことばかりではありません。
IdP を自前で持つデメリット
ADFS や LDAP といったインスタンス(サーバー)を持つということは多くの運用負荷がかかります。
冗長構成の担保
外部サービスとのID連携をするなら、イントラネットに配置したADFSを直接インターネットに晒さないために「DMZゾーンに ADFSプロキシ も必要」となります。当然インスタンスがいつ落ちてもいいように、ADFS も ADFSプロキシ共に冗長構成を組む必要がでます。*5
冗長構成の維持はELB を用いて透過的に扱えますが、インスタンスを持ちたくないというのが本音です。
証明書更新対応
ADFS には定期的に更新が必要な証明書が2つあります。トークン署名証明書 と サービス通信証明書 です。これらの証明書更新は、標準では自動化されていないため自動化を組む必要があります。めんどくさい。
- トークン証明書は自己証明書なので期間を長くとることも可能です。*6
- サービス通信証明書は、認証局事業者によって発行されたSSL証明書を利用する必要があるため期間をそこまで長く取れません。
サービス/デーモンの管理
ADFS には、ADFSSrvサービスがあります。
サービスが落ちるとIdP として処理ができなくなります。Chef や PowerShell DSC を使って、サービスの起動を担保するべきでしょう。
またADFS は「特定の変更処理をする際にサービス再起動を求められる」ことがあります。いうまでもなく、ADFS は何かしらの理由でリクエスト処理を正常に行えなくなることもあります。そういった場合にもサービスを再起動しないといけません。
サービスの担保、めんどくさい。
DMZ の安全性担保
AWS 使えば楽勝です。が、ADFS Proxy に脆弱性があったら？と考えると、安全性は サービス提供された IDaaS とは雲泥の差があります。正直かなりアレです。
RP 構成をそれぞれに合わせないといけない
ADFS では、各サービスによってRP構成を変えないといけません。例えば Sales Force、例えば Google Apps それぞれが、全く違う構成です。これは「ただID連携をしたいだけなのに本質じゃない設定で少なからず悩まされる」ことを意味します。
RP設定で悩んだことがない人はいないかと思います。こういう無駄な悩みは属人性を生むのでなくしたい要素です。そのために Meta.xml などがあるのですがそれを提供しているサービスは稀です。
グラニの選択
説明した通り、グラニでは ADFS と AzureAD を外部サービスとの連携に使っていました。元よりAADSync を使って ADDS とディレクトリ同期もしていたため、イントラネットのアプリケーション認証は元から AzureAD です。つまり、ADFS は SSO(ID連携) のためにのみ用意していました。
なぜ AzureADを選ばなかったのかと思われると思います。ADFS 導入当時にもAzureAD や OneLogin、Okta を検討しましたが、
- AzureAD はIdP Initiate しかサポートしていない
- 他サービスはOffice365をサポートしていなかったり
と 幾つかの問題でADFS を選ばざるを得ませんでした。
しかし、その後IDaaS の機能拡充もあり完全移行できる状況が整ったことから、ADFS から IDaaS へ移行することにしました。
AzureAD にした理由
IDaaS を幾つか検討をした結果 AzureAD Premium を選択しています。単純な連携ならPingFederate が最有力候補でしたが、AzureADにしたのは価格や融通に加えて幾つかの理由があります。
- 他IDaaS より開発が活発
- SAML認証も容易
- カスタムフォーム認証機能の強力な補助
- ユーザープロビジョニング機能も安価に利用可能
- オンプレADDS へのパスワードライトバックの提供*7
さすが、ADDS との連動は強くこういう意図ではいい候補かと思います。
現在は AzureAD も SP Initiate にも対応したことに加えて、アプリケーション連携も増えておりクリティカルな問題は解消しています。
AzureAD 変化後の構成図
元から AzureAD を使っていたこともあり移行はスムーズにダウンタイム 0 で完了できました。
移行後は、ADFS 周りがすべて破棄されてシンプルになっています。
移行後はスライドでいうところの、4. ハイブリッド② (オンプレAPL+AAD/WAP) - ws-federation + 統合Windows認証) が近いでしょうか。実際のところ、ADDSが死んでいてもクラウドサービスとの接続はAzureAD が完結します。AzureAD単独のユーザー管理も可能なので「クラウド型」にかなり近い印象です。
AADConnect の 実行スケジュール が AADSync から変更になったことに注意
ADDS と AzureAD のディレクトリ同期は AADConnect で行っています。AADSync から AADConnect へのアップグレードと ADFS から ADDS への移動は何も問題ありません。おおよそ DirSync からのアップグレードと代わりないので、チュートリアル通りどうぞ。*8
一つだけ気をつける必要があるのが、ディレクトリ同期方法です。AADSync ではタスクスケジュールで同期がデフォルト3時間おきに実行されていました。これが AADConnectで、30分ごとにプロセスで実行されるように変更されました。*9このドキュメントがぱっと見つからないのでお気をつけて。
ADSync モジュールにすべてのコマンドがあるので確認しておいた方がいいです。
IDaaS 移行の結果
ADFS にあったデメリットがすべて解消しました。これは、AzureAD に限らず IDaaS にすることで得られるメリットです。
- ADFS などはすべて破棄しているので、冗長構成の担保は不要です。ID連携の仕組みとして非常に堅牢になりました。
- トークン証明書やサービス通信証明書も担保が不要になりました。
- サービス/デーモン管理も不要です。
- DMZ 安全性担保も不要になりました。
- RP の構成も単純化されてたとえ初めて見る人でも構成可能になりました
他にもメリットがあります。
- カスタムフォーム認証により「SSOに対応していないサービスだけど、共通IDでアクセスしたい」というケースも対応されました。*10
- AzureAD 連携する対象を、ユーザーだけでなくグループ指定も容易に。*11
もともとアプリケーション連携も AzureAD は強力だったのでいいでしょう。GraphAPI で、認証プロバイダとしても活用できるのでAzureAD はその意味でも便利です。
グラニのユースケースでは、特にデメリットは生じていません。
AzureAD で対応できないものの対処
なんでもできるほど万能ではありません。むしろ細かい融通効かないので、結構残念なポイントは多いです。
とりあえず、カスタムフォーム認証のパスワードフィルの失敗度合いが高すぎてアレですね。
CloudForce.com とのSSO
AzureAD の SAML は、対応アプリケーションでも決まったフォーマットである必要があります。どういうことかというと、SalesForce における CloudForce.com ドメインでは連携できません。
Allow salesforce galary app to support cloudforce url – Customer Feedback for Microsoft Azure
これに関しては、Google Apps を IdP とすることで連携しています。
Google Apps は、AzureAD とSSO しているためユーザーが行うべき認証はUI/UX共に変わりません。違和感皆無で利用できるの最高ですね。
Google Apps との日本語名ユーザーがいる場合のSSO
日本語名のユーザーがどうしてもSSO できないので悩んでいたら、ちょうどブログが更新されて救われました。
プロビジョニングは、以前無効になる問題にあい初期化ができない状況を確認したため利用していません。GADS や GAPS での連携を現状は行っています。
まとめ
「AzureAD 最高」とはいいませんが、良いサービスです。もし ADFS を外部サービスとの連携でしか使っていない場合は、AzureAD Premium に限らず各種 IDaaS へ移行を推奨します。
私の一番の推奨は PingFederate ですが、AzureAD もいい候補でしょう。
今後は、Managed Directory Service にしたいですね。GPOやDNS 周りがあるので、なんともバッチリなサービスがまだ見つかっていないのですが、Azure Active Directory Domain Service は後一歩で現実味を帯びそうです。
*1:つまり面倒
*2:全部理解しておけばより挙動が理解できます
*3:実際には Macがあるため、統合Windows認証で困るシーンがあるので 3. ハイブリッド① (クラウドAPL+ADFS) - ws-federation + フォーム認証) となります
*4:この時代になっても要求規則を書かせる仕組みはサイテーだと思いますが！
*5:この時点で冗長構成なら最低4台
*6:いいか悪いかは別として
*7:これは完全にリモートワークであっても同様の認証制御が可能ということを意味します
*8:むしろ私はアップグレードしてからみました
*9:任意の間隔に変更可能 : 最短30分
*10:すべてではない。むしろ結構AzureAD のカスタムフォームは動かない
*11:AzureAD Premium の機能です。ADFS と違って要求規則さわらなくていいので楽です。ただしグループのネストは非対応なので注意