OpenID Connectの脇役たち

本記事は Digital Identity技術勉強会 #iddance Advent Calendar 2020 17日目の記事です。

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

今日は年末ということもあり、普段はあまり表舞台に出てこないOpenID ConnectのOptionalなオプションにフォーカスを当ててみようかと思います。

対象とする仕様は「OpenID Connect Core 1.0」とします。

• 日本語訳（By OpenIDファウンデーションジャパン翻訳・教育WG）
• http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html
• オリジナル
• https://openid.net/specs/openid-connect-core-1_0.html

OpenID Connectの設計思想

OpenID ConnectはいわゆるID連携（Federation）を行うための仕様として、OAuth2.0の上位にアイデンティティ層を載せる形で定義されています。

そして、その設計思想は、

• 簡単なことは簡単に
• 難しいことも可能に
• モジュラーデザイン

という原則に則っています。

この中の最初の原則である「簡単なことは簡単に」という部分が普段みなさんが使っているOpenID Connectを使ったログオンの実装の大半で、上記の仕様の第2章「Authentication」に定義されているAuthorization code flow、Implicit flow、Hybrid flowの3つ、特にAuthorization code flowを覚えておけば基本的なWebアプリケーションへのログインのシナリオでは何も難しいことはありません。

※当然、セキュリティ上の考慮事項などはそれなりに存在するため、stateやnonceを正しく使ってcodeを横取りされたりid_tokenを使いまわされることを防いだりする必要はありますので運用環境で使うためにはちゃんと仕様を理解して実装する必要はありますが。。。

また、2つ目の「難しいことも簡単に」、3つ目の「モジュラーデザイン」の原則の通り、OpenID Connect DiscoveryやOpenID Connect Dynamic Client Registrationなど関連仕様との組み合わせでより高度なシナリオにも対応することができるようになっています。

今回はニッチを狙いますので、OPTIONALなパラメータを重点的に見ていきたいと思います。

RFCにおける要求レベルの定義

仕様を読んでいるとMUST、SHOULD、MAY、OPTIONALなど各パラメータ毎に要求レベルが定義されています。

この要求レベル自体はRFC2119で以下の通り定義されています。

※RFC2119の日本語訳はIPAのホームページで公開されています。

以下、IPAの日本語訳です（赤字・太字は筆者）。

1. 「しなければならない（ MUST ）」 
• この語句、もしくは「要求されている（ REQUIRED ）」および「することになる（ SHALL ）」は、その規定が当該仕様の絶対的な 要請事項であることを意味します。
2. 「してはならない（ MUST NOT ）」
• この語句、もしくは「することはない（ SHALL NOT ）」は、その規定が当該仕様の絶対的な禁止事項であることを意味します。
3. 「する必要がある（ SHOULD ）」
• この語句もしくは「推奨される（ RECOMMENDED ）」という形容表現は、 特定の状況下では、特定の項目を無視する正当な理由が存在するかもしれませんが、 異なる選択をする前に、当該項目の示唆するところを十分に理解し、 慎重に重要性を判断しなければならない、ということを意味します。
4. 「しないほうがよい（ SHOULD NOT ）」 
• この語句もしくは「推奨されない（ NOT RECOMENDED ）」という形容表現は、 特定の動作が容認できる、ないし、非常に有用である、というような 特定の状況下では、正当な理由が存在するかもしれませんが、 このレベルの動作を実装する前に、当該項目の示唆するところを十分に理解し、慎重に重要性を判断しなければならない、ということを意味します。
5. 「してもよい（ MAY ）」 
• この語句、もしくは「選択できる（ OPTIONAL ）」という形容表現は、ある要素が、まさに選択的であることを意味します。 その要素を求めている特定の市場があるから、あるいは、 他のベンダーはその要素を提供しないだろうが、その製品機能を拡張する と察知して、その要素を含む選択をするベンダーがあるかもしれません。 特定の選択事項（オプション）を含まない実装は、おそらく機能的には劣る ことになるでしょうが、そのオプションを含む他の実装との相互運用に備えなければなりません（ MUST ）。 同様に、特定のオプションを含む実装は、そのオプションを含まない実装 との相互運用に備えなければなりません（ MUST ）。（当然ながら、そのオプションが提供する機能は除かれます。）

