[Azure AD]Google AppsとのSSO設定でのポイント

こんにちは、富士榮です。

これまでも本ブログや各種記事で何度も紹介してきたAzure Active Directory（Azure AD）とクラウド・アプリケーションとのシングルサインオンですが、その中でもGoogle Appsが非常に手軽かつ利用シーンも多いので、何度も設定例として取り上げてきました。

しかし、実はAzure ADとGoogle Appsのシングルサインオンを行う際、2点はまりポイントがあります。

簡単に解説します。

◆サインオン時にGoogle Apps側で「ログイン資格情報を確認できない」と言われる

これはダブルバイト圏ならでは悩みと言えますが、原因は「Azure AD上のユーザ名に日本語（ダブルバイト文字）が含まれている」ことです。
Azure ADはSAML AssertionのAttribute Statementに必ず氏名の情報を含めてしまうため、ダブルバイト文字がAssertionに含まれてしまい、Google Appsが解釈できずにエラーとなる、という具合です。

一見なぜエラーになっているのかよくわからないため、タチが悪いと言えます。
Azure ADでログオンした後、Google Appsへリダイレクトされた際、以下のエラーが表示されます。

SAML Assertionの中身をトレースするとダブルバイト文字が入っていることがわかります。（SAML Tracerで見ると文字化けしてます）

対策としては、Google AppsはNameIdentifierさえあればシングルサインオンできるので、不要なAttribute Statementを消してしまえばOK、と思いきやAzure ADのSAML Assertionの編集画面で不要な属性を消しても、以下の属性が必ずAssertionに含まれてしまいます。
・tenantid
・objectidentifier
・identityprovider
・givenname
・surname
・name
・displayname

仕方がないので、日本語が入る可能性がある、givenname、surname、name、displayname属性にダミーの文字列を固定で入れてしまいます。

尚、displaynameについては初期状態の属性一覧には出ていないにも関わらず、Assertionの中を見ると値が飛んでいるので、属性定義を追加してから他の属性と同じくダミーの値を入れます。
ちなみに属性名は「http://schemas.microsoft.com/identity/claims/displayname」です。

必要な属性について編集を行い、保存します。以下が編集後の属性マッピング設定です。

これで実際のAssertionを見ると、ダミーのシングルバイト文字列がAssertionに含まれるようになり、エラーが出ることは無くなりました。

◆ログアウトするとエラーになる

シングルサインオンは良いのですが、Google AppsからログアウトするとAzure ADのサインアウト画面でエラーが出る、というケースがあります。

こんな画面が出ます。正しいSAMLプロトコル・メッセージではないというエラーが出ています。

これは、Azure ADがSAML2.0のシングルログアウトに対応していないにも関わらず、Azure ADがGoogle AppsのログアウトURLにSAMLのエンドポイントを設定していたことが原因です。（ws-federationのサインアウト設定を行う必要があります）
ちなみに、現在はこの問題は解決されているので、新規にシングルサインオン設定を行うとちゃんとws-federationのエンドポイントが設定されます。

以前の設定（エラーが出る）：https://login.windows.net/｛テナントID｝/saml2
現在の設定（エラーは出ない）：https://login.windows.net/common/wsfederation?wa=wsignout1.0

現在は、以下のようにちゃんとサインアウトできます。

このようにアプリケーションとのシングルサインオン設定はたまに更新されるので、定期的に設定を見直しておいた方が良いかもしれません。

ちなみに余談ですが、同一テナント上に複数のドメインが設定されており、かつフェデレーション・ドメインが含まれるケースにおいてはシングルログアウトの際に、全IdPのセッションをクリアしに行きます。
そのため、サインアウト時にIdPが落ちていたりして疎通できないと、うまくセッションがクリアできませんので、注意が必要です。（そのドメイン上のユーザかどうかに関係なく必ずセッション・クリアに行ってしまいます）

こんな感じで、落ちているIdPへもアクセスしようとしてエラーが出ます。

このように、Azure ADを使うと、かなり簡単にクラウド・アプリケーションとのシングルサインオン設定を行うことが可能ですが、トラブル時に対応するためにはID連携プロトコルの中身について少し知っておくと非常に有用です。

