ラベル Azure AD B2C の投稿を表示しています。 すべての投稿を表示
ラベル Azure AD B2C の投稿を表示しています。 すべての投稿を表示

2024年5月3日金曜日

Entra External IDがGAされています

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

長らくPreviewだったEntra External ID(旧Azure AD B2B、およびCIAM)がGAされました。(といっても特にCIAMはまだまだPreviewの機能だらけなんですけどね・・・)

https://techcommunity.microsoft.com/t5/microsoft-entra-blog/announcing-general-availability-of-microsoft-entra-external-id/ba-p/3974961


個人的にポイントだと思っているのは、いわゆるワークフォースIDであるEntra ID(Azure AD)との機能面での統合が進んだこと、そしてEntra Verified IDとの連携ですね。

しかし、もうここまでくると単なるID基盤という枠には収まらず、他のAzureリソースとの組み合わせを意識した統合的なアイデンティティ・プラットフォームになってきていますね。いよいよインフラとしての設計も難しくなってきてますので、ちゃんとプロ(国井さんとか)の教育を受けて使うことをお勧めします。



個人的にも気になってきたAzure AD B2Cからのトランジションについてはまだまだ情報が不足していますが、現状のCIAMの機能ではとてもじゃないけどAzure AD B2Cの自由度のカバーはできないので、まだしばらくは並行してサポートされていくことになると思います。本社の開発チームの話ではマイグレーションパスなどもゆくゆくは用意していくということなので、こちらも継続ウォッチですね。

2024年1月6日土曜日

OpenID Providerを作ることでOpenID Connectを知る

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

OpenID Connectってシンプルなプロトコルだと思いますが、やっぱりOpenID Providerの気持ちにならないと本当のところはわからないよね、ということで「OpenID Providerを作る」シリーズ(デ⚫︎ゴ⚫︎ティーニ風)でもやってみようかと思います。

超絶ベーシックなところまでは前回・前々回のポストを踏まえて2時間くらいで作ってみたのでまずはこちらを解説しつつ実装を一緒に育てていきたいな、と考えています。

とりあえず作ったところまではこちらのレポジトリで公開しています。(前回のポストからの追加部分としては認可コードをJWEにしたところくらいです。詳しくはReadmeを見てください)

https://github.com/fujie/oidc-study-op


ということで、中身は次回から解説しますが現状の実装で何ができるのかの確認を兼ねてOpenID Connectの通信が実際にどうなっているのかを、Azure AD B2Cを使って確認してみようと思います。結構Azure AD B2CとかAuth0を触るときにサービス側が外部IdPにどういう期待をしているのかを知るためにこれまでも簡易IdPを作って通信トレースをとったりしていたのですが、この辺りの試行錯誤がOpenID Connectそのものを知ることにつながりますし、Azure AD B2CやAuth0などのIDaaSについての知識も深められて一石二鳥です。


早速Azure AD B2Cに作ったOpenID ProviderをIDプロバイダとして読み込ませてみます。作ったOpenID Providerはローカルで動かしていますのでngrokを使ってインターネットからアクセスできる様にしています。

ちなみにAzure AD B2Cに限らずMicrosoftのID基盤はresponse_modeとしてform_postをデフォルトにしているのですが、そんなものは作っていないのでqueryに変更してあげる必要があります。

free版のngrokを使っているのでngrokを止めてしまうとURLが変更されてしまうので注意が必要です。(もし止めてしまったら一度IDプロバイダを消して再作成する必要があります)