まさに今回のターゲットはMAY、もしくはOPTIONALな部分です。

MAYとOPTIONALを仕様から抽出する

早速、仕様の中にどのくらいMAYとOPTIONALがあるのか抽出してみます。

• MAY：87個
• OPTIONAL：53個

・・・結構ありますね。

全部カバーしているとキリがないので、独断と偏見でMAY/OPTIONALを5個選んで番付的に紹介してみようと思います。

※もちろんOPTIONALなので実装しているOpenID Providerばかりではありませんので、動かしてみても期待する反応がえられないケースが多いので悪しからず。

十両：prompt

認証リクエストにpromptパラメータを付加することで再認証や同意を求めることができます。

仕様では3.1.2.1のAuthentication Requestの項に定義されています。（OpenIDファウンデーションジャパンの日本語訳から引用）

OPTIONAL. Authorization Server が End-User に再認証および同意を再度要求するかどうか指定するための, スペース区切りの ASCII 文字列のリスト. 以下の値が定義されている.

none

Authorization Server はいかなる認証および同意 UI をも表示してはならない (MUST NOT). End-User が認証済でない場合, Client が要求する Claim 取得に十分な事前同意を取得済でない場合, またはリクエストを処理するために必要な何らかの条件を満たさない場合には, エラーが返される. 典型的なエラーコードは login_required, interaction_required であり, その他のコードは Section 3.1.2.6 で定義されている. これは既存の認証と同意の両方, またはいずれかを確認する方法として使用できる.

login

Authorization Server は End-User を再認証するべきである (SHOULD). 再認証が不可能な場合はエラーを返す (MUST). 典型的なエラーコードは login_required である.

consent

Authorization Server は Client にレスポンスを返す前に End-User に同意を要求するべきである (SHOULD). 同意要求が不可能な場合はエラーを返す (MUST). 典型的なエラーコードは consent_required である.

select_account

Authorization Server は End-User にアカウント選択を促すべきである (SHOULD). この prompt 値は, End-User が Authorization Server 上に複数アカウントを持っているとき, 現在のセッションに紐づくアカウントの中から一つを選択することを可能にする. End-User によるアカウント選択が不可能な場合はエラーを返す (MUST). 典型的なエラーコードは account_selection_required である.

prompt パラメータは Client に対して, End-User のセッションがアクティブであることを確認したり, End-User にリクエストに対する注意を促すことを可能にする. none がその他の値とともに用いられる場合はエラーとなる.

アプリの仕様でトランザクションの種類によって強制再認証を求めたり、同意を求めたりするケースもあると思うので、そのような場合はうまくpromptパラメータを使うと良いですね。

前頭：target_link_uri

SAMLでいうrelayStateですね。

仕様にも記載がありますが、全てのログインフローがRelying PartyからOPへのリクエストによって始まるわけではなく、OP起点だったり別のシステム（ポータルなど）から起動されることもあります。そのような場合、ログインフローを起動するシステムはRPのログイン開始エンドポイントへユーザをリダイレクトしてフローを起動するわけですが、ログインが完了した後、必ずしもRPのデフォルトのランディングページに着地させたいわけではなく、別のページへ飛ばしたい、というケースもあります。そのような場合にtarget_link_uriに指定するとログイン完了後に望むページへ遷移させることができます。

ただ、注意点として記載がある通りOpenリダイレクタにならないように指定できるURLはきちんと検証しないといけません。

仕様では4のInitiating Login from a Third Partyの項に定義されています。（OpenIDファウンデーションジャパンの日本語訳から引用）

target_link_uri

OPTIONAL. 認証後, RP がリダイレクトするよう要求された URL. RP は外部サイトへのオープンリダイレクターとして使用されることを防ぐために target_link_uri の値を検証しなければならない(MUST).

SAMLを使ったシステム導入の際はrelayStateに関する要望は結構あったので、今後このパラメータもメジャーになってくるかな？と思います。

関脇：request/request_uri