[告知]Active Directory & Security Conference 2016

こんにちは、富士榮です。

なんだか毎月イベントやってますね。先日のJapan Community Camp by MVPに続き、3月は「Active Directory & Security Conference 2016」（通称AD16周年）に登壇予定です。

日時：2016年3月18日（金）12:50～20:00
場所：日本マイクロソフト品川本社セミナルームA～D
イベント申込URL：
　http://events.msfthcp.com/?CR_CC=200764089&eventID=JA-EMS-IPVNT-FY16-03Mar-18-Active-Directory-Security-Coference%20&ls=Website&lsd=AzureWebsite
※結構埋まってきているみたいなので、お早めに。

私は、Deep DiveトラックでAzure Active DirectoryとアプリケーションのID連携について解説する予定です。Deep Diveということで、普段は抑え目にお話ししているフェデレーションの深いところを心置きなくしゃべれるようなので個人的に楽しみにしています。

こんなセッションにする予定です。

タイトル（仮）：Azure ADと外部アプリのID連携/SSO Deep Dive
内容（仮）：Azure ADの最大の特徴である、GoogleやSFDCなどの外部アプリケーションとのID連携/シングルサインオン機能について、具体的な連携方法やトラブルシューティング時に必須となるSAML/OpenID Connectなどのプロトコルの解説、実際の連携時の通信のトレース方法についてデモを交えて解説します。

もちろん、他にもとても楽しみなセッションがたくさん予定されていますし、一部（英語）というセッションがあるあたり、ゲストにも期待大です。

ぜひ、お申込みください。


あ、そういえばJapan Community Campの資料は以下にアップしていますので、よろしければどうぞ。

Azure ADとWindows 10によるドメイン環境の拡張 from Naohiro Fujie

[Windows 10]PIN対パスワード、そしてWindows Passport

こんにちは、富士榮です。

昨年夏のリリース時から「パスワードは時代遅れです」というメッセージで世の中を混乱の渦に巻き込んできたWindows 10ですが、半年が経過した今でも「やっぱり意味がよくわからない」という声をしばしば耳にします。
※ちなみにTH2のビルドだと「PINのセットアップ」というメッセージになっています。

これまでも各所の記事やセミナなどでは簡単に話をしたことはあるのですが、ちょうど前回から書き始めているWindows 10のドメイン参加やサインインの仕組みの大前提になる話でもあり、良い機会でもあるので簡単にまとめておきたいと思います。
（ちなみに多分に私見が入っています）


◆何が議論されているのか？
まず、これまで起きている議論はどういうものなのか、簡単にまとめておきます。

Windows 10をセットアップすると「PINはパスワードを使用するよりも早くて安全です」というメッセージ表示されます。また、短いPINが長いパスワードより安全な理由として「PINはこのデバイスでしか動作しないからです」と説明されています。

これを見て、
「数字4桁のPINの方がなんでパスワードより安全なの？」
とか、
「Windows 10ではPINに数字以外が使えるようになったし桁数も増やせるから！！」
とか、
「Windows Helloで生体認証と組み合わせられるから安全なんだ！」
とか、
「PINは端末とセットだからパスワードより安全なんだ！」
など、色々な疑問や意見がやり取りされて来ました。


それぞれの疑問や意見を見ると、もっともらしいものもありますが、いまいち何の話をしているのかがよくわからない、というのが正直な感想です。


◆なぜモヤモヤするのか？
まず、これらの議論を考えるうえで圧倒的に欠けているのは、「安全かどうか？」という話の大前提は「相対論」である、という点だと思います。
つまり、疑問が発生するのは「何と何を」、「どうやって」比べて相対的に「安全」なのか？という前提が抜け落ちているからではないでしょうか？

例えば、桁数や複雑性を比較軸としてPINとパスワードを比べると、パスワードの方が安全、という結果になることが多いと思いますし、有効範囲（端末をまたいで使えるか）の広さを考えるとPINの方が安全（でも結局同じPINを使いまわすんじゃない？？？）みたいな話です。

