2021年8月6日金曜日

LINEがFIDO2サーバーをOSSで公開したので触ってみた

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

もうすでに記憶の彼方ですがLINEさんは過去にFIDO2サーバーをOSSで公開する!と宣言していました。それが遂に公開されました!素晴らしい!

ということでとりあえず動かしてみました。(まだ中身は全然みてません、単に動かしただけです)




とりあえず公開されているレポジトリをcloneしてREADME.mdに記載の通り動かしてみました。


# Start RP Server
cd rpserver
./gradlew bootRun
# Start FIDO2 Server or Line-fido2-spring-boot Demo
cd server
./gradlew bootRun
cd spring-boot-starter/line-fido2-spring-boot-demo
./gradlew bootRun


やることとしては以上です。

これで http://localhost:8000 にアクセスするとテスト用のトップ画面が出てきます。

まずは認証器の登録

まず画面上部のuser nameとdisplay nameに適当に名前を入れます。

その状態で画面下部のregisterをクリックすると認証器の登録を求められます。今回はMacbook ProのTouch IDを使っていますが、Yubikeyなどのローミングキーやモバイルの場合はFace IDなども使えます。

うまくいけば成功したよ、というメッセージが表示されます。



認証器を使って認証してみる

次は登録した認証器を使って認証してみます。resident_keyにも対応しているので画面丈夫のuser nameを入れないとユーザ名の選択をするところからスタートしてくれます。とっても便利です。
もちろんuser nameを入れてAuthenticateをクリックするとユーザ名を選択することなく認証することもできます。

こちらもうまく認証されると画面下部に成功!とメッセージが出ます。




とりあえず動かしてみた、というだけなので簡単ではありますが以上となります。

OSSでピュアなFIDOサーバーの実装が出てきたというのは非常に画期的なので、これから実装をする方にとってはもちろん、自社のWebサイトへFIDO認証を組み込む方にとっても一つの選択肢になるのかもしれません。(もちろんこれまでもKeycloakのようにOSSでFIDOをサポートしたソフトウェアはありましたが、FIDOの部分だけ抜き出すのも苦労するので)




















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年7月23日金曜日

必読!「デジタルアイデンティティー」

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


ついに発売されました。米OpenID Foundation理事長の崎村夏彦さんによるデジタルアイデンティティに関する集大成とも言える書籍、その名も「デジタルアイデンティティー 経営者が知らないサイバービジネスの核心」です。

献本いただきましたので早速熟読してみました。


もう一言では言い尽くせないのですが、何しろ素晴らしい。(ボキャブラリー不足、、汗)

ここまで体系的かつ広い視点でデジタルアイデンティティに関して俯瞰した書籍は洋書を含めて存在していなかったんじゃないか?と思います。(Phil Windleyの「Digital Identity」はもちろん良書ですが、如何せん2004年の書籍なので古くなってきています)


とにかくこちらから購入できるので、まだの人は今すぐポチるのです。


ざっと感想を含め見どころを。

  • 言葉の定義が経緯を含めとにかく丁寧に書かれている
    • これを見ると世の中に出回っている記事がどれだけ適当な理解で書かれているのかわかってしまいます。この辺がこの領域をわかりにくくしている原因の一つだと思います。
  • 技術仕様がなぜ必要なのか、OAuth/OpenID Connectがなぜ必要となったのか、など歴史的な経緯を含め解説されている
    • 頑張って仕様を読んでも、あくまで結果をみているだけなので、なぜこのような仕様になったのか?がわからず腹に落ちにくい点もあると思います。もちろん解説記事やイベントでのプレゼンテーションは存在するのですが、分散してしまっているので体系的に理解するのは至難の業です。
  • FAPIやeKYC&IDAなど若い仕様についても言及されている
    • 単純にフレームワークとしてのOAuth/OpenID Connectだけでは不足している実世界でのユースケースと対応するためのプロファイル群についても詳細に記載されている。
  • よく知っている事件を例に何が必要だったのかを解説しており、理解しやすい
    • ドコモ口座事件、SBI証券の不正出金の件、Facebookのアクセストークン漏洩事件などIT業界のみならず広く報道された事件の裏側がデジタルアイデンティティの側面から解説されており、腹落ちしやすい。
  • プライバシーと個人情報保護の関係、トラストフレームワークなどビジネス担当も技術担当も周辺知識として知っておく必要がある知識もカバーしている
    • まさにサブタイトルにもなっている「経営者がしならない〜」という点にも繋がりますが、システム担当だけでなくビジネス担当やまさに経営者の方も知らなかった、では済まされないプライバシー尊重に関する考え方についても非常に易しく書かれており、非技術者でも読みやすい。

書き始めるとキリがないので、この辺りでやめておきます。

また、大きな特徴として「他の文献への参照が異常に少ない」という点が挙げられると思います。これは常に第一線でデジタルアイデンティティに取り組んでこられた崎村さん自身が執筆している、ということが大きく影響していると思われます。つまり、本書は今後の文献では一次ソースとして扱われることになる、ということを示しています。その点においても必携・必読であるとも言えます。


ちなみに、OpenIDファウンデーション・ジャパンでは崎村さんをお招きして本書の見所解説などを直接お話しいただく出版記念イベントを企画している最中です。こちらは纏まりましたら改めてお知らせしたいと思います。(サインもらえるかも!)

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年4月6日火曜日

Azure AD Verifiable Credentialsがやってきた(Public Preview)

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

ようやく出ました、Azure AD Verifiable CredentialsのPublic Preview。


AlexのBlog

https://techcommunity.microsoft.com/t5/azure-active-directory-identity/announcing-azure-ad-verifiable-credentials/ba-p/1994711


各種リソース

https://www.microsoft.com/en-us/security/business/identity-access-management/verifiable-credentials

某社もソリューションパートナーになってます。

この辺りからチュートリアルも触れるのでガシガシ触っていけると面白いと思います。

Microsoft Authenticatorを最新版にアップデートするとこんな感じでVerifiable Credentialsをどんどん発行していけます。これで各種デジタルな証明書を持ち運んでIdPにアクセスすることなくVerifierへ証明書を提示していくことができるようになるはずです。




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も変わっちゃう?
などなど。


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