読者コミュニティ｜SAML入門

SPの実装見てみたいのですがsaml-sp-sampleのソースコードはどこかに公開されてますでしょうか？非公開の場合、SAMLまわりの実装に使用したライブラリ名でも教えて頂けると嬉しいです。

申し訳ございませんが、以下の理由からコードは現状公開できない状況にあります。なにとぞ理解いただければ…。

• かなり手抜きをしているため、これを参考にされると脆弱性を持ったサービスを生み出しかねない
• ちゃんと作ったとして認証周りのコードを公開することは所属企業への影響が無視できない

ライブラリは本書でも紹介しているOneLoginのものを使用しています。
基本的にREADMEの通りなんですが、Properties Fileでの設定ではなく、SettingsBuilderを用いて動的に設定するほうが取り回しがいいですね。

ご返信ありがとうございます。
使用ライブラリが分かれば実装方法は調べられそうなので大丈夫です。
JavaのライブラリはOpenSAML4ぐらいしか知らなくてOneLoginは初めて知ったので次に何か実装する機会には候補入れようかと思います。
（メンナンス終了のIssueが立ってますがメンナンスを引き継ぎたい人が現れたようで良かったですね）

質問ありがとうございます！
仕様上はHTTPSの使用は必須ではないが、推奨される、が回答になりますね。
ほとんどのBindingsやProfilesでRECOMMENDEDと強めに書かれています。

ADFS3.0だと必須とされるというのは自分も知らなかったのですが、盗聴や改ざんを防ぎ、機密性と完全性を担保するためにIdPが必須だと判断するのはわからなくはないかなとは思います。

このあたりの仕様について、

• 簡単に知りたい場合は Overview の4.6 Security in SAMLの章を、
• もう少し突っ込んで知りたい場合は Profiles の4.1.3.3 <AuthnRequest> Is Issued by Service Provider to Identity Providerや4.1.3.5 Identity Provider Issues <Response> to Service ProviderのRECOMMENDEDと書いてあるところを、
• もっと知りたい場合は Security and Privacy Considerations の4 Security Techniquesあたりを
  見てもらえると良いかと思います。

丁寧な回答ありがとうございます。
なかなか仕様を読み込むことは自分のレベルでは難しかったので、とても助かりました。

仕様も具体的な場所を章をしてもらえれば読めると思うので、読んでみようと思います。

質問ありがとうございます！
Protocolsとしては必須として定義はないのですが、Web Browser SSOのProfilesとして必須とされています。
このあたりですね…！

• 4.1.4.1 <AuthnRequest> Usage

  The <Issuer> element MUST be present and MUST contain the unique identifier of the requesting service provider;

• 4.1.4.2 <Response> Usage

  It MUST contain at least one <Assertion>.

特定のProfilesやBindingsを使うときは必須だったりするところがちょっと読みにくいですね…。

早速の回答ありがとうございます！
Profiles のほうもみないといけないんですね、スッキリしました、感謝です！！

感想ありがとうございます！！励みになります！

ややこしくてすみませんが、本書はAmazon等で購入できる商業版とZenn等で購入できる同人版があります。

• 同人版のバージョンとしてはv1.0.1とv2.0.0が存在しています（奥付で確認ができます）
• 商業版と同人PDF版v2.0.0については内容は同じになります。
• 同人冊子版v1.0.1（物理本）と同人PDF版v2.0.0との差分ですが「第 11 章 実際に動かしてみよう」が増えています。

同人冊子版を購入いただいたサイトにて再度PDFをダウンロードしていただけるとv2.0.0が落とせると思いますので、再ダウンロードのほどお願いいたします。
すべての販売サイトで更新したつもりですが、もしv1.0.1が降ってきてしまう場合はご一報いただけると幸いです。

ご返信ありがとうございます。冊子はAmazonだったので商業版だったようです。

ところで、SAMLに伴う秘密鍵管理、証明書更新などの運用面に関心があり調べておりました。

調べているうちに、
サーバ証明書とSAML証明書が出て来て、
サーバ証明書は発行した認証局のルート証明書をブラウザに設定するのに対し、
SAML証明書は（ブラウザとは関係なく）IdPとSPが二者間で直接信頼関係を構築する点が違い、かつ、IdP側証明書はSP側に事前登録するのに対し、SP側証明書はIdP側に登録するのでなく、SAMLリクエストを通じて送付する点が違うように思われました。

主体別、用途別に整理すると以下のとおり。

SP側
SAMLリクエスト署名用証明書
p17のX.509証明書

※p17の事前に公開鍵をSP側で登録とは、SP側でSAMLリクエストを生成するアプリサーバのことでしょうか？★

※p18によればAzure ADの場合署名が無視される。

※必要ならリクエストとともに送付されるので、p44-45においてもIdPへの登録作業なし。

https通信用サーバ証明書
p35により推奨

IdP側
SAMLレスポンス署名用証明書
p43によりSPに登録

https通信用サーバ証明書
p37により推奨

以上のような読み方で合っているでしょうか？
また、★部分な念のため明確化したくご教示頂けると幸いです。

※巻末のウェブサイト一通りアクセスしたのですが、OASYSはアクセスできず、なかなか分かりませんでした。

冊子はAmazonだったので商業版だったようです。

誤解を招いてしまったようですみませんでした。説明を修正させていただきました🙇‍♀️

SP側証明書はIdP側に登録するのでなく、SAMLリクエストを通じて送付する

P17の<X509Certificate>で「事前にこの公開鍵をSP側で登録しておく必要がある」と記載されていますが、これは誤字ですね…。IdP側の間違いです🙇‍♀️
SAML Requestに署名が必要な場合、こちらに関してもSP側で発行された公開鍵をIdP側に登録する必要があります。
署名はお互いに事前に交換しあった公開鍵にて行うことになります。
こちらの説明でスッキリしましたでしょうか？