このあたりがごっちゃになってしまっているので、ある一部分を切り取るとPINの方が安全に見えるし、違う見方をするとそうでもない、という話になり混乱を招いているといったところでしょう。


◆整理してみる
では、軸を整理してきちんと比較すればPINとパスワードのどちらが安全なのかが見えてくるんでしょうか？

まずリスクとなりうるポイントを洗ってみます。

＃	ケース	PIN	パスワード	コメント
①	のぞき見される	×	○	通常、複雑性はパスワードの方が有利
②	通信経路で盗まれる	○	×	PIN自体は通信経路を流れないのでPINの方が有利
③	フィッシングサイトに入力する	○	×	PINでサイトへログインすることは無いのでPINの方が有利
④	サービスのDBから漏えいする	○	×	PINでサイトへログインすることは無いのでPINの方が有利
⑤	リストを使ってサインインを試行	○	×	PINは端末とセットなので、漏れたPINで別端末へログインはできない
⑥	リスト攻撃される	○	×	PINでサイトへログインすることは無いのでPINの方が有利

いかがでしたか？
結論は出ましたか？


一見PINが安全に見えますが、やっぱりモヤモヤは止まりません。


◆ではマイクロソフトは何が言いたかったのか？
結論から言いますと、そもそも単純にPINとパスワードを比べてしまっている段階で間違えているんだと思います。
マイクロソフトが言いたかったのは、Windows 10で新たに採用された「Microsoft Passport」を使ったサインインは従来のIDとパスワードを使ったサインインに比べて安全である、ということを言いたかったんだと思います。

ただ、その安全性を正しく理解するには、ベースとなっているFIDOの考え方やデジタル署名やTPMなどの用語を説明し理解してもらう必要性がある中、メッセージを単純化しようとして「やりすぎた」んではないか？と私は思います。


Microsoft Passportを使ったサインインの本質は、端末内（TPM）に保存された秘密鍵を使ってデジタル署名をしたサインイン要求を、認証サーバ側にあらかじめ登録したペアとなる公開鍵を使って検証することをもって正当性を判断することにあります。

この仕組みにおいてPINなどユーザを認証するための情報（クレデンシャル）はリクエストに署名するための秘密鍵へアクセスするために端末内でだけ使われるため、ネットワーク上を流れず、従来のサインインに比べて安全である、ということです。

参考）Windows 10におけるサインイン時のフロー（Azure AD参加/Microsoft Passport利用）

これが認証サーバはデバイスを、デバイスは利用者を信頼・認証する、つまり「利用者の認証と端末の認証を分離する」というFIDO（https://fidoalliance.org/）そしてMicrosoft Passportの基本的な考え方です。

この考え方では利用者の認証手段を問いませんので、もちろん従来通りパスワードを使って問題はありませんが、
・端末内だけで使うため利便性を上げるにはシンプルな方法が望ましい
・パスワードは使いまわしや漏えいしていることが前提なのでもはや単体で使っても安全ではない
などの理由でPINがデフォルト、さらに利便性と安全性を高めるためにWindows Helloを使った生体認証を使うことが出来るように設計されているのだと考えられます。


つまり、最終的にマイクロソフトが言いたかったことは、
「安心してください、流れてませんから」
「Microsoft Passportという新しい仕組みを使うことでクレデンシャルの盗難が起きないようにしたから、パスワードのように運用上面倒なものを使わなくても安全ですよ」ということです。

少しはすっきりしましたかね。。。やっぱり難しいですね。

参考）昨年のidconで使った資料：FIDO in Windows 10
http://www.slideshare.net/naohiro.fujie/fido-in-windows10

[Windows 10/Azure AD]ハイブリッド環境におけるドメイン参加とシングルサインオン①

こんにちは、富士榮です。

Azure Active Directory（Azure AD）に参加したWindows 10デバイスでのデバイス・サービス間のシングルサインオンの仕組み（Microsoft Passport）については、これまでもidconや本ブログなどでも解説をしてきました。

　[Windows10]デバイス＆サービス間のシングルサインオンの仕組み
　　http://idmlab.eidentity.jp/2015/05/windows10.html
　[FIDO/Windows10]idcon vol.20（別名fidcon）が開催されました
　　http://idmlab.eidentity.jp/2015/05/fidowindows10idcon-vol20fidcon.html


