Open26

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

ピン留めされたアイテム
kanakana

9/1に同人版をver.2.0としてアップデートしています。
PDFについても更新しているので、必要があれば購入されたサイト(Zenn、BOOTH、技術書典オンラインマーケット)にて再ダウンロードをお願いいたします。
<アップデート内容>
商業版出版時に加筆した「SPとIdPを繋げてみる」章を追加

※最新の内容は商業版 = 同人版v2.0.0となります。

kanakana

本の感想や質問をお気軽にコメントしてください。
初心者なりに仕様書を見ながらまとめたので、間違っているところがあるかもしれません。
https://zenn.dev/kxn4t/books/3778cace88911a

eichisandeneichisanden

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

kanakana

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

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

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

eichisandeneichisanden

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

Shinichi HashibaShinichi Hashiba

認証フローでのユーザ⇔SP間、ユーザ⇔IDP間のHTTP通信はHTTPSが必須なのでしょうか。

5章のサンプルに使用しているOneloginのSAMLRequestではAssertionConsumerServiceURLがHTTPになっていますし、同じOneloginが提供するpython3-samlのサンプルSPサイトもHTTPによるものです。
一方、ADFS3.0(Windows Server 2012 R2)をIDPとして、python3-samlのサンプルをSPとして登録しようとすると、AssertionConsumerServiceURLがHTTPであると登録不可とエラーが出ており、HTTPSが必須なのかどうかわからないです。

kanakana

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

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

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

  • 簡単に知りたい場合は Overview4.6 Security in SAMLの章を、
  • もう少し突っ込んで知りたい場合は Profiles4.1.3.3 <AuthnRequest> Is Issued by Service Provider to Identity Provider4.1.3.5 Identity Provider Issues <Response> to Service ProviderのRECOMMENDEDと書いてあるところを、
  • もっと知りたい場合は Security and Privacy Considerations4 Security Techniquesあたりを
    見てもらえると良いかと思います。
Shinichi HashibaShinichi Hashiba

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

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

okarinokarin

SAML Request や Response の必須項目に関して質問です。

本書の 5.1.1 AuthnRequest において、 <Issuer> が必須となっていますが、Protocols の 3.2.1 Complex Type RequestAbstractType (1489行目) をみると、

<saml:Issuer> [Optional]

と記載されていました。

また、5.2.1 Response において、 <Assertion> も必須となっていますが、 Protocols の 3.3.3 Element <Response> (1928行目) では

<saml:Assertion> or <saml:EncryptedAssertion> [Any Number]`

と記載されており、こちらも必須項目ではないのではないかと思います。

これらは、「仕様的には必須ではないが、実用上ほぼ必須の項目」という意味に捉えると良さそうでしょうか?

kanakana

質問ありがとうございます!
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を使うときは必須だったりするところがちょっと読みにくいですね…。

okarinokarin

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

samlaisamlai

感想、質問させていただきます。
冊子購入し、先ほど読み終わりました。
SAMLについては、書籍では例えば、SoftwareDesign2020/12p p39-40、マスタリングTCP/IP情報セキュリティ編第2版p134-に、セキュリティ入門書の中では比較的確かな説明があるように思われるのですが、入口としては分かりやすいのですが、https/サーバ証明書、署名用証明書が必須かどうか分かりにくいのに対し、本書では実装を意識されているということもあり一歩踏み込んだ説明があり、(未だ入口ですが以前より)理解が深まりました。
数ヶ月前には手にしていたのですが、ようやく最後まで辿り着きました。

冊子最終頁にコミュニティの紹介がありPDF2.09/1ではIdP、SPを繋いでみる章が追加されたということで、冊子のverが1.07/8だったので新規情報を得たくダウンロードしたのですが、差分が分かりませんでした。
PDF2.0と冊子1.0の差分が有れば教えて頂けると幸いです。もしかしたら同じだったでしょうか?

kanakana

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

ややこしくてすみませんが、本書は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が降ってきてしまう場合はご一報いただけると幸いです。

samlaisamlai

ご返信ありがとうございます。冊子は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はアクセスできず、なかなか分かりませんでした。

kanakana

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

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

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

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

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

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

samlaisamlai

ありがとうございます。

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章も手を動かせたらと思います!

kanakana

あくまで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年近くかけて書いたのでそう言ってもらえるととてもうれしいです。

samlaisamlai

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

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

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

okarinokarin

SAML入門を読んでから実際に実装してみて、つまづいたところを記事にしてみました。
暇なときにでも読んでもらえると嬉しいです〜〜
https://zenn.dev/ksrnnb/articles/36ba8dcc4f4c64

kanakana

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

yokoshinyokoshin

読ませて頂きました。非常に読みやすく勉強になりました。
素朴な疑問がありますので、こちらで質問させて頂きました。

書籍の11.3節にある動作検証を見ると、SPで「Log in with SAML」を実行するとrequestとresponse(オレンジラベル)がそれぞれ発生することが確認できました。この後、Backで戻って再度「Log in with SAML」を実行すると、やはりrequestとresponseがそれぞれ発生していました。このことから、ログインの都度idpにリクエストに行っていることが分かりました。

その後を読み進めると、12.4節で実装について言及があります。ここで「特にResponseの検証は複雑です」とあるのですが、ここで素朴な疑問が発生しました。それは、上述の通り都度idpに確認に行くのであれば、SPにてResponseの検証を行う必要が無いのではないかということです。読み始めたときの想像ではクライアントが認証情報を持っていればSPはidpにリダイレクトしないと思っていました。

この点について何か補足等頂けると大変ありがたいです。どうぞ、よろしくお願いします。

kanakana

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

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

yokoshinyokoshin

ありがたく読ませて頂きました。別件で質問を投稿させて頂きましたが、もう1件、基本的な質問をさせてください。

書籍の12.2.1節に「例として、次のような解決策が考えられます」として2例挙げて頂いています。この内の2点目にて「アカウント毎にトークンを発行する」とありますが、ここで言うトークンとは何を意味するものでしょうか?

知識不足で申し訳ないのですが、”トークン”で検索すると下記のような情報がヒットし、混乱しました。
・ワンタイムパスワードを生成するツールの総称
・ユーザー ID およびセキュリティー属性情報を交換するための XML ベースの OASIS 標準
・その他、いろいろ

可能であれば、ここで書いて頂いているトークンとは誰が発行する何のことなのかを補足頂けるとありがたいです。
たびたび申し訳ありません。よろしくお願い致します。

kanakana

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

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