いわゆるRequest Objectです。FAPI Part2では認可要求自体への署名が要求されるので、普通にQuery Stringに各種リクエストパラメータをくっつけるのではなく、JWTとして認可サーバへ渡してあげる必要があります。また認可要求にJWTそのものを渡すこともできますが、request_uriに指定したエンドポイントを参照させることによりリクエストパラメータを取りに来てもらうこともできます。

仕様では6のPassing Request Parameters as JWTsの項に定義されています。（OpenIDファウンデーションジャパンの日本語訳から引用）

request

OPTIONAL. このパラメータにより, OpenID Connect リクエストを単一の self-contained なパラメータとすることができ, 任意で署名および暗号化を施せるようになる. パラメータ値は Request Object 値である (Section 6.1 参照). Request Object は, 各 Claim がリクエストパラメータとなる JWT である.

request_uri

OPTIONAL. このパラメータにより, 値そのものではなく参照を送ることが可能になる. request_uri 値は https スキーマで始まる URL であり, Request Object 値を含むリソースへの参照となる. 参照先の Request Object は, リクエストパラメータを含む JWT である.

金融サービスに限らず要求についても隠蔽したいケースや署名をつけて確実に渡したいケースではこのパラメータは活躍する場面がありそうです。

大関：id_token_hint

完全に個人的な趣味です。実はAzure ADを使っていると結構活躍の機会が多いんです。例えば今はもう新規のサポートは受け付けていませんがPremium P2の機能のカスタムMFAプロバイダへのセッション引き継ぎはid_token_hintを使って行っていましたし、そもそもOffice365→Azure AD→外部IdPというようなチェーン構成のフェデレーションでは前段で入力されたユーザ名のドメインパートに基づきログイン先のIdPを動的に変更する、なんということもよくやります。そのようなケースでは前段のIdPでのユーザの挙動（入力した値や、その値から導き出された値など）を連鎖する後段のIdPにも伝えないと、ユーザ名を2回入力する必要が出てきたり、とUXを毀損してしまいがちです。

このようなケースではid_token_hintの中に必要なパラメータを詰め込んで後段のIdPへJWTとして渡してあげることで格段にUXが向上します。