しかし、現実のエンタープライズ・シナリオでは一気にAzure ADへPCを参加させて、クラウドだけで生きていく、ということは考えにくく、まずは現存のオンプレミスのドメインとWindows 10をどうやって組み合わせて活用していくのか？が焦点になっていくものと思われます。

と、いうことで今回はオンプレミスのドメインにWindows 10のPCを参加させて、Azure ADと連携することで得られる利点について解説していきたいと思います。いわゆるハイブリッドID基盤をWindows 10を使うことで更に活用できますよ、というシナリオです。

ちなみに、やれることは単純にデバイスへのログインと社内アプリ、社外アプリへのシームレスなログイン（シングルサインオン）ですが、この環境を実現するためのシナリオとしては複数の方法があります。

１）AD FSを構築してAzure ADとID連携する方法
　現在も主流となっているオーソドックスな方法です。PCはあくまでオンプレのAD DSに参加、ログインをして利用しますので、社外で利用する場合は社内ネットワークへVPN接続するか、Web Application Proxy（WAP）を用意してForm認証する必要があり、AD FSがダウンすると全滅するという弱点がありました。

２）Azure AD WAPを使う方法
　上記１のパターンと似ていますが、PCはAzure ADに参加して社内アプリへのアクセス時だけAzure AD WAPを使うため、可用性の面では改善されたものの、社内にいても社内アプリケーションへのアクセスはあくまでAzure AD WAP経由となるため、ファイルサーバなどの非Webアプリケーションへの対応ができない、など機能面で現実的な選択ではありませんでした。

３）Windows Server 2016のAD FSを使い、Microsoft Passport for Workを利用する方法
　おそらく今後の本命になると思います。社外はAzure ADを使ったMicrosoft Passport、社内はMicrosoft Passport for Work、社内外のつなぎはAzure ADとAD FSの連携という形になるので、オンプレのAD DSに参加したPCでもAzure ADに参加したPCでもシームレスに社内外のアプリケーションを利用できます。非WebアプリケーションについてもMicrosoft Passport for Workではカバーする予定らしいので、そうなると無敵です。弱点は基盤構築が超面倒なところですかね。SCCMとかIntuneとかのMDMが必要になりそうです。

４）Azure AD Connectを使いMicrosoft Passportに使うデバイス情報をオンプレ・クラウド間で同期する方法
　今回紹介する方法です。PCはオンプレのADへ参加するので従来通り社内リソースは統合Windows認証で利用し、社外アプリケーションはAzure ADとMicrosoft Passportで利用する形をとります。認証する局面においてクラウド・オンプレの間で連携がないので、完全に環境を切り離すことが可能なので、可用性はあんまり気にしなくても良いのが利点です。ただ、この後解説しますが現状はちょっと環境を選びます。


では、さっそく解説します。

◆実現すること
おさらいですが、以下を実現します。
・ドメイン参加したWindows 10 PCがAzure ADと連携されているアプリケーションへSSO（PCログインとアプリログインのSSO）できるようにする
・社内ファイルサーバなどへのログインは従来通り統合Windows認証を利用
　※つまり、Windows Server 2016のAD FSを使ったMicrosoft Passport for Workシナリオではありません。
・社外アプリ（Azure AD連携アプリ）へのログインはMicrosoft Passportを利用

◆前提および制限事項
実現するためには以下の前提や制限があります。
・Azure ADとAD DSはAzure AD ConnectでID同期を行っている
・Azure ADとAD DSはフェデレーションしていない（AD FSを使っていない）
・Azure ADとAD DSの間はパスワードハッシュ同期を行っている
・PCはWindows 10（TH2以降）
・ドメインコントローラはWindows Server 2012R2以降
・オンプレドメイン名とAzure ADドメイン名は同一であること
　（Azure AD ConnectでメールなどUPN以外の属性でオブジェクト・マッチングをするとNG。代替UPNでも良いので同一UPNが必要）
・実際にデバイスがAzure ADに登録されるまでには結構時間がかかります。（ログイン、Azure AD Connectによる同期、ログインの順で処理が走るので、同期の前後でログインをする必要があります）