なお、ngrokを使う利点としてインスペクションができることです。(http://127.0.0.1:4040をブラウザで開くと通信内容がトレースできます)



Azure AD B2CでIDプロバイダの設定をして保存を行うとDiscoveryとjwks_uriへのアクセスがあります。


この状態でユーザーフローを作成し、実行してみます。


順調にIDトークンが発行され、ユーザ登録画面に遷移しました。


インスペクションを見るとOpenID Connectのフローに則って順次アクセスされていることがわかります。

まぁ、徐々に育てていきましょう。


2024年1月3日水曜日

ログインさせたいユーザを指定してIdPへFederationする(SAML/OpenID Connect)

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

SAMLでもOpenID ConnectでもFederation構成をしているとService Provider(SP)やRelying Party(RP)側であらかじめIdentity Provider(IdP)側で認証させたいユーザ名を指定したいケースがしばしばあります。
典型的なケースの一つは多要素認証をオンデマンドで実行させた場合で、普通のページには第1要素であるユーザ名とパスワードで認証、決済ページには追加要素で認証を要求する、というシナリオは結構あり得るシナリオです。この場合、第1要素で認証されたユーザと追加要素で認証されたユーザをSP/RP側で比較することで同じ人であることを検証することももちろん可能なのですが、できればあらかじめ追加要素で認証させたいユーザの識別子をSP/RPからIdPに渡してあげることで利用者が再度ユーザIDをIdP側で入力する必要がなくなるのでUXも向上します。
この様なシナリオは当然のことながらSAMLでもOpenID Connectでもサポートされています。

SAMLの場合

SAMLを使う場合、SPからのSAML Requestの中にSubjectを指定することができます。
OASISのSAML2.0 coreの仕様の3.4.1のAuthnRequestのエレメントの章に記載があるSubjectが該当します。
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>
実際の動作は上記リクエストを受け取ったIdP側の実装に依存するので利用するIdPの仕様を確認してださい。ちなみにEntra ID(Azure AD)の場合はこの方法ではなくクエリパラメータにlogin_hint=test@example.jpという形で付加してリクエストを投げる形になります。(この辺りを参照:https://learn.microsoft.com/ja-jp/entra/identity-platform/single-sign-on-saml-protocol#subject)ただし、Entra IDが外部IdPとFederationしている時はlogin_hintではなくusername=test@example.jpという形でパラメータ名が異なるので要注意です。
また、Azure AD B2Cでは要求リゾルバという仕組みでSubjectの情報を取得することができるので、このサブジェクトに応じた処理を書けば割と自由に実装ができます。
Okta CIC(旧Auth0)はSAML RequestのSubjectをちゃんと判別してくれそうです。(この辺りを参照:https://community.auth0.com/t/pass-login-hint-to-saml-provider/92546

OpenID Connectの場合

こちらはシンプルにlogin_hint属性をクエリパラメータに付加することで実現できます。(仕様はこちらを参照;https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html)こんな感じでAuthentication Requestにパラメータをつけるだけです。
HTTP/1.1 302 Found
  Location: 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
こちらもSAMLと同様にIdPの実装に依存するので実際の動作はIdPの仕様を確認してみてください。ちなみにAzure AD B2Cの場合はSAMLと同じく要求リゾルバで属性の取得ができます。

ちなみに他にもヒント系のパラメータは色々とあります。
また、SP/RPから認証コンテキストを指定したい場合もあるのですが、現在SAMLについてはAuthnContextClassRefというパラメータがありますが、OpenID Connectについてはacr/amrをclaimsパラメータで渡す方法はありますが、レベルの指定方法の共通化をどうするべきか?についてはPam Dingleさんを中心にIntenet Identity Workshopで議論が続けられているので今後の注目ポイントかもしれません。

2023年12月18日月曜日

Worldcoinによる金融包摂とデジタルアイデンティティ

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

2023年も終盤に近づいてきたということで、今年もDigital Identity技術勉強会 #iddance Advent Calendar 2023に参加しています。


今回のネタはWorldcoinで話題のWorld IDを探っていきたいと思います。

ということでこんな内容でお届けします。

  • Worldcoinとは
  • World IDの取得と確認
  • Identity ProviderとしてのWorld ID
  • Incognito Actions(おまけ)

なお、お約束ですが本記事ではWorldcoinを含む特定の仮想通貨の購入や投資などを推奨するものではありません。あくまでDigital Identity関連技術の観点からWorldcoin/IDを見ていきたいと思います。


Worldcoinとは

Worldcoinというキーワードを検索するとOpenAIの創業者であるSam Altman氏が共同創業者した仮想通貨のプロジェクトという切り口で紹介されている記事が多くヒットしますが、本家Worldcoinのサイトを見るとこのように記載されています。

Worldcoin is an open-source protocol, supported by a global community of developers, individuals, economists and technologists committed to expanding participation in, and access to, the global economy. The Worldcoin Foundation is the steward, and will support and grow the Worldcoin community until it becomes self-sufficient. Tools for Humanity helped launch Worldcoin, and currently serve as advisors to the Foundation and operators of the World App.(原文)

ワールドコインはオープンソースのプロトコルであり、開発者、個人、経済学者、技術者からなるグローバルコミュニティによって支えられている。Worldcoin財団はスチュワードであり、Worldcoinコミュニティが自立するまでサポートし、成長させる。Tools for Humanityはワールドコインの立ち上げを支援し、現在は財団のアドバイザーとワールドアプリの運営者を務めている。(Deeplで機械翻訳) 

また、同サイトにはWorldcoinに関するホワイトペーパーも公開されており、その中に端的にWorldcoinはこのように解説されています。
Worldcoin was founded with the mission of creating a globally-inclusive identity and financial network, owned by the majority of humanity. If successful, Worldcoin could considerably increase economic opportunity, scale a reliable solution for distinguishing humans from AI online while preserving privacy, enable global democratic processes, and show a potential path to AI-funded UBI.(原文)

Worldcoinは、人類の大多数が所有する、グローバルに包括的なアイデンティティと金融ネットワークを構築することを使命として設立された。成功すれば、ワールドコインは経済機会を大幅に拡大し、プライバシーを守りながらオンライン上で人間とAIを区別するための信頼できるソリューションを拡大し、グローバルな民主的プロセスを可能にし、AIが資金を提供するUBIへの潜在的な道を示すことができる。(Deeplで機械翻訳)

要するに金融包摂の文脈で設立されたデジタルアイデンティティと金融ネットワークで、UBI(ユニバーサル・ベーシック・インカム)を実現することも一つのゴールとして定めている様です。

また、同時にWorldcoinを構成する要素についても以下のように説明が記載されています。

Worldcoin consists of a privacy-preserving digital identity network (World ID) built on proof of personhood and, where laws allow, a digital currency (WLD). Every human is eligible for a share of WLD simply for being human. World ID and WLD are currently complemented by World App, the first frontend to World ID and the Worldcoin Protocol, developed by the contributor team at Tools for Humanity (TFH).(原文)

ワールドコインは、個人であることの証明の上に構築されたプライバシーを保護するデジタルIDネットワーク(ワールドID)と、法律が認めるデジタル通貨(WLD)で構成されている。すべての人間は、人間であるというだけでWLDの分け前を得る資格がある。World IDとWLDは現在、Tools for Humanity (TFH)の貢献者チームによって開発された、World IDとWorldcoinプロトコルの最初のフロントエンドであるWorld Appによって補完されている。(Deeplで機械翻訳) 

なるほど、Worldcoinのサイトのトップに記載されていたWorld ID、WLD、World Appはそれぞれ以下のような関係性だということがわかります。(トップページからリンクされるそれぞれのページの解説文からも補完)

  • World ID:デジタルIDネットワーク
    • A more human passport for the internet. More powerful. More integrations. More human.(原文)
    • インターネットのより人間的なパスポート。よりパワフル。より多くの統合。より人間的に。(Deeplで機械翻訳)
  • WLD:デジタル通貨(Worldcoin Token)
    • A more human token freely, equally, and globally distributed to unique humans.(原文)
    • より人間的なトークンは、自由に、平等に、そしてグローバルに、ユニークな人間に配布される。(Deeplで機械翻訳)
  • World App:フロントエンドアプリケーション
    • More human access to the global economy with identity and finance for all. Privacy‑first. No fees. 24 hour support.(原文)
    • すべての人のためのアイデンティティと金融で、より人間らしいグローバル経済へのアクセスを。プライバシー第一。手数料無料。24時間サポート。(Deeplで機械翻訳)
なんとなくわかってきました。
要するに金融包摂(世の中には銀行等の金融システムにアクセスできない人たち、要するに銀行口座が持てず社会経済に参加できない人たちが多く存在する。その人たちの経済参加を促進すること。この辺りはThe World Bankのページが参考になります。)を実現するには、人類が区別されることなくアクセスできるアイデンティティ・ネットワークに支えられたユニバーサルなベーシック・インカムを含む金融システムが必要であり、Worldcoinはその理想を実現するためのプロジェクト、という位置付けということです。


World IDの取得と確認

では、早速World IDを取得してみたいと思います。
World IDアカウントを作成するのに必要となるのは、以下のものです。
  • スマートフォン(iOS/Android)にインストールするWorld App
  • SMSの受信できる携帯電話番号(なくてもアカウントは作成できます)
スマホを持っていない人は金融包摂的にどうなるのか?という疑問は抱きつつ、World Appをインストールしセットアップを続けます。

もちろんこの状態でもWorld IDは作成されているのですが、World IDのもう一つの特徴は本当に人(Human)であることをOrbというデバイスを使って確認(物理的にOrbが置いてある場所まで行って対面で確認を行う)を行うことにあります。

まだID確認を行なっていない状態だとアプリの上部にVerify your World IDというリンクが表示されるのでタップすると近所に存在するOrbの場所が表示されますので、場所によっては予約をした上で現地を訪問して存在確認を行います。なお、この際に虹彩登録を行う必要があることから謎のシステムやデバイスに生体情報を提供するのはどうなのか?という議論も存在します。確かに私も渋谷の指定の場所へ行ってOrbでID確認をしてきましたが、かなりカジュアルな感じで登録ができてしまうので、偽Orbを作って生体情報だけを搾取する人たちが出てきても不思議ではありません(Orbを操作してくれる人も、Orbそのものについても登録しようとしている人から見て正当性を確認する手段がない)。この辺りは今後の課題なんだと思います。

なお、ID確認時には法的なアイデンティティ・ドキュメント(免許証などの身分証明書)の提示は求められないので、この辺りは金融包摂のため、という考え方がベースにあるのだと思います。ただ、一人のユーザが複数のWorld IDを取得できないようにするための虹彩情報の突合・重複確認がどこまで本当に実施されているのか?などはよくわかりません。

こんな感じのデバイスが置いてあるのでアプリのQRを読み込ませた後で虹彩登録を行います。登録自体は5分もかからずサクッと終わります。


なお、このID確認を行わないとベーシック・インカムとなるWLDを受け取ったり取引することができません。ちなみにWorld Appをインストールすると定期的(週一回くらい?)にGrantといってベーシック・インカムとしての3〜10程度のWLDが付与されます。現時点で1WLDは日本円で368〜9円程度なので、隔週で1,000円もらえる感じです。実際に利用する際は暗号資産取引所などで日本円へ換金することもできるんじゃないかと思います。(やったことありませんが)※追記:12/18の朝にみたら爆上がりしてました。624円とかになってました。

いずれにしても確認が終わるとVerifiedとして記録がされます。



Identity ProviderとしてのWorld ID

さて、デジタルIDの話なので、あまり仮想通貨の話に行っても仕方がないのでWorld IDの使い方の話をしたいと思います。

非常にざっくりいうと、World IDもOpenID Connectに対応したIdentity Providerとしての機能を持っています。

開発者ポータルへアクセスし、サインアップすると一般のIdentity Providerと同じようにクライアント登録などができる仕組みが提供されています。

ちなみにAuth0(Okta CIC)ではすでにマーケットプレイスにSign in with Worldcoinの機能が提供されていますので、クライアントID/シークレットの登録とRedirectURIを設定すると簡単にWorld IDによるサインインが実装できます。

開発者ポータルでClient ID/Secret/RedirectURIの設定を行います。

こちらはAuth0(Okta CIC)の画面。Social Connectionsとして定義します。

Sign in with Worldcoinを起動するとQRコードが出てくるので、World AppでQRコードを読み込み、サインインします。

World App側でQRコードを読み込むとVerify with World IDの画面が表示される、確認に成功するとサインインされます。


World IDのOpenID Connectの実装に関してはドキュメントが公開されているので、こちらを見ると自作のWebアプリケーションや他のIDaaSへの接続も容易です。(最近World IDのバージョンが2.0に更新され、PKCEのサポートなどが追加されました)

簡単なRelying Partyを書いて実際のid_tokenの中身などを確認していきましょう。細かいコードは省略しますが、結果的にこんなid_tokenが返ってきます。


ポイントはこの辺りです。ドキュメントをみるとhttps://id.worldcoin.org/betaのエレメントはdepricateっぽいですが、verification_levelとしてOrbで確認済みのWorld IDかどうかがわかるような仕組みになっています。

  "https://id.worldcoin.org/beta": {

    "likely_human": "strong",

    "credential_type": "orb"

  },

  "https://id.worldcoin.org/v1": {

    "verification_level": "orb"

  },

ちなみに、Orbで確認を行なっていないWorld IDでもアクセスしてみるとverification_levelがdeviceとなっています。

  "https://id.worldcoin.org/beta": {

    "likely_human": "weak",

    "credential_type": "device"

  },

  "https://id.worldcoin.org/v1": {

    "verification_level": "device"

  },


ところで、Auth0でも簡単なRelying Partyでも実装できたので、ついでにAzure AD B2Cでも実装してみようと思います。Discoveryもサポートしているし、openid-configurationを見るといつもの鬼門のresponse_mode=form_postもサポートしているようなので試してみます。

こんな感じでIDプロバイダーを設定します。

ところが、response_modeをform_postにするとWorld IDのAuthorizationエンドポイントでWorld Appでサインインしたところjsのエラーが出て止まってしまいます。どうもCSPの設定がうまくできていないみたいですね。。。


ということで、response_modeをqueryに変更して再度試してみるとTokenエンドポイントへのアクセスでエラーが出ているようです。
ここは結構ハマったのですが、Postmanなどで順番にアクセスするとちゃんとid_tokenが取得できるので、Azure AD B2CがTokenエンドポイントへアクセスする際に何か変なヘッダがついていたりするんだろうな、、(あるいは逆にUser-Agentがないと返事をしないTokenエンドポイントがいたりするのでそういうケースかも、、)と思いダミーのTokenエンドポイントを作りPostman経由の場合とヘッダを比較。

結果、

expect: '100-continue'

が犯人でした。

PostmanでもexceptヘッダをつけるとWorld IDのTokenエンドポイントがエラーを出しました。どうやらContent-Lengthの事前通知には対応していないようです。

とはいえ、APIクライアントとなるAzure AD B2C側のリクエストをここまで細かいレベルで調整するのはカスタムポリシーを使っても無理っぽいので、現時点では諦めます。(どうしても実装する場合はTokenエンドポイントとの間にゲートウェイモジュールを立ててProxyさせる形になると思います)


Incognito Actions(おまけ)

ここからはおまけですが、World IDにはIncognito Actionsという機能があります。これはユーザがSign in with World IDを含むVerifyをする対象のアプリケーションを簡単に作るための機能です。(例えば、投票などが想定されています)
開発者ポータルからIncognito Actionsメニューから定義体を作っていくことができますが、その際にVerifyの回数の制限などをつけることができます。
例えば、Uniqueだと1つのWorld IDにつき1回しかVerifyができないようなアプリケーションが作れますし、2 Verificationsや3 Verificationsのように2回・3回まで許可する設定やUnlimitedのように制限なしの設定もできます。
本来はIDKitというSDKやAPIを使ってアプリケーションを構築していくことになるのですが、管理者ポータルからテストをするためのKioskモードが用意されているのでこちらから確認していきます。
Enable Kiosk〜Open Kioskでテスト用の画面が開きます。

先ほどのSign in with World IDと同じようにWorld AppでQRコードを読み込みます。今回はUniqueモードを設定したので最初の1回はちゃんとVerifiedとなります。
しかし、再度同じようにKioskを起動して同じWorld IDで確認をするとAlready verifiedとエラーが出ます。
簡単な投票や特典の配布などのアプリを作るのに良さそうですね。



ということで、Worldcoin / World IDを触ってみました。
金融包摂という社会課題への対応をしていくという方向性については共感できるものがありますし、うまく社会に浸透していくことができればベーシック・インカムはおいておいて金融システムからネグレクトされた人々にとっては救いになり得るのかもしれません。
ただ、先に書いた通りOrbの真正性などまだまだ情報の非対称性など粗いところも多く、まだまだポリシーやガバナンス面を含めやるべきことはたくさんあるんじゃないかと思います。Sam Altman氏もOpenAIで得られた知見や利益を、打ち上げ花火だけではなく、うまく実際の社会のために役立てられるといいですね。





2021年7月31日土曜日

新Sign in with SlackでAzure AD B2CにSlackでサインインできるようにする

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


Sign in with SlackがOpenID Connectに対応したので、Azure AD B2Cに繋いでみました。

Slackのドキュメントはこちら



ふむふむ。昔のSlack連携はOAuth2.0でidentity.*というスコープが使われていたところがOpenID Connectに対応したってことですね。

ではやってみましょう。


まずはSlack側にアプリ定義を作成

こちらからSlackアプリ定義を作ります。メインはAzure AD B2C(今回のケースだとRelying Partyになります)に渡すためのclient_id、client_secretを作るための行為です。

Create an Appをクリックするとスクラッチから作るかapp manifestを使って作るかを聞かれますので、今回はスクラッチから作ることにします。


アプリ名と対象となるワークスペースを選択して次へ進みます。


ナビゲーションメニューからOAuth & Permissionsを開きます。


少し下にスクロールするとredirect_uriを設定するところがあるので、Azure AD B2CをRelying Partyとして使う場合のCallback Uriを設定します。以下の形式のUriです。

https://your-tenant-name.b2clogin.com/your-tenant-name.onmicrosoft.com/oauth2/authresp

これでSlack側への設定は終わりです。

左のナビゲーションメニューのBasic Informationからclient_id、client_secretが取得できるのでメモしておきましょう。後でAzure AD B2C側に設定します。


Azure AD B2CにIdentity Providerを設定する

次はAzure AD B2C側です。

IDプロバイダのメニューから新しいOpenID Connectプロバイダーをクリックして設定を開始します。

必要なのは以下の設定です。

  • 名前:適当に
  • メタデータURL:https://slack.com/.well-known/openid-configuration
  • クライアントID、シークレット:Slack側で取得した値
  • スコープ:openid profile email
  • 応答の種類:code
  • 応答モード:form_post
  • ドメインのヒント:なし
  • IDプロバイダーの要求のマッピング
    • ユーザーID:sub
    • 表示名:name
    • 名:given_name
    • 姓:family_name
    • 電子メール:email

上記を設定して保存をしたら設定はおしまいです。


ユーザーフローを実行してみる

早速ですが適当なユーザーフローを作ってテストしてみます。アプリはお馴染みのhttps://jwt.msを使います。

フローを実行するとSlackへリダイレクトされて権限に関する同意を要求されます。
その後、素直にAzure AD B2Cへ戻り、Slackから取得した属性が渡ってきていることが確認できます。



ということで、サクッと15分くらいでできてしまうので、ぜひみなさまも試してみてください。




2021年5月27日木曜日

Build 2021で発表されたAzure AD B2Cのアップデート

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


今年も Build のシーズンですね。

Ignite に比べて主に Developer 向けの Update がメインなカンファレンスなので Identity 要素は薄めですが、もろもろ発表はありました。

※主にこのセッションからです。


ざっくりですが、すでに発表済みだったものも入れるとこんな感じです。

(ドキュメントが公開されているものはリンクしておきます)



Apple ID サポートは2年くらい前にカスタムポリシーで実装してたやつですね。その後 Private Preview で一部では提供されていたので私も評価していたんですが、しばらく前に全面的にリニューアルされて出てきました。ただ、個人的には iOS も最近は Platform Authenticator としてつかえるので Apple ID としてサポートするよりも FIDO として実装しちゃった方がいいじゃないかな?と思ってます。(仕事で Azure AD B2C のデプロイする場合は FIDO でやっちゃってます)

昔実装した様子の動画



Verifiable Credentials を使ったログインは個人的にも注目している領域です。デモはされていましたが、正式に Claims Provider として Verifiable Credentials がサポートされるのかどうかはわかりません。




実は私も半年くらい前にこの辺りの実装をしてみてました。こんな感じの動きになります。



Identity Protection 連携はこちらも以前投稿したやつですね。ようやくGAです。



API Connector はカスタムポリシーを使いたくない人向けですね。(私はユーザーフローは基本使わない人なのであんまり興味ないです)



カスタムドメインもちょうど先日投稿したやつですね。Azure Front Door を使って実装するやつです。これまで Microsoft と交渉しないと使えなかった機能なので、今更ながらに非常に嬉しい機能です。



他にも Ask the Expert セッションを聴いていると色々とポロリもあったりして面白かったです。(TOTP の Private Preview の話とか)


最近は Identity Verification Partner との連携などエコシステムも育ってきつつある Azure AD B2C ですが、Microsoft 自身によるエンハンスも着実に進んでいるみたいなので引き続き楽しんで触っていけそうです。



2021年4月19日月曜日

[Azure AD B2C]カスタムポリシー内のエラーハンドリング

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

たまには小ネタを。


Azure AD B2Cのカスタムポリシーを使ってUserJourneyを構成する際に悩ましいことの一つはエラーハンドリングです。

初期状態だと、UserJourney内のOrchestrationStepでエラーが発生した場合はエラーメッセージをパラメータにつけて呼び出し元のアプリケーションへリダイレクトする、という振る舞いをするので、アプリケーション側で発生しうるエラー毎に振る舞いを定義してあげる必要があります。


かっちりした開発をする場合はちゃんとアプリケーション側でエラーハンドリングをするのが正解だとは思いますが、アプリ側に手が入れにくい場合などある程度Azure AD B2C側でエラー画面を出して処理を止めたい場合もあります。こういう時に使うのがUserJourneyBehaviorsに定義するOnError Modeです。
とりうるパラメータと振る舞いは以下の通りです。
  • DisplayInService:Azure AD B2Cのフローの中でエラーメッセージを表示して処理を止める
  • ReturnToRequestor(Default):呼び出し元アプリケーションへエラーメッセージをつけて戻す

試しに絶対にエラーになるREST APIを呼び出すClaimsProviderを作りUserJourneyの中で呼び出して見ます。

ServiceUrlがhttps://www.example.com/apiとなっているのでNot Foundとなり、このTechnical Profileは絶対に失敗します。

このUserJourneyを呼び出すRelyingPartyのOnError ModeをDisplayInServiceにセットして見ます。


これでフローを実行してみると一番最初に貼り付けた画像の挙動(初期状態)とはことなり、Azure AD B2Cのフローの中でエラーメッセージが表示され、フローが停止します。



どちらが良いかはシナリオ次第ですが、デバッグ時はこちらのモードを使ったほうがわかりやすいかもしれませんね。


2021年3月17日水曜日

[Azure AD B2C]遂にカスタムドメインがやってきた

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


おそらくAzure AD B2Cユーザ最大の要望だったカスタムドメイン(b2clogin.comのサブドメインではなく持ち込みのドメイン)がようやくパブリック・プレビューになりました。

参考)b2clogin.comのサブドメインをカスタムドメインと言っていた頃の記憶


当時もコレジャナイ感を感じつつ、Azure AD B2Cを使っているはずのレアル・マドリードのサイトを見ると自前ドメインを使ってるやん、、的な羨望の眼差しを抱えつつ実案件ではUSまで押しかけてプライベート・プレビューとして個別にカスタムドメインをアンロックしてもらったり、と苦労していたものです。。。


この苦労は当然世界共通で、中にはWeb Appをフロントにたててrewriteを使って無理矢理カスタムドメインを実現してしまう猛者まで現れる、という状態でした。

(ちなみにこの方法、当然のことながら可用性は落ちますし、Identity Protectionを使ったクライアント判定もできなくなるのでオススメはできません)



ということで、ようやくパブリック・プレビューです。

https://docs.microsoft.com/ja-jp/azure/active-directory-b2c/custom-domain?pivots=b2c-custom-policy


仕組みとしては、Azure Front DoorをAzure AD B2Cの手前においてURLのRewriteする、という形です。ってこれ、上で紹介した猛者のやってた技をオフィシャルに実装した、という感じなんですね。

Identity Protectionなどはちゃんと効くのか、などはおいおい深堀りしてみるとして、まずはファーストルックです。


大まかな手順としては、

  1. Azure AD B2Cの実体となっているAzure ADにカスタムドメインを追加する
  2. Azure Front Doorを作り、b2clogin.comへ振り分け設定をする
  3. Azure Front Doorにカスタムドメインを設定する
という流れです。


順に確認してみましょう。

1. Azure AD B2Cの実体となっているAzure ADにカスタムドメインを追加する

ご存知の通り、Azure AD B2Cには実体となっているAzure ADが存在します。ポータルからAzure AD B2Cを立ち上げると、別のテナントが開き、その中でAzure AD B2Cの管理を行う、という形になります。この別テナントにもAzure ADが存在しているので、Azure AD B2Cの管理画面からテナントを変えずにAzure Portalのホームへ遷移、改めてAzure ADの管理メニューを開くと実体の管理ができるようになります。(分かりにくいですね)

そのテナントは通常のAzure ADなのでカスタムドメインを追加することができます。


ここで普通にカスタムドメインを追加し、ドメインの所有権の確認を行います。

これで第1段階はOKです。


2. Azure Front Doorを作り、b2clogin.comへ振り分け設定をする

次はAzure Front Doorを作って構成します。

Azure Front Doorは単純なエッジで動くレイヤ7のフロントサービスで、SSLのオフロードなどを含め高スケーラビリティなWebアプリをデプロイするのに役に立つサービスです。

必要な設定は、

  • フロントエンド設定(リクエストを受けるドメイン)
  • バックエンド(振り分け先となるWebアプリケーション)
  • 振り分けルール(パスやポートなど、バックエンドへの振り分け条件の設定)
の3種類です。

まずはフロントエンドです。この段階では適当な名前でAzure Front Doorドメイン(azurefd.net)上の名前を定義します。※どっちみち後でカスタムドメインをつけるので適当でOK、っていうことです。


次にバックエンドです。今回はAzure AD B2Cがバックエンドとなりますので、カスタムドメインを使いたいAzure AD B2Cのテナントドメイン名(xxx.b2clogin.com)を設定します。

最後が振り分けルールです。

ここでは特に考えずにフロントとバックエンドをストレートにマッピングしておきます。

ここもカスタムドメインを追加した後でちゃんと設定しますので仮でOKです。

これでAzure Front Doorの基本設定は完了です。


3. Azure Front Doorにカスタムドメインを設定する

次はAzure Front Doorにもカスタムドメインを設定します。ここで設定するドメインは先にAzure ADに設定したドメインと同じものを使う必要があります。

Azure Front Doorのフロントエンドまたはドメインよりカスタムドメインを追加します。

CNAMEの設定と検証が走るので必要なレコードをDNSサーバ上に設定する必要がありますが、設定としては単純にカスタムドメインを追加するだけです。


正常にドメインが追加できたら、振り分け規則についてもカスタムドメインの設定を行います。フロントエンドまたはドメインの設定より追加したカスタムドメインを選択するだけなので特に難しいことはありません。


とりあえず設定関係はこれで完了です。

(ちなみにSSL証明書もAzure Front Door側が勝手に設定するので別途買う必要はありません)

ただ、忘れがちな点が何点かあります。

  • カスタムHTMLをAzure Storage上に配置している場合はCORS設定を行う
  • redirect_uriや各種エンドポイントのアドレスも当然変わるので外部IdPなどに設定してあるredirect_uriやアプリに設定してあるエンドポイントアドレスを修正する

カスタムHTMLを使っている場合のCORS設定

外部IdP(LINEの例)のredirect_uriの追加



これで本当に設定完了です。


試してみる

とりあえず適当なアプリの設定を変えたらログイン要求をしてみます。



ちゃんとカスタムドメインで動きます。

id_tokenの中のIssuerのURIも変わっていることが分かります。


特にむずかしいことはなく、問題なく動きました。


とはいえ気になる点は何点か。
  • Identity Protectionなどフロントの環境を取得して動くサービスやカスタムポリシーの要求リゾルバはちゃんと動くのか?
  • カスタムドメインを設定しても、https://カスタムドメイン/xxx.onmicrosoft.com(もしくはテナントID)となってしまうのをhttps://カスタムドメインだけにできないか?(ルール設定でなんとかなる気もしなくもない)
  • SAML IdPとしてAzure AD B2Cをつごかす場合のIdPのEntityIDも変わっちゃう?
などなど。


引き続き試してみようと思います。











    2020年9月26日土曜日

    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つのセッションです。

    全体を簡単に要約すると、
    • 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ならではのユースケースがもっと研究されると良いな、というのが全体的な感想でした。