2024年5月14日火曜日

Entra IDの外部認証プロバイダの設定を試す(3)

こんにちは、富士榮です。

引き続きEntra IDの外部認証について見ていきます。


今回は、前回のポストに記載したハマりポイントにも記載したjwksで公開する鍵の作り方を書いておきます。

ポイントはx5cを含む形でjwkを作成〜公開すること、です。要するに証明書を含め公開することでキーチェインがわかるようにする必要があるってことですね。

今回は当然自己証明証明書を使っているので、opensslで鍵ペアの作成等を行っています。

大まかには川崎さんが公開しているこちらのQiitaと類似の手順を通ればOKですが、今回はRSAでやったのでちょっと手順も異なる部分もあります。

前提)

  • MacOSを使っています
  • opensslはMacOS標準ではなくbrew install opensslをインストールした以下のバージョンを利用する必要があります(標準版だと一部新たなパラメータに対応していないため)
    • OpenSSL 3.3.0 9 Apr 2024 (Library: OpenSSL 3.3.0 9 Apr 2024)
  • pem-jwkを使いますのでnpm installしておいてください
  • jqを使いますので同じくnpm installしておいてください
ということで鍵生成をしていきます。

まずは鍵ペアの生成をします。いきなりjwk形式で作ります。

openssl genrsa -traditional 2048 | pem-jwk > keypair.jwk

次にpemに変換します。

pem-jwk keypair.jwk > keypair.pem

公開鍵を抽出します。

openssl pkey -pubout -in keypair.pem > public.pem

証明書を作ります。CNにはissuer名を指定します。 

openssl req -x509 -key keypair.pem -subj /CN=7...省略...25.ngrok-free.app -days 3650 > certificate.pem

jwkに証明書を入れます。

CERT=$(sed /-/d certificate.pem | tr -d \\n)

jq ".+{\"x5c\":[\"$CERT\"]}" keypair.jwk > key+cert.jwk


これで出来上がったjwkをjwks_uriに入れ込んで公開します。ちなみに上記ではuseのパラメータが設定されないことがあるので必要に応じて"sig"を手動でセットしておきます。

その後、こんな感じでjwksとしてセットします。


これをkeystoreとして読み込んでjwks_uriエンドポイントで公開します。

// jwks_uriエンドポイント
router.get('/jwks_uri', async (req, res) => {
const ks = fs.readFileSync(path.resolve(__dirname, "../keys/keystoreSign.json"));
const keyStore = await jose.JWK.asKeyStore(ks.toString());
res.json(keyStore.toJSON())
});

これでEntra IDが署名検証に使える状態で鍵を公開することができました。

こんな感じです。


まぁ、雑ですが一通りの原理はわかる状態まで持っていくことができました。

あとはちゃんと外部認証プロバイダ側を実装するだけですね。 

2024年5月13日月曜日

Entra IDの外部認証プロバイダの設定を試す(2)

こんにちは、富士榮です。

前回に引き続きEntra IDの外部認証を試していきます。

こちらのドキュメントを見つつ設定をしていきますが、なかなかハマりポイントがあります。ちなみに外部認証は細かい動きを見るためにも自前のIdPを使っていきます。

ハマりポイントだけ先に書いておきます。

  • jwks_uriエンドポイントに公開するjwk(id_tokenの署名検証するための鍵)はx5cを含む必要がある
  • id_tokenのJWTヘッダのメディアタイプは大文字"JWT”を指定する必要がある(昨日のポストの通り)
  • 外部認証プロバイダのdiscoveryとjwks_uriの情報をEntra ID側がキャッシュをするので変更があっても24時間は読みにきてくれない
  • 外部認証プロバイダから返却するid_tokenの中のamrは配列で返す必要はあるが、返す値は単一である必要がある
  • response_typeはid_token、reponse_modeはform_postで認証レスポンスを返却する必要がある(まぁ、この辺はいつものMicrosoftですね)
  • 外部認証プロバイダの認可エンドポイントへ各種パラメータがPOSTされてくる(こちらは前回書いた通り)


とりあえず、こんな感じで動きます。ngrokでローカルで動かしているIdPを読みにこさせているので画面左側にtrafic inspectorを出しています。Entra IDでログインする際にリクエストが来ているのがわかります。



外部認証プロバイダの認可エンドポイントへPOSTされてくるデータなどをtrafic inspectorで確認しながら実装を進めていくのが良いと思います。