◆準備作業
まず、準備として以下の2点を行います。
１．クライアントPCが自動的にデバイス登録（Workplace Join）を行うためのタスクの有効化

　グループポリシーの設定を行います。
　Windows Server 2016のドメインだと、
　　コンピューターの構成
　　　⇒ポリシー
　　　　⇒管理用テンプレート
　　　　　⇒Windowsコンポーネント
　　　　　　⇒デバイスの登録
　から「ドメインに参加しているコンピューターをデバイスとして登録する」を有効にします。
　※2012 R2サーバだと、「社内参加（Workplace Join）」という名前の項目になっています。

　このポリシーを有効にすることで、クライアントPCにユーザがログインしたタイミングでデバイスを登録するためのタスクスケジューラ（dsregcmd.exe）が起動するようになります。
　（このあたりの細かい動きは次回解説します）


２．有効化されたタスクがAzure AD DRSのドメイン、テナントを解決するためのエントリ（SCP：Service Connection Point）をAD DS上に登録

　１の作業で有効化したタスクがデバイスを登録する先となるAzure ADのサービス名（ドメイン名およびテナントID）をAD DS上に登録する作業です。
　実際の作業としてはAzure AD Connectに含まれるPowerShellのコマンドレット「Initialize-ADSyncDomainJoinedComputerSync」を実行することになります。

　こんな感じです。

　これを行うと、CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=example,DC=comにazureADNameとazureADIdという二つの情報が登録されます。先のタスクスケジューラはこの値を見てデバイス情報を登録する先のAzure ADを判別します。
　※ちなみに、Azure ADのディレクトリ内に複数のドメインが存在する場合、意図しないドメイン名が登録されてしまうことがありますので、その場合は直接AD DS上の値を修正する必要がありそうです。（これが原因かどうかはわかりませんが、うまく動かないことがありました）

◆PCをドメインに参加させ、ドメインユーザでログイン、そして同期する
ここは特に何もいりません。通常の手順です。

ただ、グループポリシーが正常に適用されると「Automatic-Device-Join」というタスクが自動的に実行されているはずです。

結果、いくつかのことが発生します。

まずは、初回ログインの際、ドメインに登録されたコンピュータオブジェクトのuserCertificate属性に証明書がセットされます。（タスクの中で自己証明書を発行します）

このあとAzure AD Connectでデバイス情報の同期を行います。Azure AD Connectの同期ルールを見るとuserCertificateに値が入っていないとAzure ADへコンピューターオブジェクトを同期しないので、この段階で初めて同期対象となるためです。

同期されるとAzure AD上にデバイスが登録されます。登録状態はGraph Exploreで確認するしか方法がありません。

そして、再度ドメインユーザでログインします。
するとAzure AD上に登録されたデバイスとログイン時に実行されるタスクによる登録要求の突合が行われ、Microsoft Passportに必要なKey Registration Serviceエンドポイントでの認証に必要なクライアント証明書がダウンロードされます。
この後、Windows 10はキーペアを生成し、秘密鍵をTPMに、公開鍵をKey Registration Serviceへ登録し、Microsoft Passportのデバイス登録フェーズが完了します。

次回Azure ADへログインする際はTPM上の秘密鍵で署名したリクエストによりPrimary Refresh Token（PRT）が取得できるので、そのあとは必要なアクセストークンを取得してアプリケーションを利用、という流れでシングルサインオンが実現します。

この際、ユーザのアカウント設定のページにはAADTokenBrokerが発現、紐づけられたAzure AD上のアカウント情報が表示されます。

◆Azure ADと連携したアプリケーションへアクセスする
ここまで来れば、これまで紹介したものと同じです。
アクセスパネルにアクセスするとAzure ADでのログインを求められることなく、アクセスできます。

かなりややこしいフローになるため、次回は少し深いところの仕組みを解説し、なぜこのような動きをするのか？を解説したいと思います。

[AD FS]連携アプリケーション毎に対応するIdPへ自動振り分けを行う

