こんにちは、富士榮です。
SAMLaiです。AIではありません。愛です。サムライです。
ということで、以前アナウンスさせていただいた大学ICT推進協議会（AXIES）の認証基盤部会主催の勉強会でSAMLを知っている人向けのOpenID Connect講座をやってきましたので資料をこちらにおいておきます。
もちろん一般企業などにも使える話だと思うので、ご覧ください。
OPTIONAL. Informs the Authorization Server of the mechanism to be used for returning parameters from the Authorization Endpoint. This use of this parameter is NOT RECOMMENDED when the Response Mode that would be requested is the default mode specified for the Response Type.
まぁ、元々はOAuth2.0のレスポンスの定義なので、こちらの仕様をみる方が適切といえそうです。
https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#ResponseModes
OPTIONAL. Informs the Authorization Server of the mechanism to be used for returning Authorization Response parameters from the Authorization Endpoint. This use of this parameter is NOT RECOMMENDED with a value that specifies the same Response Mode as the default Response Mode for the Response Type used.
このOAuth2.0の仕様が発行されたのが2014年なのでその時点ではqueryとfragmentの2種類だけが本文には記載されており、追加モードとして今回の主役であるform_postの定義への参照が記載されています。
と、ここでちょっと待て、、と。
上記を見るとresponse_typeのデフォルトのresponse_modeの値を取る場合以外はこのパラメータを使うことは推奨しない、と明確に書いてありますね。
ということは、Azure AD B2Cが外部IdPと連携する際にresponse_typeの値に関わらずresponse_modeを必ず指定するのは推奨外の動作ってことですよね。。
また、先日書いたEntra IDの外部認証プロバイダ連携の場合はresponse_type=id_tokenでリクエストがされ、かつ外部認証プロバイダからはform_postでレスポンスが返されることを期待するにも関わらずresponse_modeが指定されないのはどうなんだ、、、という話です。（というか世の中にあるIdP製品やサービスでresponse_type=id_tokenだけをリクエストされてform_postでレスポンスするものは存在しないと思います）
この辺はMicrosoftさんちゃんと仕様を見ようよ・・・って思いますね。。
ちなみにresponse_type=id_tokenの場合のデフォルトのresponse_modeはfragmentです。（こちらに定義されています）
https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#id_token
The default Response Mode for this Response Type is the fragment encoding and the query encoding MUST NOT be used.
気を取り直してresponse_mode=form_postの話に戻ります。response_modeは認可サーバからの認可レスポンスを返却するための方式を示すパラメータであることはわかりましたが、値にform_postが指定するというのはどう言うことなのか、についてはこちらの追加仕様に記載されています。
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
Abstractにこう記載されています。
This specification defines the Form Post Response Mode. In this mode, Authorization Response parameters are encoded as HTML form values that are auto-submitted in the User Agent, and thus are transmitted via the HTTP POST method to the Client, with the result parameters being encoded in the body using the application/x-www-form-urlencoded format.
まぁ、要するにHTML formにresponse情報を入れてredirect_uriにPOSTしますよ、ってことです。ws-federationやSAMLのHTTP POST Bindingですね。
ここでも話は横にそれますが、今でこそOAuth2.0やOpenID Connectは認可コードをリライングパーティに発行し、リライングパーティは認可サーバのTokenエンドポイントへ投げ込んでaccess_tokenやid_tokenを受け取る、いわゆるresponse_type=codeのコードフローが主流になっていますが、SAMLも当初はHTTP POSTやRedirect BindingではなくArtifact Bindingが主に使われていた時代がありました。当時はフィーチャーフォンのブラウザなど扱えるURL長に制限があったり、フロントに大きなPOSTデータを持ってくると通信量が増えてパフォーマンスに大きく影響が出るなどの問題があり、ArtifactといわれるコードをService Providerへ提供、Service ProviderがIdentity ProviderへSAMLトークンをとりにいく、という流れが必要だったためです。当時と今では事情がことなりますが、認可コードフローとのままですね。なんといってもOpenID Connectは、開発中はOpenID ABC（Artifact Binding and Connect）って名前でしたし、OpenID Connect Coreの定義をしている、OpenID FoundationのAB/ConnectワーキンググループはArtifact Binding Working GroupとConnect Working Groupから組成されており、ABはArtifact Bindingなわけです。
話を戻すと、Entra IDの外部認証プロバイダの際にも書いた通り、id_tokenとstateをformに乗せてPOSTしてあげるためのHTMLをレンダリングするコードを書けば良いってことになります。
node_expressとejsで書くとこんな感じです。
レンダリングされるhtmlテンプレートはこんな感じですね。（前回の記事では動きを見るために自動POSTしていませんでしたが、今回はJavaScriptで自動POSTする形にしています）
しかし、form_postを使っているのって実態としてMicrosoftくらいしかいないんですよね・・・（Sign In with Appleも使ってたかも）
現状、ブラウザを経由してトークンのやり取りをする、つまりArtifactや認可コードを使わないパターンを使いたい大きな理由は先ほど挙げたフィーチャーフォンのブラウザの制限や通信速度・通信量の問題というよりも、エンタープライズなどIdPがファイアウォールの内側にありリライングパーティが外側にあるというケースやWalletがIdPになるケースなど、IdPが外部からのアクセスできない（Walletの場合はエンドポイントを持たない）という問題である場合が多いと思います。
その場合は当然Implicitを使う、つまりフラグメントにトークンを入れてJSでリライングパーティへ渡す、というやり方になるわけですが、これだとリライングパーティのredirect_uriがブラウザ上でJSをハンドリングする機能を実装することが前提になってしまいます。もちろんこれができるケースならば良いのですが、リライングパーティ向けの共通ライブラリを提供しようとすると単純にバックエンドでPOSTを受け取るAPIを作っておく方が楽なんじゃないかと思います。さらに言うと、これまでws-federationやSAMLのSP向けのライブラリを提供してきたベンダであれば少しパラメータを変えれば対応できると言う意味でform_postの方がありがたかった、と言うのが実情だったんだろうなぁ、、と聞いた話から推測しています（あくまで推測です）。まぁ、SameSiteの問題もあったりしますがこの辺は各社対応してきているので現状は大丈夫だと思いますが。
ということで、今回はresponse_modeとform_postの話をしましたが、みなさんが作るIDシステムやアプリケーションのシステム配置や要件によって適切な実装をしていきましょう。
こんにちは、富士榮です。
故Craig Burtonが”SAML is Dead”という名言を放ってから永らく経つわけですが、まだまだ現役のSAMLには今でもたまに脆弱性のレポートが出てきます。
* SAML is Dead
昨日もSilver SAML Attackに関するレポートが出ていました。
非常にざっくり要約すると、以下のようなことが書かれています。
こんにちは、富士榮です。
厳密にはOpenID Connectの仕様に定義されていませんが、以前実装したPairwise識別子（PPID）に加えて匿名の識別子（Transient Identifier）をサポートしたくなるシーンが存在するので、対応を入れていきたいと思います。
その前にこれまでのおさらいです。
SAML 2.0 core仕様
https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
こんな感じのリクエストになります。
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"ForceAuthn="false"ID="a133c62aafc8dcee7a69481de5af763c4ee370494"IssueInstant="2024-01-03T03:28:40Z"Destination="https://idp.example.jp/sso/login"AssertionConsumerServiceURL="https://sp.example.com/acs"ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"Version="2.0"><saml:Issuer>https://sp.example.com/sp</saml:Issuer><saml:Subject><saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">test@example.jp</saml:NameID></saml:Subject></samlp:AuthnRequest>
HTTP/1.1 302 FoundLocation: https://server.example.com/authorize?response_type=code&scope=openid%20profile%20email&client_id=s6BhdRkqt3&state=af0ifjsldkj&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb&login_hint=test@example.jp
<ClaimsProvider>
<DisplayName>Token Issuer</DisplayName>
<TechnicalProfiles>
<!-- SAML Token Issuer technical profile -->
<TechnicalProfile Id="Saml2AssertionIssuer_SAMPLE">
<DisplayName>Token Issuer</DisplayName>
<Protocol Name="SAML2"/>
<OutputTokenFormat>SAML2</OutputTokenFormat>
<Metadata>
<Item Key="IssuerUri">https://nfpoc.b2clogin.com/nfpoc.onmicrosoft.com/B2C_1A_SI_SAML_SAMPLE</Item>
</Metadata>
<CryptographicKeys>
<Key Id="MetadataSigning" StorageReferenceId="B2C_1A_samlsampleapp"/>
<Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_samlsampleapp"/>
<Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_samlsampleapp"/>
</CryptographicKeys>
<InputClaims/>
<OutputClaims/>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer"/>
</TechnicalProfile>
<!-- Session management technical profile for SAML based tokens -->
<TechnicalProfile Id="SM-Saml-issuer">
<DisplayName>Session Management Provider</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
<RelyingParty>
<DefaultUserJourney ReferenceId="SI_SAML_SAMPLE" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="SAML2"/>
<Metadata>
<Item Key="PartnerEntity">https://nfpoccontent.blob.core.windows.net/root/aad_sp_meta.xml</Item>
<?xml version="1.0"?>
<md:EntityDescriptor
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
entityID="urn:federation:MicrosoftOnline"
validUntil="2031-12-31T00:00:00.000Z">
<md:SPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://login.microsoftonline.com/login.srf"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/login.srf" index="0"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>
<RelyingParty>
<DefaultUserJourney ReferenceId="SI_SAML_SAMPLE" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="SAML2"/>
<Metadata>
<Item Key="PartnerEntity">https://nfpoccontent.blob.core.windows.net/root/aad_sp_meta.xml</Item>
<Item Key="Saml11AttributeEncodingInfo">
<![CDATA[
<saml:AttributeStatement xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<saml:Attribute AttributeName="emailaddress" AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims">
<saml:AttributeValue>
</saml:AttributeValue>
</saml:AttributeStatement>]]></Item>
</Metadata>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
<OutputClaim ClaimTypeReferenceId="b2cmail" PartnerClaimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" />
</OutputClaims>
<SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
</TechnicalProfile>
</RelyingParty>
</TrustFrameworkPolicy>
| カスタムドメインのID連携 | B2Bの直接フェデレーション | |
|---|---|---|
| フェデレーション単位 | ドメイン単位 | ドメイン単位 |
| ユーザの管理 | あらかじめ作成が必要（Azure AD Connectでの同期など） ImmutableIdでのマッチング | あらかじめ招待が必要 メールアドレスでのマッチング |
| アプリケーションの制限 | マルチテナントでも可 また、WS-Fedでwindowstranportエンドポイントの整備などの条件を満たせばWindows 10 PCログオンも可（Webサインイン設定不要） | マルチテナントアプリは不可 当然Windows 10 PCログインには使えない |
function(accessToken, ctx, cb) {
request.get('https://graph.microsoft.com/v1.0/me', {
headers: {
'Authorization': 'Bearer ' + accessToken,
},
json: true
},
function(e, r, u) {
if (e) return cb(e);
if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));
var profile = {
user_id: u.userPrincipalName,
name: u.displayName,
email: u.mail
};
cb(null, profile);
});
}
function (user, context, callback) {
const ipaddr = require('ipaddr.js');
// 社内ネットワーク
const corp_network = "x.x.x.x/16";
// 対象のアプリケーションのclient_id
const CLIENTS_WITH_MFA = ['G SuiteのClient Id'];
// 接続元のソースIP
const current_ip = ipaddr.parse(context.request.ip);
if ((!current_ip.match(ipaddr.parseCIDR(corp_network)) && (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1))) {
context.multifactor = {
provider: 'google-authenticator',
allowRememberBrowser: false
};
}
callback(null, user, context);
}
投稿
すべてのコメント