(Office365のケースではOpenID Connect→ws-federationの連鎖なのでusernameというパラメータを使っていますが）

仕様では3.1.2.1のAuthentication Requestの項に定義されています。（OpenIDファウンデーションジャパンの日本語訳から引用）

id_token_hint

OPTIONAL. Authorization Server が以前発行した ID Token. Client が認証した End-User の現在もしくは過去のセッションに関するヒントとして利用される. もしこの ID Token に紐づく End-User が認証済, もしくはこのリクエスト中で認証された場合, Authorization Server はポジティブレスポンスを返す. さもなければ, Authorization Server は login_required のようなエラーを返す (SHOULD). prompt=none を利用する場合は, 可能であれば id_token_hint を指定するべきであり (SHOULD), さもなければ invalid_request を返しても良い (MAY). ただしサーバーはその場合可能な限りサクセスレスポンスを返すこと. id_token_hint 利用時は, ID Token の audience に Authorization Server 自身が含まれている必要はない.

id_token_hint として使用するために RP によって受信された OP からの ID Token が暗号化されていた場合, クライアントは暗号化された ID Token を含んだ署名済みの ID Token を復号しなければならない (MUST). クライアントは Authentication Server に送信する署名済みの ID Token をサーバーが ID Token を復号できる鍵を用いて再暗号化し, id_token_hint の値として使用してもよい (MAY).

横綱：claims

最後の横綱級はなんといってもclaimsでしょう。理由はシンプルで私も共同議長を勤めさせていただいるOpenID FoundationのeKYC and Identity Assurance WGで策定中のOpenID Connect for Identity Assuranceの仕様はclaimsがあるから成り立っている、といっても過言ではないからです。

パラメータの意味合いとしてはRPからOPへの認証要求時にclaimsに指定した属性をid_tokenもしくはuserInfoとして提供することを明示的に求める、というものです。OpenID Connect for Identity Assuranceではこの機能を拡張してRPがOPに検証済みの属性を要求する、ということを実現しています。

仕様では5.5のRequesting Claims using the "claims" Request Parameterの項に定義されています。（OpenIDファウンデーションジャパンの日本語訳から引用）

claims

OPTIONAL. 当パラメータは, 特定の Claim の返却を要求するのに用いられる. 値は要求する Claim をリスト化した JSON オブジェクトである.

claims Authentication Request パラメータは, 特定の Claim を UserInfo Endpoint から, かつ/または ID Token 内で, 返却することを要求する. これは要求する Claim のリストを含む JSON オブジェクトとして表される. 要求する Claim のプロパティが指定されていてもよい (MAY).

claims パラメータのサポートは任意である (OPTIONAL). 当パラメータをサポートしない OP に対して RP が当パラメータを使用したとき, OP は 適切と思われるヒューリスティックな方法を用いて, RP と End-User にとって有益と思われる Claim のセットを返すべきである (SHOULD). Discovery で得られる claims_parameter_supported は, OP が当パラメータをサポートしているかどうかを示す.

claims パラメータ値は, OAuth 2.0 要求の中で, UTF-8 でエンコードされた JSON として表される (最終的には OAuth パラメータとして受け渡されるときに form-urlencoded される). Request Object 値として使用される際は, Section 6.1 により, JSON が claims メンバーの値として使用される.

Claim 要求 JSON オブジェクトのトップレベルメンバーは以下の通り:

userinfo

OPTIONAL. UserInfo Endpoint へ返却を要求する個々の Claim のリストを示す. 当メンバーが存在した場合, scope 値で要求された Claim に加え, 当メンバーでリストされた Claim も返却される. 当メンバーが存在しなかった場合, scope 値で要求された Claim のみが返却される.

userinfo メンバーを指定する際は, UserInfo Endpoint を使用するために, response_type に対し, Access Token を Client に発行するタイプの値を指定しなければならない (MUST).

id_token

OPTIONAL. ID Token 内に格納して返却を要求する個々の Claim のリストを示す. 当メンバーが存在した場合, デフォルトの Claim に加え, 当メンバーでリストされた Claim も返却される. 当メンバーが存在しなかった場合, デフォルトの Claim のみが返却される. デフォルトの Claim 等の ID Token の定義については Section 2を, フロー毎の ID Token 要件については Section 3.1.3.6, 3.2.2.10, 3.3.2.11, 3.3.3.6 を参照すること.

上記以外のメンバーが存在してもよい (MAY). 認識できないメンバーが使用された場合は無視しなければならない (MUST).

通常のOPでclaimsを利用している実装ってあまり見かけないのですが、先日某芸能事務所のファンクラブサイトに娘がログインするところをトレースしていたらclaimsを使っているのが判明し驚愕しました(w)

ちなみになぜclaimsを使っているのかはよくわかりません。。。自前RPと自前OPのはずなのでこんなことをしなくてもOPが必要な属性をid_tokenやuserInfoに入れて返してあげれば済むと思うのですが・・・

いかがでしたか？

他にもご紹介したいニッチなパラメータもいっぱいあるので、また機会があればご紹介できればと思います。

Universal ResolverでIONのDIDを解決可能に

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

永らくMicrosoftの提供するION（アイオン）のDID Method、did:ionはUniversal Resolverでは解決できず、Microsoftが提供するリゾルバ（discover.did.microsoft.com）を使うしかありませんでした。

参考）DIDリゾルバあれこれ

今回、Universal ResolverのレポジトリにIONサポートのコードがマージされたことで、did:ionの解決ができるようになりました。

https://github.com/decentralized-identity/universal-resolver/pull/154

早速、レポジトリをcloneして試してみましょう。

手順はREADME.mdにある通り、

git clone https://github.com/decentralized-identity/universal-resolver
cd universal-resolver/
docker-compose -f docker-compose.yml pull
docker-compose -f docker-compose.yml up

とするだけです。

面倒ならhttps://dev.uniresolver.io/を使うのも良いと思います。

ローカルにデプロイしたUniversal ResolverとMicrosoftがホストしているリゾルバ、dev.uniresolver.ioそれぞれでテスト用のdidを解決してみました。

■ローカル

http://localhost:8080/1.0/identifiers/did:ion:xxxxxxxxxxxxxxxx

■Microsoftのリゾルバ

https://beta.discover.did.microsoft.com/1.0/identifiers/did:ion:xxxxxxxxxxx

■dev.uniresolver.io

まぁ、当たり前に解決できます。

ただ、MicrosoftのVerifiable Credentialsサービス経由で発行したdidは今のところローカルにデプロイしたdid driverでは何故か解決できませんでした。Microsoftのdiscoverサービスやuniresolver.ioだと解決できるので、まだコードに差分があるのかもしれません。

引き続き要ウォッチです。

Microsoft IgniteでのDID/VC関連トピックス

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

先週のオンライン開催されたMicrosoft IgniteではAzure Active Directoryを始めとするアイデンティティ関連のトピックスや新機能発表が色々とありました。

個人的に気になったのは、

• Identity ProtectionがAzure AD B2Cにもきた
• 条件付きアクセスがGraph API経由で触れる様になった
• ヘッダ認証が使える様になった
• VC関係の近況と退役軍人向けの教育プログラムへの適用事例

の4点です。

1点目は先日Blogにも書いた通り、今後のB2C向けサービスの幅が非常に広がる話ですし、2点目はリスクイベントを拾ってTeamsなど外部サービスに連携させるデモなどもあり運用面で非常に有用だと思いました。また3点目は以前Ping Access連携で実現していたことがMS純正でできる様になる、というところでレガシーアプリケーションへの適用の面では非常に有用だと思います。

そして、最後が本日のメインであるDID/VC関係の近況です。

* DID : Decentralized Identifier

* VC : Verifiable Credentials

こちらも以前ブログに書きましたが、その後ブラッシュアップされてきているもです。

※この辺のキーワード（含む自己主権型アイデンティティ/SSI）の使い方は間違って使われているケースが散見される（Decentralized Identityとか）たり、＝ブロックチェーンみたいな誤解もあるみたいなのでどこかでちゃんとまとめないとな、、、と。この辺りのスライドを書いてから、自分の理解も進んだのと標準化の方向性も進捗してるのでどこかでUpdateします。。。

話がそれましたが、早速Igniteでのトピックスを追いかけてみましょう。

VC関係の話が取り上げられたのはキーノートを含む以下の4つのセッションです。

• Satya Nadellaのキーノート：Building Digital Resilience
• Vasu Jakkalのキーノート：Achieve resilience with Security, Compliance, and Identity
• Joy Chikのキーノート：Azure Active Directory vision and roadmap to help you secure remote access
• Microsoft Mechanicsセッション：Taking identity and privacy to a new level | Verifiable credentials with decentralized identity using blockchain

全体を簡単に要約すると、

• VCを使うとVerifier（学校とか企業とか）が各種証明（学歴、職歴など）を簡単・確実に検証できるよ
• VerifierがSubject（個人）の情報を一生懸命集める事によるプライバシー上の懸念もなくなるよ
• すでに米国の退役軍人向けの教育プログラム（MILGears）で実証実験が走ってるよ
• 今はプライベートプレビューだけど、もうすぐみんな使える様になるぞ！
• VCをLinkedInのプロファイルに追加できるなるぞ！

みたいな話でした。

ざっくりみていきましょう。

まずはSatyaのキーノートです。後半54分あたりからDecentralized Identity Systemの話が出てきます。

私たちはオープンな分散型アイデンティティシステムを作り上げようとしています。そしてそれは、どんな中央集権的なオーソリティやテック企業からも独立しています。すでに退役軍人向けの教育プログラムでパイロットをしています。

彼らは自身の検証済みの記録をスマートフォン上のWalletに保管することができ、大学や企業に直接提示することができます。大学はそれ（VC）を数秒で検証することができ、センシティブなデータを保管する必要はありません。また退役軍人たちは、VCをLinkedInのプロファイルに追加することができ、新たな職業を得る機会に役立つでしょう。

次はVasuのキーノートです。途中16分すぎから出てくるIrinaのパートでIdentityの話があり、17分過ぎから分散型アイデンティティの話です。

オンライン化に伴いデジタル信頼やプライバシーはとっても重要なものになっています。しかし現在私たちはアイデンティティをデジタルに検証する仕組みを持っておらず、またデジタル・プライバシーは私たちのコントロール外となっています。私たちがパーソナルデータをオンラインで共有する際、企業・組織は記載されている目的外には利用せず、許可なく共有することはないことを約束し、それらのパーソナルデータが盗まれない様に、誤用されない様に保護する努力をします。マイクロソフトはすべての人々が自身のアイデンティティをコントロールできる様にする必要があると考えています。アイデンティティはどんな組織やテック企業からも独立しているべきなのです。これが私たちが分散型アイデンティティ分野に投資する理由であり、すべての人が自身のデジタルアイデンティティを所有し、誰が何の目的でいつアクセスできるか決定できるべきだと考えています。

年齢、学歴、職歴、クレジットスコア、生体情報は利用者自身のコントロール配下におかれ、政府や大学や企業の様なサードパーティはそれらの情報を検証できる様になります。それらすべてのクレデンシャルはデジタル・カードの様な形でMicrosoft Authenticatorの様なデジタル・ウォレットに保存されます。

私たちはVerifiable CredentialsとDecentralized Identifiersに関するオープンな標準に基づく自己主権型アイデンティティのヴィジョンを現実のものとするため、Decentralized Identity Foundationと共に活動しています。

私たちはこの分散型アイデンティティのシステムを多くの顧客と共にパイロットしており、MILGearsの教育プログラムもその一つです。 

ここでMilGearの人のインタビュー動画が流れた後、VasuがIrinaに今のステータスと今後どうなるの？って聞いてくれます（Good Job！）。「We're currently in private preview, but soon anyone will be able to try it.」素晴らしい！

次はおなじみJoyです。19分くらいから分散型アイデンティティ関係の話が始まります。

我々が物理的な世界で行ってきたパスポートや学位やその他証明書のやりとりをデジタル化するにはどうすれば良いのでしょうか？私たちはデジタルにそれらのクレデンシャルを検証するメカニズムが必要です。しかし今日私たちが持っているシステムはデータ漏洩や誤用で溢れています。私たちは分散型アイデンティティシステムとVerifiable Credentialsが解決策になると信じています。コミュニティの努力とオープンな標準をベースに構成され、既存のアイデンティティシステムと簡単に接続することが可能です。それはオープンな標準技術を用いており、マイクロソフトを含むどんな組織も支配することはできません。そして、それはすでに現実のものとなっているのです。

ここでやはりMILGearsの事例の話。どこにVerifiable Credentialsを提示したのか確認することができます。

退役後、大学や企業に就職する際に、軍がIssuerとなってそれまでの学歴や経歴を証明する、という形態の様ですね。

退役後、高等教育や企業への就職する際、大学や企業は学歴や軍でのトレーニング履歴にアクセスする方法がありませんでした。そのため、彼らは証明書などのドキュメントを収集し確認する長いプロセスを必要としていました。そして、多くの場合、それらのプロセスは紙をベースとしており、数ヶ月を要することもありました。

このプロセスをデジタル化することにより、彼らの待ち時間を減らすだけでなく、自身のデータに関するコントロールを行うことができる様になりました。大学がデータを収集し、保管し、保護する必要がなくなったのです。

ここでMILGearsのデモです。ここでMILGearsが保持している記録をVerifiable Credentialsとして発行します。

QRコードが表示されるのでMicrosoft Authenticatorで読み込むとカードの形でVerifiable CredentialsがAuthenticator上に追加されます。

次は大学にVerifiable Credentialsを提示します。こちらもQRコードを読み込むとVerifiable Credentialsが提示され、検証済みのデータとして大学側へ連携されます。

デモに続いてテクニカルな話をMelanieさんから。必要なのはAzure Active Directoryサブスクリプション（正確にはPremium P1以上）とKeyVaultだけ（こちらも正確にはStorageは必要）。やるべきことはたった3つ。KeyVaultでキーペアの作成をする、Rulesファイルを作る、Displayファイルを作る、とってもシンプルでしょ、的なデモです。

こちら、Rulesファイルですね。まぁ、確かに簡単な構造のjsonです。

こちらはDisplayファイル。こちらも非常にシンプルなjsonファイル。Authenticatorに表示されるカードのロゴとか色を決める感じですね。

というところでJoyのキーノートは終了です。

最後はMicrosoft Mechanicsですが、こちらも結局Joyががっつり話をします。

中身的には、W3Cの標準をちゃんとみてるよ、という話とこれまであったMILGearsの事例、KeyVault、RulesとDisplayなど実装にかかる話のおさらい的な感じのセッションです。

MILGearsの事例をベースにIssuer=MILGears/Subject（Holder）=退役軍人/Verifier=大学など、と関係性を解説してくれています。わかりやすい。

ブロックチェーンとの関係も最後に少しだけ触れられます。基本的にDID Documentと公開鍵の置き場所として使ってるだけです。

全体的にまだ詳しいところは触れられない感じでしたが、こうして動いている姿を見ることができると非常に面白いですね。MILGearsのケースも非常に面白いと思います。退役軍人っていうともっと年寄りでそのまま隠居する？ってイメージでしたが結構若い間に退役して、その後大学に行ったり企業に就職したりするケースもあり、その場合に身元保証を軍がやる、というのは日本にいるとあまりイメージが湧きにくいとは思いますが、話を聞いてみると納得、という非常に良いユースケースだと思います。

DID/VCはとても面白いテクノロジだとは思いますし、可能性も感じますが、別にDID/VCじゃなくても良いじゃん、というケースばかりなので今後DID/VCならではのユースケースがもっと研究されると良いな、というのが全体的な感想でした。

Azure Identity Protection for B2CがPublic Preview

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

ずっと出ると言われていて待っていたAzure Identity Protection（リスク判定と条件付きアクセス）のAzure AD B2C対応版がようやくPublic Previewになりました。

公式Blogでのアナウンス

　Azure Active Directory External Identities goes premium with advanced security for B2C

　https://techcommunity.microsoft.com/t5/azure-active-directory-identity/azure-active-directory-external-identities-goes-premium-with/ba-p/1604572

ポイントをまとめるとこんな感じです。

• Identity Protection
• 基本は普通のAzure AD版のIdentity Protectionのサブセット
• 以下の制限あり
• B2Cテナントでのセキュリティ・センターは使えない
• ROPCフローでは使えない
• ローカルアカウントでしか使えない
• 条件付きアクセス
• 基本は普通のAzure AD版の条件付きアクセスのサブセット
• 以下の制限あり
• デバイス状態をベースとして条件判定は使えない（設定はできちゃいますが）
• ビルトインのユーザ・フローでもカスタム・ポリシーでも使える
• ライセンス
• Premium P2 Tierが必要

一番気になるP2ライセンスの価格表ですが、月間アクティブユーザー課金で通常の利用料＋1.8円程度かかるみたいですね。（契約形態などにも依存するはずなので正確にはちゃんと調べてくださいね）

https://azure.microsoft.com/en-us/pricing/details/active-directory/external-identities/

徐々に全テナントにロールアウトされるみたいですが、私のテナントではすでに使えているのでFirst Lookをとりあえず。

何はともあれPricing TierをPremium P2へ。

ビルトインフローは面倒なのでカスタム・ポリシーで。

基本的な考え方としては、①リスク評価をして、②結果によっては多要素認証などによりユーザに対応をさせて、③結果OKであればリスクを緩和する、というプロセスでUserJourneyを汲みます。

全部は紹介しませんが、とりあえずこんな感じですね。

ConditionalAccessProtocolProviderを使ったTechnicalProfileを作ってOperationTypeでリスク評価なのか緩和なのかを切り替える、という感じです。

リスク評価の結果のアクションをどうするか、については通常の条件付きアクセスと同じように設定します。

とりあえず評価だけですが、ポリシーを実行するとカスタム属性に評価結果が出てきます。

ざっとですが、こんな感じです。

サードパーティのソリューションとの連携のエコシステムもできつつある中、純正機能もどんどんリリースされるので、全体として成長していくようにキャッチアップを続けていかないといけませんね。