こんにちは、富士栄です。

AD FSを使ってアプリケーションとのID連携を行う場合、基本はビルトインのActive Directoryでの認証および属性の提供を行うことになりますが、アプリケーションが増えてきたり、複数の企業でAD FSを使ったりし始めると、AD FSをHUBのように使いたくなってきます。
（他にもプロトコルの変換を行うために使うケースなんかでもHUB的にAD FSを使いたくなります。例えばアプリケーションがws-federationにしか対応していなくて、IdPがSAMLにしか対応していないような場合とかですね。Windows Server 2016のAD FSではOpenID Connectにも対応してくるので、OpenID Connectにしか対応していないアプリケーションをSAMLしかしゃべれないIdPに統合するケースなど、AD FSをHUBとして使うケースも出てくるかもしれません）

そんな場合、AD FSに登録するIdP（Claim Provider）が複数になってしまいますので、利用者自身がどのIdPを使うのかを選択する必要が出てきます。（少なくとも初回は。2回目以降はCookieでブラウザに記憶されます）

AD FSに複数のClaim Providerが設定されているケースです。
下の画面ではビルトインのActive DirectoryとAzure ADを設定しています。

この環境でアプリケーションからAD FSにリダイレクトされるとIdPを選択する画面が表示されます。
これをHome Realm Discovery（HRD）と呼びます。

これって結構面倒くさいですよね。
利用者が間違ったIdPを選択してしまうと一旦Cookieをリセットしてもらって、、、ということにもなりますのでサポートしなければならない情報システム部門からすると非常に頭の痛い問題にもなりかねません。


ということで、例えば絶対に特定のIdPでしか認証させないアプリケーションであれば選択画面（HRD画面）をスキップして直接IdPへリダイレクトさせたいのですが、そういう場合はAD FSに少々設定を行うことで実現可能です。

具体的にはAD FSのPowerShellコマンドレッド「Set-AdfsRelyingPartyTrust」を使って対象のRelying Party（アプリケーション）が指定したClaim Provider（IdP）のみを使うように設定を行います。

構文は以下の通りです。

AdfsRelyingPartyTrust -TargetName <アプリケーション名（RP名）> -ClaimsProviderName <IdP名>

尚、複数のIdPを指定したい場合は、@("AAA","BBB")という形で配列を指定することで対応できます。

詳細は以下のURLにありますので、参考にしてください。
　https://technet.microsoft.com/en-us/library/dn280950.aspx


早速設定してみます。WLSという名前のアプリケーションはAzure ADのみを使って認証する、という設定です。

この状態で先ほどのアプリケーションに再度アクセスしてみます。
（Cookieをクリアしてからアクセスするのをお忘れなく）

選択画面（HRD）が出ずに直接Azure ADへリダイレクトされました。
これで多少なりとも混乱を防ぐことが出来ると思われます。


尚、間違えてClaim Providerを制限しすぎてしまったので元に戻したい、という場合は先と同じコマンドレットに他のClaim Providerを指定してあげれば大丈夫です。

[告知]2月はJapan ComCampでAzure ADとWindows 10の話をします

こんにちは、富士榮です。

先日告知させていただきました通り、今月（1月）は日本ネットワークセキュリティ協会（JNSA）のアイデンティティ管理WGの10周年記念イベントで「ID管理プロジェクトの進め方」について解説させていただきますが、2月は少し毛色を変えてAzure ADとWindows 10についてJapan ComCamp powered by MVPというイベントでお話しさせていただきます。

　イベントサイト：
　　　https://technet.microsoft.com/ja-jp/mt637807


国内の各拠点で同時に開催されるイベントでMicrosoft MVPが中心になって企画・運営をしているらしいです。

私はなぜか東京会場に呼ばれましたので、大阪ではなく東京で登壇させていただきます。

まだ内容は全然考えていませんが、以下がセッション概要です。

