今、SAML が解決するさまざまな課題を考察します。
SAML はゼロトラストに欠かせないプロトコルですが、初心者には難しすぎるイメージもあります。そこで、ひとめでわかる図解入りで SAML の基本と注目ポイントも解説します。
- ライター：渥美 淳一
- セキュリティアーキテクトとして活動。変革し続けるニーズからセキュリティのあるべき姿を見極める。セキュリティには統合されたアイデンティティ基盤が欠かせないと考えている。
目次
SAML が解決する課題とは？
ランサムウェア対策
警察庁 より「ランサムウェアの感染経路の 68％ が VPN 機器からの侵入」と発表されました。脆弱性対応で一週間だけ多要素認証を無効化した VPN 経由で侵入されたニュースもありました。多くの攻撃者がランサムウェアの侵入口として VPN を狙ってきます。パスワードや安全性の低い多要素認証で VPN 接続できてしまう状態は危険です。
そこで SAML です。
SAML はアクセスしてきたユーザーの認証を他のシステムにお願いする技術です。SAML を使って VPN ユーザーの認証をより堅牢な認証システムにお願いします。強度の高い認証に合格しなければ VPN 接続できません。VPN 単体で認証しないことが結果としてランサムウェア対策になります。
攻撃トラフィックの削減
SAML により、VPN や SASE の前にもう一つのセキュリティを追加します。こちらも認証要求（SAML）が必須となり、先に認証しなければ攻撃対象にアクセスできません。結果、SASE やクラウドサービスの負担が軽くなり、快適になります。攻撃トラフィックが削減されるため、セキュリティ監視もしやすくなります。
フィッシング対策
Microsoft 365 を利用する組織がフィッシング攻撃の標的にされています。より堅牢な認証システム（組織のサインイン ページ）で認証しますと、異常に気づきやすくなります。普段と違う画面でパスワードなどを要求されるからです。加えてフィッシング攻撃に強い認証（FIDO2 や証明書認証など）を導入しやすくなります。
このように、SAML は組織のセキュリティ強化に大きく貢献します。
SAML とは？
基本データ
|
通信フロー
SAML のやりとりを具体的に見てみましょう。
ユーザーは SP または IdP の URL にアクセスします。
SP にアクセスした場合、SP から 認証要求（AuthnRequest）が送られてきます。
認証要求には上図のような情報が含まれています。
Destination はこの認証要求の宛先、実際に認証する IdP の URL です。
ACS は Assertion Consumer Service の略で、アサーションを使うサービス（つまり SP）のことです。IdP がユーザーに発行したアサーションをユーザーから受け取って検証する URL になります。SP はユーザーに対して「アサーションをもらったら ACS URL に提出してね」とお願いしています。
ProtocolBinding はアサーションを含む SAML メッセージをどうやって送ってほしいか、です。HTTP-POST または HTTP-Redirect がよく使われます。違いは下表です。この例では SP は「HTTP-POST で応答（Response）してね」とお願いしています。
| HTTP-POST | アサーションや署名を含む長い SAML メッセージは HTTP ペイロードに入れて HTTP POST で送る |
| HTTP-Redirect | 短い SAML メッセージは URL に入れて HTTP GET で送る |
Version は利用する SAML バージョンですが、多くの場合ここは「2.0」です。
Issuer は認証要求の発行者、つまり SP です。
以下は実際の（XML フォーマットの）認証要求のイメージです。
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="認証要求のID"
IssueInstant="2023-03-10T01:06:06Z"
Destination="認証要求の宛先URL（IdP）"
AssertionConsumerServiceURL="アサーションの提出先URL（SP）"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0"
>
<saml:Issuer>認証要求の発行者（SP）</saml:Issuer>
</samlp:AuthnRequest>
ユーザーは SP から受け取った認証要求を Destination の IdP へ送ります。
IdP のログイン画面になります。ユーザーは IdP にログインします。認証（ログイン）の仕組みは SAML のスコープ外になるため、お使いの IdP に依存します。SAML は認証連携のための仕組みであり認証には関与しません。
認証後、IdP はユーザーへ 応答（Response）を返します。
この応答にアサーションが含まれます。
Subject にこのユーザーの ID が書かれています。「NameID」と呼ばれ、メールアドレスなどが使われます。
Conditions に書かれているエンティティ ID（SP）は SP を識別するための ID です。
AuthnStatement には IdP が行った認証の種類・強度（AuthnContextClassRef）が書かれています。これにより SP はどのような認証が行われたかを知ることができます。例えば「PasswordProtectedTransport」であれば、IdP がパスワード認証したことが分かります。SP がログイン方法を指定して認証要求するオプションもあります。
AttributeStatement にはこのユーザーの属性情報が書かれます。例えば「姓」「名」「役職」「部署」などです。SP はユーザーの属性情報に従ってユーザーに与える権限をコントロールできます。
以下は実際の応答のイメージ（注目ポイントを抜粋したもの）です。
<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
Destination="ACS URL（SP）"
ID="応答のID"
InResponseTo="認証要求のID"
IssueInstant="2023-03-10T01:06:16.197Z"
Version="2.0"
>
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
>応答の発行者（IdP）</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">署名の情報</ds:Signature>
<saml2p:Status xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</saml2p:Status>
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
ID="アサーションのID"
IssueInstant="2023-03-10T01:06:16.197Z"
Version="2.0"
>
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
>アサーションの発行者（IdP）</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">署名の情報</ds:Signature>
<saml2:Subject xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">ユーザーID</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData InResponseTo="認証要求のID"
NotOnOrAfter="2023-03-10T01:11:16.197Z"
Recipient="ACS URL（SP）"
/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
NotBefore="2023-03-10T01:01:16.197Z"
NotOnOrAfter="2023-03-10T01:11:16.197Z"
>
<saml2:AudienceRestriction>
<saml2:Audience>SPを識別するためのID（entityID）</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
AuthnInstant="2023-03-10T01:06:14.954Z"
SessionIndex="認証要求のID"
>
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>認証の種類・強度</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:Attribute Name="firstname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
>
<saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string"
>淳一</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="lastname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
>
<saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string"
>渥美</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="title"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
>
<saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string"
>主任</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="department"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
>
<saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string"
>ビジネス開発本部</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>
</saml2p:Response>
ユーザーは IdP から受け取った応答を Destination に書かれた ACS URL（SP）に提出します。SP はアサーションを検証し、問題なければユーザーは SP を利用できるようになります。
SP は認証要求するときに RelayState=値 のようなパラメーターを URL などに埋め込む場合があります。これにより SAML 成功後にユーザーを適切な SP リソースの URL に誘導できます。
SAML コソコソ噂話
IdP をオンプレミスのシステムから IDaaS に変更したところ、IdP の応答に違いがありました。
変更前の IdP の応答は <saml2p:Response から始まりました。
変更後の IdP の応答は <samlp:Response から始まりました。
見た感じ、変更前は SAML バージョンが「2.0」、変更後は「1.0」と思うかもしれませんが、それは誤解です。どちらも「2.0」です。そのため、ここの違いによる影響はないと思っていましたが、変更後に SSO に失敗する SP がありました。SP の設定変更により解決（成功）しましたが、ここを検証する SP もあることを学びました。
どちらの応答も正常なのですが、SP がそれをどう検証するか？にも注意が必要です。
動作確認
何かあったときは「SAML-tracer」による動作確認をオススメします。Google Chrome や Firefox などの Web ブラウザから無料で使えます。Firefox の場合、以下にアクセスして saml で検索、追加するだけです。
Firefox (ja) 向けアドオン (mozilla.org)
赤枠をクリックすると SAML-tracer 画面が表示されます。その状態で SAML 通信しますとその内容を追跡できます。認証要求や応答には「SAML」マークが付きます。
Summary タブが SAML メッセージを見やすくしてくれますのでオススメです。
プロトコルとアサーション
一口に「SAML」と言っても、プロトコルとアサーションは区別する必要があります。
SP が Microsoft 365 の場合、SAML プロトコルではなく WS-Federation プロトコルを使う IdP があるからです。（SAML プロトコルを使う IdP もあります）
しかしどちらのプロトコルも SAML アサーションによって認証情報やユーザー情報を応答します。
プロトコルはアサーションを含む SAML メッセージをやりとりするための認証要求および応答の仕様です。アサーションはやりとりするデータです。
SAML プロトコルで応答される SAML アサーション例
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ID="応答のID"
InResponseTo="認証要求のID"
Version="2.0"
IssueInstant="2023-03-07T03:55:39Z"
Destination="SP"
>
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">IdP</saml:Issuer>
...中略...
<saml:Assertion Version="2.0"
ID="アサーションのID"
IssueInstant="2023-03-07T03:55:39Z"
>
<saml:Issuer>IdP</saml:Issuer>
<saml:Subject>
...以下略...
WS-Federation プロトコルで応答される SAML アサーション例
<wst:RequestSecurityTokenResponse xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
<wst:Lifetime>
<wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2023-03-06T06:42:50Z</wsu:Created>
<wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2023-03-06T07:42:50Z</wsu:Expires>
</wst:Lifetime>
<wst:RequestedSecurityToken>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
Issuer="IdP"
IssueInstant="2023-03-06T06:42:50Z"
AssertionID="アサーションのID"
MinorVersion="1"
MajorVersion="1"
>
...以下略...
SAML コソコソ噂話
私の知る WS-Federation プロトコルを使う SP は Microsoft 365 だけです。他にも Microsoft Windows ベースのレガシー Web アプリケーションが使っていたようですが、私は SAML プロトコルが「事実上の標準」というイメージを抱いています。Microsoft 365 は SAML プロトコルにも対応しています。
今後、SAML のライバル（？）は「OpenID Connect」になると思います。
シングルサインオン
SAML により、IdP に一度ログインすれば複数の SP を利用できます。つまりシングルサインオン（SSO）が可能です。
SAML には SP-Initiated SSO と IdP-Initiated SSO の 2 種類の SSO シナリオがあります。両者の違いは、ユーザーが最初に SP と IdP のどちらの URL にアクセスするか？です。すでに組織内のポータルサイトがある場合、そこに集められた業務システムへのリンクをクリックして始めます。この場合は SP の URL アクセスからスタートしますので SP-Initiated SSO になります。
IdP-Initiated SSO のほうが通信フローがシンプルです。IdP-Initiated SSO は IdP の URL アクセスからスタートします。ユーザーはログイン後の IdP ポータル（下図左）に並ぶ SP のアイコンをクリックして応答を受け取ります。
なぜ 2 種類あるのでしょうか？
それは一方しかサポートしていない SP があるからです。例えば VPN は SP-Initiated SSO のみサポートするケースが多いです。また SP-Initiated SSO の場合、ユーザーは SP から認証要求を受け取り IdP に送信します。SP はこの認証要求により厳格なログイン方法を指定（RequestedAuthnContext）できる点がメリットです。
すでに組織内にポータルサイトがあるケースも多いため、結果的に SP-Initiated SSO がよく利用されています。
シングルログアウト
SAML はセキュアなシングルログアウト（SLO）も可能です。
ユーザーが 1 回の操作で SP と IdP の両方からログアウトできます。こちらも SP-Initiated SLO と IdP-Initiated SLO の 2 種類があります。両者の違いは、ユーザーが SP と IdP のどちらのログアウトボタンをクリックするか？です。
SP でログアウトボタンをクリックした場合、SP からユーザーへログアウト要求（LogoutRequest）が送られてきます。
<saml2p:LogoutRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="IdPのSLO URL"
ID="ログアウト要求のID"
IssueInstant="2023-03-13T09:00:49.324Z"
NotOnOrAfter="2023-03-13T09:05:49.324Z"
Version="2.0"
>
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">ログアウト要求の発行者（SP）</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">署名の情報</ds:Signature>
<saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
>ログアウトするユーザーのID</saml2:NameID>
<saml2p:SessionIndex>終了するセッションのID</saml2p:SessionIndex>
</saml2p:LogoutRequest>
ユーザーは SP から受け取ったログアウト要求を Destination（IdP の SLO URL）に送ります。IdP からユーザーにログアウト応答（LogoutResponse）が送られてきます。
<saml2p:LogoutResponse xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="SPのSLO URL"
ID="ログアウト応答のID"
InResponseTo="ログアウト要求のID"
IssueInstant="2023-03-13T09:00:49.775Z"
Version="2.0"
>
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
>ログアウト応答の発行者（IdP）</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">署名の情報</ds:Signature>
<saml2p:Status xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</saml2p:Status>
</saml2p:LogoutResponse>
ユーザーは IdP から受け取ったログアウト応答を Destination（SP の SLO URL）に送ります。ユーザーは SP と IdP の両方からログアウトした状態になり、ログイン画面に戻されます。
SAML コソコソ噂話
SLO は必須ではないため、まだ SSO ほど世間に浸透していない印象です。上に挙げた SP-Initiated SLO のみサポートする IdP が一般的かもしれません。加えてログアウトした SP のみセッションが終了し、他の SP はそのまま使えてしまう実装も多いです。
セキュリティ的には 1 回の操作ですべての SP から強制的にログアウトされるのが理想だと思います。
SP と IdP の信頼関係
SAML を使うためには事前に SP と IdP の信頼関係を結んでおく必要があります。
これは 通信フロー で使われる Destination（認証要求や応答の宛先 URL）などを事前に交換しておくことを言います。人間で例えるなら名刺交換のイメージでしょうか。そしてお互いに相手の情報（下図）を登録しておきます。誤った情報を登録しますと SAML が成功しないため、セキュアです。
登録作業を簡単に行えるように相手からもらえるファイルを「メタデータ」と言います。相手のメタデータをインポートするか、相手の情報をひとつずつ手動で登録します。後者は面倒なのでメタデータが重宝されます。
SP メタデータの例です。
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
entityID="SPを識別するためのID"
validUntil="2033-03-10T08:54:47.907Z"
>
<md:SPSSODescriptor AuthnRequestsSigned="認証要求に署名するか否か（true or false）"
WantAssertionsSigned="アサーションの署名が欲しいか否か（true or false）"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>署名を検証するためのSP証明書</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="SPのSLO URL"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="SPのSLO URL"/>
<md:NameIDFormat>ユーザーID（NameID）の形式</md:NameIDFormat>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="応答の宛先URL"
index="0" isDefault="true"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>
IdP メタデータの例です。
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
entityID="IdPを識別するためのID">
<md:IDPSSODescriptor WantAuthnRequestsSigned="認証要求の署名が欲しいか否か（true or false）"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>署名を検証するためのIdP証明書</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="IdPのSLO URL"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="IdPのSLO URL"/>
<md:NameIDFormat>ユーザーID（NameID）の書式</md:NameIDFormat>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="認証要求の宛先URL"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="認証要求の宛先URL"/>
</md:IDPSSODescriptor>
</md:EntityDescriptor>
信頼関係を結ぶことで SP は認証要求を、IdP は応答を送信できるようになります。SP は応答（アサーション）に含まれる、IdP による署名を検証できるようになります。
NameIDFormat には応答に含まれるユーザー ID の対応可能な書式が指定されています。種類はいろいろありますが、よく目にするのは「emailAddress」や「unspecified」です。後者は SP と IdP が共に対応可能であれば自由で、メールアドレス形式が使われる場合もあります。
IdP 証明書の更新
SAML を使い続けるために必要な作業、それが IdP 証明書の更新です。
IdP 証明書は SP と IdP の信頼関係 であらかじめ交換され、SP に登録されています。この IdP 証明書には有効期間があるため、いつまでも使い続けることはできません。有効期間を過ぎると SAML に失敗しますので一大事です。その前に IdP で IdP 証明書を更新し、それを SP にも登録し直す必要があります。
IdP のみ IdP 証明書を更新すると SAML に失敗します。応答（アサーション）は新しい IdP 証明書のペア鍵で署名されます。古い IdP 証明書に含まれる公開鍵ではこの署名を検証できません。結果、怪しい応答と判定され、SAML が成立しません。この実装も SAML がセキュアと言われる所以です。
応答に含まれる IdP 証明書の有効期間は SAML-tracer でも確認できます。応答を選び、Summary タブの Download リンクから IdP 証明書をダウンロードできます。下図はダウンロードした IdP 証明書の有効期間の例です。
IdP 証明書の更新は担当者の交代などにより忘れられてしまう恐れがあるためご注意ください。IdP 証明書の有効期間の終了 1 カ月前などにメールで通知してくれる IdP がオススメです。
SAML コソコソ噂話
「じゃあ SP 証明書の更新も必要では？」と考えました。
SP 証明書は、SP からの認証要求やログアウト要求の署名を検証したい場合に使われます。その場合は IdP 証明書と同様、有効期間内に更新する必要があると思います。しかし認証要求の署名は必須ではありません。経験則では署名しないケースが多かったです。認証要求の署名を検証しない仕様の IdP もありました。
そんな認証要求と違い、ユーザー ID など大事な情報が含まれる応答は、改ざんを防ぐための署名が必須となります。
最後に
「適切な認証をしなければ利用できない」、これがゼロトラストの第一歩です。
SAML によって IdP と SP を分離し、すべての認証を常に IdP に委ねることで、効果的なゼロトラストにつながります。IdP に求められるのはセキュリティ（高い認証強度）と利便性（パスワードレスなど負担の少ない認証）の両立です。ユーザーやデバイスを常に検証すべきゼロトラストにおいて、利便性は特に重要となります。
さらに IdP は複数 SP の代わりに認証しますので、IdP が停止したら複数 SP を利用できなくなります。停止しない IdP を選ぶことも大事です。
SAML はゼロトラストに欠かせない技術ですので、このブログが微力ながら皆さまの一助となりましたら幸いです。IdP のリプレースを検討される際は弊社までご相談ください。
- 登壇
NPO 日本ネットワークセキュリティ協会 標準化部会
デジタルアイデンティティＷＧミニウェビナー 第1回 - 著書
技術評論社 Software Design 別冊シリーズ
今さら聞けない暗号技術＆認証・認可
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