ということで、外部認証プロバイダを実装していきます。

まずは認可エンドポイントです。

こちらが認可エンドポイントへ投げ込まれてくるパラメータですので、こちらに対応する形でid_tokenを発行して返してあげれば良いはずです。

パラメータ値
scopeopenid
response_modeid_token
client_id外部認証プロバイダ側にEntra IDをRPとして登録した際のclient_idの値
redirect_urihttps://login.microsoftonline.com/common/federation/externalauthprovider
claims{"id_token":{"amr":{"essential":true,"values":["face","fido","fpt","hwk","iris","otp","tel","pop","retina","sc","sms","swk","vbm"]},"acr":{"essential":true,"values":["possessionorinherence"]}}}'
nonceEntra IDが払い出すnonceの値
id_token_hintEntra ID側で認証済みのユーザに関する情報
client-request-idEntra ID側でのトラッキングに使う識別子(サポート用)
stateEntra ID側が払い出すstateの値


最終ゴールはid_tokenを生成し、リクエスト内のstateと合わせてredirect_uriへPOSTしてあげることとなります。

こんな感じでエンドポイントを作っていきましょう。

// 認可エンドポイント(POST)
router.post("/authorize", async (req, res) => {
// Todo
// - redirect_uriが登録済みでEntra IDから提供されている規定値(https://login.microsoftonline.com/common/federation/externalauthprovider)であることの検証
// - client_idがEntra IDに割り当てたものであることの検証
// - id_token_hintの署名等の検証
// - ユーザ認証(id_token_hintに含まれるoid/tidを使ってユーザとの紐付け)
// - 認証応答を行う
// - redirect_uriへPOSTする
// - id_token
// - state : リクエストに含まれるstate(存在する場合)
// - id_tokenの中身
// - iss : idpのopenid-configurationで公開されているものと一致すること
// - aud : Entra IDに割り当てたclient_id
// - exp : 有効期限
// - iat : 発行時刻
// - sub : id_token_hintのsubと一致すること
// - nonce : リクエストに含まれるnonce
// - acr : リクエストのclaimsに含まれる値の一つと一致すること
// - amr : リクエストのclaimsに含まれる値と一致すること(配列)

結構やることはありますが、今回はまずはid_tokenを発行するところにフォーカスを当てますので、ユーザの認証や各種パラメータの検証は省略します。

id_tokenに含めるべき値にリクエスト内のid_token_hintに含まれる情報があるので、まずばid_token_hintのpayloadをデコードして値を取り出せる状態にパースします。

// とりあえずpayloadだけパースする(検証は後回し)
const id_token_hint_payload = req.body.id_token_hint.split('.');
const raw_id_token_hint = base64url.decode(id_token_hint_payload[1]);
const obj_id_token_hint = JSON.parse(raw_id_token_hint);

そしてid_tokenのpayloadを生成します。今回は検証もユーザ認証もしないので、acrやamrの値も決め打ちで設定しています。ちなみにハマりポイントにも記載した通り、amrは配列で値を設定する必要がありますが、値は単一でなければなりません。(今回はfidoを設定)

const date = new Date();

const raw_id_token = {
iss: 'https://' + req.headers.host,
aud: req.body.client_id,
exp: Math.floor((date.getTime() + (1000 * 60 * 10)) / 1000),
iat: Math.floor(date.getTime() / 1000),
sub: obj_id_token_hint.sub,
nonce: req.body.nonce,
acr: 'possessionorinherence',
amr: ['fido']
};

そして、このpayloadを署名してJWTと作ります。

const id_token = await utils.generateJWS(raw_id_token);

こちらも面倒だったので、opensslで作った秘密鍵をベタ打ちでコードに埋め込んでいますし、kidも生成したものをベタで指定しています。この辺はおいおい直します。

const jwt = require('jsonwebtoken');
const privatekey = `-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAmbjCIt20NKwMrH78TGOA8w9LS/R6B81RNHoJ/J+7UljRUfMN
sGC+RR6bqtDxeLgLjmt4s7CccbVf380DQx4b2XtCvoP0QW4GsJm7b13XkwCD6fWT
xSX5RTqXyTrLFk0ifOhRZ09QxZnAOGgUN12HeKjWj24XLQKFOROi8BhwHxLLSd+n
-- 省略 --
52EKdTgNOrVFGV/1qACGuDgLNDss+z2f2HgO/pk5UtS0EaXltv62IV6izkZh7f9O
aPXrS0BclfaGBZ0RcQIt0lJ2UMSTd8CFKX+k5efoFthX2ddWY24A
-----END RSA PRIVATE KEY-----`

exports.sign = async function(payload){
return jwt.sign(payload, privatekey, {
algorithm: "RS256",
keyid: "Vzy3LDbuzSrt0cQldElZp5R92etQvOCENEu5aOOppYs"
});
}

あとはid_tokenとstateをPOSTしてあげるだけですが、node+express+ejsを使っているのでres.renderで値をejsへ渡してあげます。

// form postするためのページをレンダリング
res.render("./form_post.ejs",
{
redirect_uri : req.body.redirect_uri,
id_token: id_token,
state: req.body.state
}
);

フォーム側はこんな感じです。実際は値はhiddenにして、JavaScriptで自動POSTするようにしますが、今回はステップバイステップで進めたかったので一旦フォームを表示するようにしています。

<html>
<body>
<div id="login_div" >
<form name="id_token" method="POST" action="<%= redirect_uri%>">
<input name="id_token" type="text" value="<%= id_token%>">
<input name="state" type="text" value="<%= state%>">
<input type="submit" value="POST">
</form>
</div>
</body>
</html>

これでうまくいけば上記の動画のように認証が完了します。

一旦、今回はここまでです。

2024年5月12日日曜日

JWTヘッダのメディアタイプの大文字・小文字問題でハマった話

こんにちは、富士榮です。

id_tokenを作るときにJWTヘッダのメディアタイプ(typパラメータ)の値として'JWT'を指定すると思いますが、この値の大文字・小文字ではまった話です。

ちなみに、こんな感じでjoseのライブラリを使ってJWTを作っていたのですが、下から2行目のオプション指定のところで{ typ: 'jwt' }という形で小文字指定をしていました。

// JWSの作成
exports.generateJWS = async function(payload) {
const ks = fs.readFileSync(path.resolve(__dirname, keyStoreFile));
const keyStore = await jose.JWK.asKeyStore(ks.toString());
const [key] = keyStore.all({ use: 'sig' });
   const opt = { compact: true, jwk: key, fields: { typ: 'jwt' } };
return jose.JWS.createSign(opt, key).update(JSON.stringify(payload)).final();
}

JWTの仕様を見る限りnot case sentisiveとあるので、その後にあるレガシー実装との互換性のために常に"JWT(大文字)"を使うことを推奨という文言を舐めていました。

If present, it is RECOMMENDED that its value be "JWT" to indicate that this object is a JWT.  While media type names are not case sensitive, it is RECOMMENDED that "JWT" always be spelled using uppercase characters for compatibility with legacy implementations.

仕様)

https://datatracker.ietf.org/doc/html/rfc7519#section-5.1


ということで、MicrosoftのRPに小文字'jwt'で作ったid_tokenを投げ込むとこんな感じで怒られます。

仕方なく、コードを修正しました。

exports.generateJWS = async function(payload) {
const ks = fs.readFileSync(path.resolve(__dirname, keyStoreFile));
const keyStore = await jose.JWK.asKeyStore(ks.toString());
const [key] = keyStore.all({ use: 'sig' });
const opt = { compact: true, jwk: key, fields: { typ: 'JWT' } };
return jose.JWS.createSign(opt, key).update(JSON.stringify(payload)).final();
}


確かに軽く他社の実装(Microsoft以外だとAuth0とかGoogleとか)を見るとちゃんと大文字になってますね。

2024年5月11日土曜日

NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む(5)

こんにちは、富士榮です。
引き続きNIST SP 800-63B-3への追補版を見ていきましょう。



今回は同期可能な認証器に関する脅威とチャレンジについてです。

Syncable Authenticator Threats and Challenges

同期可能な認証機能には、導入または展開の前に評価すべきいくつかの明確な脅威および課題がある。表3にこれらのリスクと推奨される軽減策の概要を示す。

表3. 同期可能な認証器の脅威、課題、緩和策
脅威と課題説明緩和策
鍵の不正使用または管理の喪失同期可能な認証器の中には、鍵を悪用する可能性のある他のユーザが所有するデバ イスへの秘密鍵の共有をサポートするものもある。- 同期されたキーの共有を防止するエンタープライズ・デバイス管理機能または管理されたプロファイルを強制する。
- 利用可能なすべての通知チャネルを通じて、鍵共有イベントをユーザーに通知する。
- ユーザが鍵、鍵の状態、鍵が共有されたかどうかを確認できる仕組みを提供する。
- 既存の認識およびトレーニングの仕組みを通じて、鍵の不正使用のリスクについてユー ザーを教育する。
同期ファブリックへの侵害鍵の同期をサポートするために、ほとんどの実装は、アカウントに関連付けられた複数のデバイスに接続されたクラウドベースのサービスである「同期ファブリック」に鍵をクローンする。- 暗号化された鍵マテリアルのみを保存する。
- 認証されたユーザ以外が秘密鍵にアクセスできないように、同期ファブリックのアクセス制御を実装する。
- クラウドサービスの基本的なセキュリティ機能(FISMA Moderate 保護または同等の保護など)を評価する。
- ハードウェア・セキュリティ・モジュールを活用し、暗号化鍵を保護する。
同期ファブリックへの不正アクセスと復旧同期された鍵は、クラウドベースのアカウント回復プロセスを通じてアクセスできる。これらのプロセスは、認証者にとって潜在的な弱点となる。- SP 800-63B に準拠した認証回復プロセスを導入する。
- デバイス管理またはマネージド・アカウント機能により、連邦エンタープライズ鍵の回復機能を 制限する。
- 復旧をサポートするために、AAL2 以上の複数の認証機関をバインドする。
- 同期ファブリックへのユーザ・アクセスに新しい認証者を追加する場合は、AAL2 認証を要求する。
- 連邦政府の企業シナリオでは、派生認証としてのみ使用する。
- ユーザにリカバリ活動を通知する。
- ユーザが管理する秘密鍵(シンク・ファブリック・プロバイダが知らないもの)を利用し、鍵の暗号化と回復を行う。
取消同期可能な認証器はRP固有のキーを使用するため、そのキーに基づくアクセ スを一元的に取り消すことは困難である。たとえば、従来の PKI では、CRL を使用してアクセスを一元的に取り消すことができる。同様のプロセスは、同期可能な認証器(または FIDO WebAuthn ベースの認証器)では利用できない。- ユーザが認証情報を管理するための中央 ID 管理(IDM)アカウントを導入し、認証情報が漏 洩したり失効したりした場合は、「所属機関」アカウントから認証情報を削除する。
- SSO およびフェデレーションを活用し、インシデント発生時に失効させる必要のある RP 固 有の鍵の数を制限する。
- ユーザが鍵の有効性と最新性を確認するよう定期的に要求するポリシーとツールを確立する。

ここにありましたね。同期と共有の違い。やっぱりMDMとかでコントロールするしかなさそうですね。
ちなみに次の章は共有に関して丸々一章を割いているのでやはり課題感は大きいんだと思います。

2024年5月10日金曜日

Entra IDの外部認証プロバイダの設定を試す(1)

こんにちは、富士榮です。

先日当Blogにも書いたとおり、最近Previewが公開されたEntra IDの外部認証を少しずつ試していきます。

設定はこの辺りのドキュメントを見ればできそうです。

https://learn.microsoft.com/ja-jp/entra/identity/authentication/how-to-authentication-external-method-manage


ざっとやり方と条件を見ていくと、こんな感じっぽいです。

  • Entra ID上にマルチテナントアプリとして外部認証システムをクライアント登録する
  • 外部認証システムがEntra IDが発行したid_token_hintを検証できるようにEntra IDのDiscoveryエンドポイントを解釈できるように構成する
  • 外部認証システムへEntra IDをクライアント登録する
  • 外部認証システムの認証強度の要求はclaimsパラメータを利用し、amr/acrの値が要求される。そのため外部認証システムは指定された値のamr/acrを返却できるように構成する必要がある
  • 外部認証システムの認可エンドポイントへのアクセスはPOSTで行われる
  • 外部認証システムからEntra IDへのid_tokenの引渡しはform_postを使う必要がある

まだ細かいところは色々とありますが、やりながら潰していきましょう。

しかしまぁ、結構条件厳しめですね。やはり自作IdPをカスタマイズしつつ対応させていくのが良さそうです。


と言うことで徐々に試します。今回は外部認証システムへ認証要求が飛ぶところまでを見ていきます。

マルチテナントアプリの登録

まずはEntra IDに外部認証システムを登録してあげる必要があります。ログイン前に参照することが必要になる、かつ他のマルチテナントアプリに対して認証する可能性があることから、外部認証システム自体の登録もマルチテナントアプリとしてクライアント登録を行います。

この際、redirect_uriには外部認証システムの認可エンドポイントのURLを指定する必要があります。

次に、APIアクセス許可を行います。

Microsoft Graphへのアクセス許可をする(委任されたアクセス許可)必要があります。

対象の権限にはopenidとprofileを指定します。

管理者の同意を付与しておきます。


外部認証の設定を行う

いよいよ外部認証システムの登録を行います。
  • 名前は適当でも良いのですが後から変えられないので注意が必要です。
  • クライアントIDは外部認証システム側にEntra IDを登録する際に発行されるクライアントIDを指定します。(次回以降で外部認証システム側への登録の話をします)
  • 検出エンドポイントには外部認証システムのdiscoveryエンドポイントを指定します。
  • アプリIDは先ほどEntra ID上に登録したマルチテナントアプリのクライアントIDを指定します。

また、この認証方式を使うことができるユーザが所属するグループを指定し、設定を有効にして保存します。

動作を確認する

この状態でユーザでログインをする際に多要素認証が求められるように設定しておくと、認証方式として先ほど指定した方式が出てきます。(出てこない場合はMicrosoft Authenticatorが現在使えない、というリンクをクリックすると出てきます)

こちらを選択すると、外部認証システムへリダイレクトされるのですが、トレーサーでリクエストを見ると以下のように認可エンドポイントへPOSTでid_tokenやclaimsを含んだリクエストが飛んでいることがわかります。

id_token_hintを紐解くとこんな感じです。

おすすめは外部認証システム側にoid(オブジェクトID)とtid(テナントID)を紐づけた形でユーザを作成しておき、当該のユーザで認証することです。(preferred_usernameだと変わってしまう可能性があるので)

また、認証方式・強度などに関する要求はclaimsパラメータで指定がされていますので、外部認証システムはこの条件を満たす形で認証を行い、id_tokenのacr/amrに値を含めてEntra IDへ送出してあげる必要があります。 

{
"claims": {
"id_token": {
"amr": {
"essential": true,
"values": [
"face",
"fido",
"fpt",
"hwk",
"iris",
"otp",
"tel",
"pop",
"retina",
"sc",
"sms",
"swk",
"vbm"
]
},
"acr": {
"essential": true,
"values": [
"possessionorinherence"
]
}
}
}
}

次回以降は外部認証システム側の設定を調整していきたいと思います。

 



2024年5月9日木曜日

NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む(4)

こんにちは、富士榮です。

引き続きNIST SP800-63B-3の同期可能な認証器に関する追補版についてみていきましょう。


今回は実際にインプリメンテーションを行う場合の考慮事項や要求事項についてです。

Implementation Considerations and Requirements

同期可能な認証器は、W3CのWebAuthn仕様に基づいて構築されており、共通のデータ構造、チャレンジ・レスポンス暗号プロトコル、公開鍵認証情報を活用するためのAPIを提供している。この仕様は柔軟で適応性があるため、WebAuthnクレデンシャルのすべてのデプロイが連邦政府機関の実装要件を満たすとは限らない。
この仕様には一連の「フラグ」があり、依拠当事者(RP)アプリケーションは、認証イベ ントの追加コンテキストを提供し、それが RPのアクセス・ポリシーに適合するかどうかを判断す るために、認証者に要求することができる。本節では、RPとして活動する連邦機関が、NIST AAL2 脅威緩和策に適合する同期可能な認証器の実装を構築する際に理解し、問い合わせる必要がある、WebAuthn仕様の特定のフラグについて 説明する。

表2, WebAuthn Level 3 flags
フラグ説明要求事項と推奨事項
User Present(UP)ユーザが認証器と対話したことを確認するための「プレゼンス」テストを示す(例:USBポートに挿入されたハードウェアトークンのタッピング)。連邦機関は、ユーザ提示フラグが設定されていることを確認しなければならない(SHALL)。認証意図をサポートする。
User Verified(UV)利用可能な「ユーザー検証」メソッドのいずれかを使用して、ユーザーが認証者によってローカル認証されたことを示す。連邦機関は、UV が優先されることを示さなければならず(SHALL)、すべてのアサーションは、UV フラグの値を確認するために検査されなければならない(SHALL)。これは、認証器が多要素暗号認証器として扱えるかどうかを示す。ユーザが検証されない場合、機関は、認証イベントに RP 固有の暗記秘密を追加することで、認証器を1要素暗号認証器として扱うことができる。WebAuthn レベル 3 仕様のさらなる拡張により、機関がローカル認証イベントのコンテキストを得ようとする場合、検証方法に関する追加データが提供される。
Backup Eligibility認証器を別のデバイスに同期できるかどうか(すなわち、鍵を別の場所に保存できるかどうか)を示す。同期可能だからといって、同期済みであることを意味しないことに注意。連邦機関は、同期可能な認証器の使用を制限するポリシーを確立する場合、このフラグを使用してもよい。このフラグは、デバイスにバインドされる認証子と、複数のデバイスにクローンされる 認証子を区別するために必要である。
Backup State認証器が別のデバイスに同期されたかどうかを示す。連邦機関は、他のデバイスに同期された認証器に対する制限を確立する場合、このフラグを使用してもよい。公開アプリケーションの場合、連邦政府機関は、ユーザエクスペリエンス上の懸念から、このフラグに基づいて受諾を変更すべきではない(SHOULD NOT)。企業の判断のために、このフラグは、特定のアプリケーションのために同期可能な 認証器の制限をサポートするために使用してもよい[MAY]。

以前パスキー対応の認証機能を実装した際にも出てきたフラグですね。

https://idmlab.eidentity.jp/2024/02/api.html

同期可能かどうかの判断にはBEやBSを使うわけです。アプリによってはこのフラグを見て同期可能な認証器を受け入れるかどうかを決める、と言うことです。

 

表2に示されるフラグに加えて、機関は、実装および受け入れを選択する同期可能な認証器のオリジンおよび機能について、より詳細な情報を得ることを望むかもしれない。FIDO2 WebAuthn のコンテキストにおいて、認証者の中には、特定の認証者の能力および製造者を 判断するために使用できる認証機能をサポートしているものがある。企業ユースケースの場合、各機関は、プラットフォームプロバイダが提供する機能に基づいて、認証機能を実装するべきである(SHOULD)。好ましくは、RP が認証器に関する一意の識別情報を要求するエンタープライズ認証の形をとる。

構成証明(Attestation)は、広範な公衆向けアプリケーションに使用すべきではない(SHOULD NOT)。このような要件(すなわち、構成証明に対応していない場合、一部の一般ユーザの同期可能な認証器をブロックする要件)は、ユーザをショートメッセージサービス(SMS)のワンタイムパスワード(OTP)のような、フィッシングに脆弱な安全性の低い認証オプションに誘導する可能性がある。

この視点は面白いですね。パブリック(共有端末とかのイメージかな?)なアプリケーションで同期可能な認証器を使うとってしまうまずいので同期可能なクレデンシャルをブロックすると言うポリシーを適用すると、手軽な認証手段を実装しがちになる、という話でしょうか?(@Shiroicaさんご指摘ありがとうございます)


RP がフラグおよび認証データを要求しても、認証器は要求された情報をすべて返さないかもしれないし、リソースへのアクセスに要求される期待応答と矛盾する情報を返すかもしれない。したがって、各機関は、同期可能な認証器を使用するユースケースを評価し、返された情報に基づいて適切なアクセスポリシー決定を行うことが決定的に重要である。
こちらも現実論として全ての認証器がちゃんとフラグを返してくるということは期待してはいけない、ちゃんとリスクを含め評価をしてポリシーを決めようね、ということです。これ非常に大事だと思います。


ということでまだ続きますが、今回はここまでです。

2024年5月8日水曜日

Entra IDの外部認証プロバイダの利用機能がPreview公開されています



Entra IDで外部の認証手段が使えるようになったようです。

むかーし、3rdパーティの多要素認証プロバイダの設定を行う機能が一瞬出て消えていったものの後継ですね。当時はPremium P2ライセンスが必要でDuoやRSA、Trusonaなどプリセットされたものを認証プロバイダとして利用することができました。
当時の記録

まぁ、中身はid_token_hintを使ってIdPをチェインさせているだけだった気がしますが、当時はあんまり流行らなかったんですかね・・・。

今回のアナウンスとドキュメントを見ているとやはりid_token_hintを使った認証状態の引き回しとチェインであることには変わらなさそうですが、より柔軟に構成を行うことができるようになっていますね。ライセンスもPremium P1でOKっぽいですし。

ということで私のテナントでも機能が有効になったのでおいおい試してみたいと思います。