タイトル：
　Azure ADとWindows 10によるドメイン環境の拡張
内容：
　クラウドやモバイルを活用しようとすると、例えばPCへのログインだけで社内のアプリケーションへシングルサインオンできたり、グループポリシーでデバイスの制御を行う、といった従来の社内ドメイン環境でできていたことが不可能になってきています。
しかし、Windows 10とAzure AD/Intuneを活用することで従来のドメイン環境に近い利便性や管理レベルを維持しつつクラウドを利用することができるようになってきています。
本セッションではクラウド・モバイルをセキュアに利用するためのAzure ADやIntune、Windows 10の上手な活用方法を紹介します。


もちろん他の会場も含め興味深いセッションも多数あるようなので、ぜひ登録してみてください。
ちなみにストリーミングもやるそうです。

[AD FS]JavaアプリSPとSAML Artifact Bindingで連携する際の証明書ストア

こんにちは、富士榮です。

小ネタです。
JavaでSAML SPとなるアプリケーションを開発した場合のSP⇒IdP間のバックエンド通信に使う証明書の登録に関するTIPSです。

◆SAML Arifact Bindingとは？

まず、SAML Artifact Bindingの通信フローのおさらいです。
簡単に言うと、POST Bindingではユーザのブラウザを経由してSAML AssertionをIdPからSPに渡すのに対して、Artifact Bindingでは認証後Artifactと言われるコードをユーザのブラウザを経由してSPへ渡し、SPはブラウザより受け取ったArtifactをIdPへ渡してSAML Assertionと交換する、という仕組みです。
ややこしいので、SPとIdPの間で直接の通信が行われるタイプのBindingと覚えておいてください。
OAuthやOpenID Connectがわかる人は、Code Flowと同じ考え方と理解すると早いかもしれません。

こんなイメージです。

昔はガラケーなどブラウザで扱えるデータサイズの問題があったので、SAML Assertionそのものをブラウザ経由でPOSTするのではなく、比較的サイズの小さいArtifactを使ってID連携をする必要があったのですが、最近は通信速度や端末性能の向上により、Artifact Bindingが使われることは減ってきています。SPとIdPの間で直接通信をさせなければならないので、クラウドサービスと社内IdPを連携させる場合などの通信の取り回しなども非常に面倒、というのも使われなくなってきた一因です。

ただ、今でもたまにArtifact Bindingしか使えないSAML SPが存在するので、仕方なく実装することがあります。（AD FSではArtifact Bindingをサポートしています。尚、Azure ADはPOST BindingのみなのでArtifact Bindingは使えません）


◆SPとIdP間のSSL通信に使う証明書の信頼設定

先述の通り、POST Bindingではすべての通信がブラウザを介して行われるため、SSL通信に使う証明書のチェックについてはブラウザが信頼している証明書であればなんの問題もありませんし、最悪オレオレ証明書でもユーザが警告を無視してくれさえすれば、ID連携することが可能でした。

しかし、Artifact BindingではSPとIdPの間でSSL通信をエラーなく成立させる必要があるので、SPがSSL通信に使う証明書を信頼している必要があります。

信頼をするための方法はミドルウェアによりさまざまで、例えばsimplesamlphpでは設定ファイルに通信で使う証明書が入っているストアを直接指定する、などの方法をとります。

今回は前回のポストで使ったWebLogic上にデプロイしたJavaアプリケーションの場合のTIPSです。
WebLogicが信頼する証明書ストアはサーバの構成よりキーストアの設定で設定・確認することが出来ます。

初期状態では、デモ用のキーストアおよびJava標準のキーストアが設定されていますので、このキーストアのどちらかにIdPがSSL通信で使う証明書がインストールされている必要がある、ということになります。

今回はAD FSをIdPとして使ったので、AD FSがSSL通信で使っている証明書をExportしてWebLogicが使うキーストアにインストールします。

まずは、AD FS管理コンソールより証明書を開き、Service Communicationに設定されている証明書を開き、DER encoded binary X.509（cer）形式でエクスポートします。

エクスポートしたcerファイルをSPにコピーし、以下のコマンドを実行して証明書ストアへインストールします。

keytool -keystore <ストアのファイル名> -importcert -file <証明書ファイル名>

こんな感じです。

これで、無事にSP⇒IdP間でSSL通信が成立するので、SAML Assertionの受け渡しが行えるようになります。