#SAML Profiles ～ SSOだけじゃなく色んなシナリオあるって知ってた？～

以前の記事で振り返っていたSAMLの仕様を掘り下げてみようのパートです。

まずはCore･･･にいきたいところですが、プロファイル仕様についてです。
どのようなシナリオで利用されるかが書いてある仕様なので、全貌を俯瞰しやすいかと思いこれから攻めることにしました。

Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

存在するプロファイル

目次から抜粋。思ったよりたくさんありました

SAMLは、認証連携だけでなくID連携が強く意識されている仕様なので、**NameID（名前識別子）**の管理やマッピングのプロファイルが存在します。

SAML SSO

WebブラウザSSO

ECP（Enhanced Client or Proxy）

IdPディスカバリ

SLO（Single Logout）

NameID管理　

Artifact Resolution

Assertion要求

NameIDマッピング

SAML Attribute

以下、各プロファイルについて見ていきます。
図は全て仕様書からの抜粋。

###WebブラウザSSO
最も使われているProfileがこれでしょう。というか、SAML使ってます！と謳っているものが指すのははほとんどこれ。詳細は以前の記事で触れているのでそちらを参照ください。

###ECP（Enhanced Client or Proxy）
ECPはSAMLを話せるプロキシ、のようなものです。ブラウザではないUserAgentがWebブラウザSSOのようにSAMLを利用する際に活用されます。

ECP が SP に HTTP Request を発行する

SP が ECP に <AuthnRequest> を発行する

ECP が IdP を決定する

ECP が <AuthnRequest> を IdP に伝達する

IdP がユーザを識別する

IdP が ECP に SPをターゲットとした <Response> を発行する

ECP が <Response> を SP に伝達する

SP がユーザのアクセスを許可/拒否する

ECPについては、Shibbolethのwiki に分かりやすい解説がありました。

###IdPディスカバリ
同じトラストサークル中に複数のIdPが存在する場合、ユーザがどのIdPを常用しているのかを確認するプロファイルとなります。共通ドメインクッキーで解決する方法が定義されており、シーケンスもありません。

###SLO（Single Logout）
ログインだけでなく、ログアウトも共有しようというプロファイルです。

ユーザがログアウトを試みたSP から IdP に <LogoutRequest> が発行される

IdP は終了するセッションを特定する

IdP は <LogoutRequest> を他のSPに発行する

IdP から <LogoutRequest> を受け取った他の SP が IdP に <LogoutResponse> を返却する

IdP は <LogoutRequest> を受け取った SP に <LogoutResponse> を返却する

ややこしい･･･
そして途中で通信切れたらSLO終わらない

OIDCでは＋α のことが Session Management で実現できます。

###NameID管理
NameIDの変更が発生した際に、それを他のProviderに伝達するプロファイルです。

変更を知らせたい Providerが <ManageNameIDRequest> を相手側 Provider に発行する

要求が処理された後、<ManageNameIDResponse> が返却される

###Artifact Resolution
Artifactを解決するためのプロファイルです。

Artifactって･･･いきなり何のことですか？！って感じだと思いますが、SAML Bindingsで定義されている通信方法のうちのひとつに登場する、チケットのようなものです。User Agent 経由の Front Channel で大きなサイズの電文のやり取りをしなくて良いように、電文の代わりに Artifact というチケットを渡しておいて、あとで Back Channel でチケットと電文を引き換える、みたいなイメージで使われるものです。

その**「チケットと電文を引き換える」**部分のプロファイルになります。

要求元が <ArtifactResolve> を発行する

要求が処理されたあと、 <ArtifactResponse> が返却される

###Assertion要求
ユーザインタラクションが必要ない Back Channel で Assertion を要求するプロファイルです。

WebブラウザSSOで送付するRequest電文は <AuthnRequest>でしたが、<AssertionIDRequest> や <SubjectQuery>、<AuthnQuery>、<AttributeQuery>、<AuthzDecisionQuery> などでAssertionを要求する場合、このプロファイルになります。

Query あるいは Request が発行される

<Response> が発行される

###NameIDマッピング
識別子ってひとつしかないんじゃないのマッピングって何それ
となるかもしれませんが、SAMLでは使うNameIDのPolicyをあれこれ指定できるので、「別の形式のNameIDに変換して！」とか「別のSPが解釈できるNameIDに変換して！」といったことが発生します。そういう時に使うプロファイルです。

必要なエンティティから IdP へ <NameIDMappingRequest> が発行される

IdP は要求を処理し、 <NameIDMappingResponse> を発行する

###SAML Attribute
これはProfileなのかなぁ。
属性情報のやりとりのプロファイルは、上記 Assertion要求 の通りです。

ここでは、属性情報をやり取りするときに、こういう属性情報はこういうパラメータ名で送りましょうとかそんなのが定義されているように見えます。

##おわりに
SAMLと言っても、大半の方は「WebブラウザSSO」しか触れたことがないのではないでしょうか。実はこんなにたくさんのプロファイルが存在して、いろんなことが検討されていたのです。私も把握できていないものがちらほらあります

しかし、改めて仕様書だけ見ても、案の定さっぱり

Profileの仕様を読めば、その通信は、どんなシナリオでどういった目的で、やり取りされるものなのかが理解できるだろうと思ったのですが、そうでもなくて･･･。

「こういうプロファイルがあります」「こういう電文のやりとりがされます」については細かく記されているものの、どういった目的で使われるプロファイルなのかっていうのがやっぱり見えてこなかったです

そういったところこそ知りたいのに、なかなか、勉強するって難しいですね