※巻末のウェブサイト一通りアクセスしたのですが、OASYSはアクセスできず、なかなか分かりませんでした。

物理本やZenn、PDF記載のリンクからアクセスしてみましたがリンクは切れていないようでした。
一応こちらでもリンクを貼っておきますね。

• FrontPage - SAML Wiki
• Technical Overview
• Assertions and Protocols
• Bindings
• Profiles
• Metadata
• Authentication Context
• Conformance Requirements
• Security and Privacy Considerations
• Glossary

ありがとうございます。

p17
「事前にこの公開鍵をIdP側で登録しておく必要がある」の旨承知しました。

＞署名はお互いに事前に交換しあった公開鍵にて行うことになります。
の考え方は理解しやすいのですが、

＞SAML Requestに署名が必要な場合、こちらに関してもSP側で発行された公開鍵をIdP側に登録する必要があります。
について、あくまでSAML Requestに署名が必要な場合に限るので、p44-45では記載が省略されていると理解すればよいでしょうか？
（ただ、p18によれば、Azure ADはSPのSAML Requestへの署名を無視する・検証しないようなので、SP側の公開鍵をIdP側に登録したくてもさせてもらえないように見受けました。そのため、p17ではSP側の公開鍵証明書を送りつけるのかと思ったのですが、いずれ仕様書を直接読めるようになれたらと思います。）

OASYS仕様にはアクセスできました。お手数おかけしました。

ところで本日たまたま大きめの本屋に立ち寄ったので認証回りの本のラインナップを調べたところ（普段Amazonではなかなか分からないので）、
・O'REILLY`の「実践Keycloak」では、SAMLの重要性を指摘するも詳細割愛
・「認証と認可Keycloak入門」でも、SAMLの取り扱いはOIDCなどに比べると少なめ
なので、改めて「SAML入門」の踏み込み具合は助かりますし、敬意を表します。（上の方で一歩と書いてしまいましたが、一歩どころか一万歩？）
いずれ第11章も手を動かせたらと思います！

あくまでSAML Requestに署名が必要な場合に限るので、p44-45では記載が省略されていると理解すればよいでしょうか？

そうですね省略しています…！
世の中のSPでRequestに署名するケースに対応しているものがほぼないので…。
本書では膨大な仕様のなかであまり使われないものはなるべく説明を省いています。

Azure ADに関してですが、無視するのはRequest内のいくつかの属性ですね。

Consent、Destination、AssertionConsumerServiceIndex、AttributeConsumerServiceIndex、ProviderName など、他の AuthnRequest 属性はすべて無視されます。

https://learn.microsoft.com/ja-jp/azure/active-directory/develop/single-sign-on-saml-protocol#authnrequest

Requestへの署名はプレビューで対応しているようですが、自分はまだ試したことがないです。

署名された認証要求の要件を適用するように Azure AD を構成できます (プレビュー)。 有効にした場合は、署名された認証要求のみが受け入れられます。

https://learn.microsoft.com/ja-jp/azure/active-directory/develop/single-sign-on-saml-protocol#signature

改めて「SAML入門」の踏み込み具合は助かりますし、敬意を表します。（上の方で一歩と書いてしまいましたが、一歩どころか一万歩？）

ありがとうございます！！実装できるレベルでのまとまった説明は日本語では存在しなくて、苦しみながら1年近くかけて書いたのでそう言ってもらえるととてもうれしいです。

ご返信ありがとうございます。
（本日関係者で会話する機会があったのですが、おかげ様でスムーズに進みました。もちろん本書も出典示しながら自己責任で参照しています。）

ところで、SAMLにはシングルサインオンのみならず属性情報の伝達という観点でも注目していたのですが、会話でプロビジョニング・SCIMというキーワードも出て来たので、薄々気付いてはいたつもりなのですが、、未だ未だ勉強すべきことが残されていたようです。

またSAML関連で何かありましたら投稿させて頂けると幸いです。m(__)m

ありがとうございます！！
特にSLOに関してまとめていただきありがとうございます…！
書いておいたほうがよかったなぁと少し後悔していたところではあったので、別途まとめていただけて嬉しいです。
SLOについてはIdP側でも実装されていない場合がありますし、挙げていただいているようにSCIM等によるアカウントの非アクティブ化や管理者によるセッションの破棄等、別の代替手段を用意するほうが優先度が高いだろうと自分も考えています。
ユーザーが端末等を紛失した場合、管理者はIdP側でアクセス権を取り消すことになると思いますが、その際Azure ADでのベストプラクティスもSCIMによるプロビジョニング解除または非アクティブ化ですね。
https://learn.microsoft.com/ja-jp/azure/active-directory/enterprise-users/users-revoke-access

すみません、検証用のアプリケーションはそのボタンを押すとIdPにRequestするだけの作りになっています。認証済みかどうかを保持しないため毎回Requestが発生します。

SPにてすでに認証済みの場合はご想像通り毎回聞きに行く必要はありません。
セッションの有効期限が切れていたり、IdPからシングルログアウトのRequestが来たなどしてログアウトしていたりする場合は再度SP-InitiatedやIdP-Initiatedによるログインが必要です。

回答ありがとうございます。了解いたしました。

ここで言うトークンはアカウントを一意に特定できるような何らかの識別子のことを指しています。
UUIDでもよいですし、十分に長いランダムな英数字でもよいです。

SPがアカウント毎に何らかの識別子となるものを発行し、それをRelayStateとうまく組み合わせることでメールアドレス等に頼らずにIdPの一意なIDとSPのアカウントを紐付けることができるよね、というのがそこの項の趣旨になります。

回答ありがとうございます。納得いたしました。