クラウドサービスが数多あると、それぞれのサービスごとにユーザー名/パスワードといった認証を管理することは大変苦痛です。
これまでグラニでは、ADFS + AzureADを使ってIdentity Federationを構成していたのですが、先日ADFSを完全撤廃してAzureADを中心とするSSO環境に移行しました。
今回は、ADFSやIDaaS (ここで上げているAzureAD以外にもOneLogin、Okta、PingFederateなどを含める) によるSSOに関してです。
- なぜ SSO や ID連携を行うのか
- 前知識
- 以前の構成
- 冗長構成の担保
- 証明書の更新対応
- サービス/デーモンの管理
- DMZ の安全性担保
- RP 構成をそれぞれに合わせないといけない
- グラニの選択
- AzureAD で対応できないものの対処
- まとめ
なぜ SSO や ID連携を行うのか
そもそも、各クラウドサービスはそれぞれユーザー名/パスワードがあります。それでは困るのでしょうか？ 私はこれに関して、
「1つ、2つのサービスなら問題無いが、10、20と利用サービスが増えていくと困る。」
と、考えています。私が働いているグラニにおいても、当初はSSOを入れていませんでしたが利用サービスが拡大し来たため途中からSSOを導入しました。
パスワード管理は苦痛以外の何者でもない
- いろいろなサービスを使う
- それぞれのサービスでユーザー名/パスワードを求められる
このような時に良く言われるのが、それぞれのサービスでパスワードを変えなさいということです。しかし多くのサービスごとのパスワードを覚えたり、いちいちパスワードマネージャーに登録するのは簡単ですが大変なことです。*1
このパスワード管理という苦痛から逃れる手段はないのでしょうか？
SSO による認証の一本化
そこで用いられるのがSingle Sign On (SSO / シングルサインオン) やID連携です。SSO/ID連携に対応しているサービスであれば、自分のPCにログインやID連携元サービスにログインするだけで自動的にログインされます。ユーザー名だけ覚えておけば1回の認証が全サービスのログインに利用されるのです。
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, SAML, SAML, SAMLなど複数の認証方式があります。
どれがどう違うか理解していないと、「ID連携したいサービスは認証方式に対応していなかった！」ということになりかねないので注意です。
認証方式に関しては、以下のリンクが参考になります。
http://www.sakimura.org/2011/05/1087/
http://idmlab.eidentity.jp/2014/04/idoauth.html
企業においてSSOと呼ばれるのは、多くがSAML 2.0を採用しています。
CP, RP, IdP, SP
SAMLなどで用いられる用語に、CP (Claim Party), CP (Claim Party), CP (Claim Party), CP (Claim Party)があります。
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とか載せたくないので悩ましいですね。
https://rnd.feide.no/simplesaml/module.php/saml2debug/debug.php
デコードは単純なのでC# でやるのもいいのですが、追跡となると面倒でしょう。
http://stackoverflow.com/questions/6099467/how-to-parse-a-saml-assertion-request-in-net
http://stackoverflow.com/questions/15530184/working-with-saml-2-0-in-c-sharp-net-4-5
やはりFirefoxプラグインが私の中では一番です。
IDaaS について
AzureAD、OneLogin、Okta、PingFederateなど多くのサービスがあります。これらはIdPとして機能するので、接続したい外部サービスとSAMLやOpenID Connectでの連携をしてくれます。
IDaaSはいいぞ。
以前の構成
グラニではもともと、ADDSを中心として、 IdPにADFSとAzureAD を用いていました。
この構成は、スライドでいうところの 3. ハイブリッド（1） (クラウドAPL+ADFS) - ws-federation + 統合Windows認証 に該当します。
※ 実際にはMacがあるため、統合Windows認証で困るシーンがあるので 3. ハイブリッド（1） (クラウドAPL+ADFS) - ws-federation + フォーム認証) ですが...
IaaS(オンプレミス)環境では、ADFSやLDAPを使うことでIdPとできます。ADFSを使うことで、プラベートネットワーク(イントラネット)に配置したADDSへ外部サービスを直接繋がせることなく安全にID連携できるわけです。
また、ADFSは要求規則を触ったりできるのでID連携のカスタマイズがある程度自在です。*3
しかしADFSを持つことは良いことばかりではありません。
IdP を自前で持つデメリット
ADFSやLDAPといったインスタンス(サーバー)を持つということは多くの運用負荷がかかります。
冗長構成の担保
外部サービスとのID連携をするなら、イントラネットに配置したADFSを直接インターネットに晒さないため「DMZゾーンにADFSプロキシも必要」となります。当然インスタンスがいつ落ちてもいいように、ADFSもADFSプロキシ共に冗長構成を組む必要がでます。*4
冗長構成の維持はELBを用いて透過的に扱えますが、インスタンスを持ちたくないというのが本音です。
証明書の更新対応
ADFSには定期的に更新が必要な証明書は2つあります。トークン署名証明書 と サービス通信証明書 です。これらの証明書更新は、標準では自動化されていないため自動化を組む必要があります。めんどくさい。
- トークン証明書は自己証明書なので期間を長くとることも可能 *5
- サービス通信証明書は、認証局事業者によって発行された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連携) のためにのみ用意していました。
ADFS導入当時にもAzureADやOneLogin、Oktaを検討しましたが、AzureADは時期尚早と判断して採用していません。
- AzureADはIdP Initiateしかサポートしていない
- 他サービスはOffice365をサポートしていなかったり
と幾つかの問題でADFSを選ばざるを得ませんでした。
しかし、その後IDaaSの機能拡充もあり完全移行できる状況が整ったことから、ADFSからIDaaSへ移行することにしました。
AzureAD にした理由
IDaaSを幾つか検討をした結果 AzureAD Premium を選択しています。単純な連携ならPingFederateが最有力候補でしたが、AzureADにしたのは価格や融通に加えて幾つかの理由があります。
- 他IDaaSより開発が活発
- SAML認証も容易
- カスタムフォーム認証機能の強力な補助
- ユーザープロビジョニング機能も安価に利用可能
- オンプレADDSへのパスワードライトバックの提供*6
さすが、ADDSとの連動は強くこういう意図ではいい候補です。
現在はAzureADもSP Initiateにも対応したことに加えて、アプリケーション連携も増えておりクリティカルな問題は解消しています。
http://idmlab.eidentity.jp/2014/09/azure-adsamlidpsp-initiated.html
AzureAD 変化後の構成図
元からAzureADを使っていたこともあり移行はスムーズにダウンタイム0で完了できました。
移行後は、ADFS周りがすべて破棄されてシンプルになっています。
移行後はスライドでいうところの、4. ハイブリッド（2） (オンプレAPL+AAD/WAP) - ws-federation + 統合Windows認証) が近いでしょうか。実際のところ、ADDSが死んでいてもクラウドサービスとの接続はAzureADが完結します。AzureAD単独のユーザー管理も可能なので「クラウド型」にかなり近い印象です。
AADConnect の 実行スケジュール が AADSync から変更になったことに注意
ADDSとAzureADのディレクトリ同期はAADConnectで行っています。AADSyncからAADConnectへのアップグレードとADFSからADDSへの移動は何も問題ありません。おおよそDirSyncからのアップグレードと代わりないので、チュートリアル通りどうぞ。*7
ディレクトリ同期方法に注意してください。AADSyncではタスクスケジュールで同期がデフォルト3時間おきに実行されていました。これがAADConnectで、30分ごとにプロセスで実行されるように変更されました。*8このドキュメントがぱっと見つからないのでお気をつけて。
ADSyncモジュールにすべてのコマンドがあるので確認しておいた方がいいです。
IDaaS 移行の結果
ADFSにあったデメリットがすべて解消しました。これは、AzureADに限らずIDaaSで得られるメリットです。ID連携の仕組みとして非常に堅牢になりました。
- ADFSなどはすべて破棄しているので、冗長構成の担保
- トークン証明書やサービス通信証明書も担保が不要
- サービス/デーモン管理も不要
- DMZ安全性担保も不要
- RPの構成も単純化されてたとえ初めて見る人でも構成可能
他にもメリットがあります。
- カスタムフォーム認証により「SSOに対応していないサービスだけど、共通IDでアクセスしたい」というケースも対応されました。*9
- AzureAD連携する対象を、ユーザーだけでなくグループ指定も容易に。*10
もともとアプリケーション連携もAzureADは強力だったのでいいでしょう。GraphAPIで、認証プロバイダとしても活用できるのでAzureADはその意味でも便利です。
グラニのユースケースでは、特にデメリットは生じていません。
AzureAD で対応できないものの対処
なんでもできるほど万能ではありません。むしろ細かい融通効かないので、結構残念なポイントは多いです。
とりあえず、カスタムフォーム認証のパスワードフィルの失敗度合いが高すぎてアレですね。
CloudForce.com とのSSO
AzureADのSAMLは、対応アプリケーションでも決まったフォーマットである必要があります。どういうことかというと、SalesForceにおけるCloudForce.comドメインでは連携できません。
これに関しては、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は後一歩で現実味を帯びそうです。
