Quantcast
Channel: IdM実験室
Viewing all 769 articles
Browse latest View live

Azure AD関連Update@Ignite 2018

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

Igniteのシーズンですね。

昨晩のKeynoteに引き続き今晩もAzure AD、EMS関連のUpdateが色々とあるようなので、楽しみです。

取り急ぎ詳細は今晩以降ですが、個人的に重要なアップデートは以下2点ですかね。

1.Passwordless login to Azure AD
 Microsoft Accountで実装されているAuthenticatorアプリを使ったパスワードレスのログインです。※画像はAlex Simonsのtwitterより。

 早速Techcrunchなども記事にしてます。
 https://techcrunch.com/2018/09/24/microsoft-wants-to-help-you-do-away-with-more-passwords/

2.IntuneでWin32アプリの配布が可能に
 結局GPOとの併用が辞められないIntuneですが、一つの大きな理由にWin32アプリの配布の課題もあったと思うので、この辺りも気になるところですね。



何しろ、セッション検索でキーワード指定をすると膨大な量が出てくるので、追いかけきれません・・・
・Active Directory : 113セッション
・Identity : 182セッション

とりあえず、Windows Server 2019のGAも決まったことですし、この辺りは必見かと。
BRK2254 - Azure Active Directory: New features and roadmap
BRK3030 - What's new in Active Directory Federation Services (AD FS) in Windows Server 2019
THR2312 - Trusted Identity Platform: Passwordless Auth using Azure AD


Windows 10 October 2018 UpdateのEdgeでWebAuthnを試す

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

昨日は #idcon vol. 25 「fidcon 勝手に Meetup」が品川のマイクロソフトで開催されていたので、参加してきました。なんともタイミングの良い?ことに、ちょうど Edge が正式に WebAuthn に対応した、Windows 10 October 2018 Update がリリースされたタイミングと重なりました。

ローンチのアナウンス
https://blogs.windows.com/windowsexperience/2018/10/02/how-to-get-the-windows-10-october-2018-update/


ちょうど日本マイクロソフトの物江さんが Edge の WebAuthn のセッションでデモをされたりもしており、なんというタイミング?!ということで、何か持っているんだと思います。

私はセッション中に Windows Update が降ってきてついつい再起動してしまったので、イベント終了後も開きっぱなしの Macbook Air を持ったまま品川の街を歩くハメになりましたが・・・


ということで、Edge のWebAuthn を試してみましょう。
手元にあったのは、FIDO2 に対応した Yubikey Security Key(青い奴)とマウスコンピュータの指紋認証用の USB ドングルなので、この辺りを使ってみます。

右:Yubico セキュリティキー
左:マウスコンピュータ FP01

テスト用のサイトとして、https://webauthn.org/を使います。
内容としては、

  1. ユーザとデバイスを登録する
  2. ログインする

というシンプルなモノですが、Debug Windows でプロトコルの詳細なメッセージが確認できるので非常に便利です。
ちょうど最後のセッションで @shiroicaさんがお話ししてくださった各パラメータの紹介が非常に役に立ちます。


ちなみにこのテストサイトではあまり細かいパラメータが触れるわけではなく、authenticatorSelection の指定は出来ず、attestation も direct 固定となっています。
この辺りを試すには https://webauthn.io/を使った方が良いかも知れません。
ちなみに Google の @agektmrさんの話では、Google としてはエンタープライズのシナリオを除き attestation は none がお奨めとのことです。(会社が指定した Authenticator だけを使わせたい、というようなケースですね)

1.ユーザとデバイスを登録する

Register タブで Usernameを指定して Register ボタンを押すだけです。

画面の下の部分の Advanced を開くと実際のメッセージを確認することが出来ます。

PubKeyCredParams で -7 と -257 があることから U2F と Windows Hello に対応していることがわかったり、 attestation は direct となっているあたりがわかります。

登録が正常に完了すると OK とステータスが返ってきていることもわかります。

2.ログインする

同じく Login タブを開いてユーザ名を指定、Login ボタンをクリックすると今度はログインのプロセスが実行されます。

尚、Resident-key が使える FIDO2 対応の Authenticator で同じユーザ名で複数回 Registration を行うとログイン時に一覧が出てきます。
(本来は先にユーザ名を指定しているのでキーの特定をした上でログインプロセスが走るのでアカウント選択は出ませんが、同じ名前で登録すると毎回鍵ペアが生成されてしまうみたいです。RPの作りの問題?)

Authenticator で認証します。

ちゃんと webauth.get が成功しています。


もう少し詳しく勉強しないと細かいところはよくわからないので、続きは今晩開催される WebAuthn もくもく会で!
 https://fido2-workshop.connpass.com/event/100944/

[Azure AD]認可コード再利用禁止ポリシーの現状

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

今月(2018年10月)のはじめに突如アナウンスされた「Azure ADのOAuth2.0におけるAuthorization Codeの再利用禁止」について現状を確認してみます。
というか、まさか認可コードが再利用できるとは思っていなかったので、アナウンスされるまで気が付きませんでした・・・。
アナウンス
https://blogs.technet.microsoft.com/jpazureid/2018/10/04/authorization-code-reuse/ 
リリースノート
https://docs.microsoft.com/ja-jp/azure/active-directory/fundamentals/whats-new#change-notice-authorization-codes-will-no-longer-be-available-for-reuse

◆アナウンスされた内容

詳しくは上記リンクを見て頂ければと思いますが、ざっくり言うと以下の事項がアナウンスされました。

  • 従来はAzure ADのOAuth2.0/Code Flowで認可エンドポイントから発行される認可コード(Authorization Code。MSの日本語訳だと「承認コード」)の再利用が出来てしまう状態だった
  • RFC 6749に準拠するため、認可コードの再利用を禁止することにした
  • 新たなポリシーはv1/v2の両方のエンドポイントに対して適用される
  • 新たなポリシーの適用は2018年10月10日から開始される
  • ポリシー適用後は認可コードを再利用しようとすると「invalid_grant」エラーが出るので、アクセストークンを取得し直す場合はリフレッシュトークンを利用するように既存のコードを修正すること


◆RFC 6749における認可コードの取り扱い

RFC 6749をみると、認可コードの取り扱いは以下の様に記載されています。

  1. 認可コードは認可サーバーによって許可される. 漏洩のリスクを軽減するため, 認可コードは発行されてから短期間で無効にしなければならない (MUST)
  2. 認可コードの有効期限は最大でも10分を推奨する (RECOMMENDED)
  3. クライアントは2回以上認可コードを使用してはならない (MUST NOT)
  4. もし認可コードが2回以上使用された場合は, 認可サーバーはリクエストを拒否しなければならず (MUST)
  5. この認可コードを基に発行されたこれまでのすべてのトークンを無効化すべきである (SHOULD)
  6. 認可コードはクライアント識別子とリダイレクトURIに紐づく.

出典)OpenIDファウンデーション・ジャパン翻訳WG
https://openid-foundation-japan.github.io/rfc6749.ja.html#code-authz-resp

この3~5番目のあたりですね。

なお、RFCにおけるMUST NOT(してはならない)の定義は「この語句、もしくは「することはない( SHALL NOT )」は、その規定が当該仕様の絶対的な禁止事項であることを意味します。」となっています。(強調は筆者による)
出典)IPA翻訳:RFC において要請の程度を示すために用いるキーワード
https://www.ipa.go.jp/security/rfc/RFC2119JA.html


・・・

「絶対的な禁止事項」って明確に書いてあるのに無視したんですね。
マイクロソフトのアナウンスを見ると、以下の注釈が付いていますので、よく理解せずに実装をしてしまったアプリへの配慮があったということなんだとは思いますが。
「アプリの破損を最小限に抑えるための試みにおいて、このパターンに依存していて、サインインが 1 日 10 回より多いアプリには、例外が与えられてきました。」


ちなみに、同じくRECOMMENDEDになっている2番の認可コードの有効期限はAzure ADでは15分です。

こちらもRFC的な意味合いを見ると「この語句もしくは「推奨される( RECOMMENDED )」という形容表現は、 特定の状況下では、特定の項目を無視する正当な理由が存在するかもしれませんが、 異なる選択をする前に、当該項目の示唆するところを十分に理解し、 慎重に重要性を判断しなければならない、ということを意味します。」(同じく強調は筆者による)とあるので、ちゃんと正当な理由の存在をもって慎重に重要性を判断したんだと信じたいところです。

15分になっている理由として、アナウンスの中の別の文章を見ると、「従来は 15 分間 (10 分間の有効期限に加えて時刻ずれを考慮して 5 分の猶予が与えられている) 有効です」とあります。時刻ずれを考慮したんですね。
ちょっと待て。。。発行から15分という話なら時刻ずれ関係なくないか?認可コードの中にタイムスタンプが埋め込まれている?唯一、Azure AD B2Cが発行する認可コードがJWTっぽいのでデコードしてみましたが、ペイロードがなくタイムスタンプ情報が入っているようには見えないんですが・・・。それとも認可エンドポイントとトークンエンドポイントが別のサーバで動いていて時刻同期がされていない、ということ?うーむ。

◆取り敢えず動作の確認

アナウンスでは10月10日から動作が変わる、ということだったので10月4日の段階で動作を確認してみました。
対象は、v1/v2/B2Cの3パターンです。

v1/v2はChrome ExtensionのAdvanced REST Clientで認可コードをトークンエンドポイントへ何度投げ込んでもIDトークン、アクセストークン、リフレッシュトークンが返ってきます。

15分経過すると有効期限切れのエラーが出ます。10分か15分かは置いておいてこちらは正しい挙動ですね。


尚、Azure AD B2Cの場合はAdvanced REST Clientだと上手く動かないことがあるので(Client Secretに記号が含まれることが多いから?)、Postmanを使って動作確認をします。

ツールは違えど、v1/v2と同じ動きです。


◆10月10日を超えたらどうなったのか?

ということで本題です。
10月10日を超えたので、どのような動きになったのか確認してみましょう。

結論から言いますと、アナウンス通りに認可コードの再利用が禁止されたのはv2エンドポイントだけでした。v1とAzure AD B2Cでは相変わらず認可コードが再利用できてしまいました。何か事情があったんでしょうか。。。

以下、v2エンドポイントで認可コードを再利用した際に出るエラーです。

「OAuth2 Authorization code was already redeemed」ってあるので、ちゃんと再利用だと判断されているようです。



いずれにしても認可コードの再利用を前提としたコードがあれば早めに書き直しましょう。v1/B2Cもそのうち再利用禁止になると思いますので。

Tech Summitでは久しぶりにエンタープライズID(主にAzure ADの裏技)の話をします

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

11月~12月はイベントが立て込んでおり、準備が中々進まない今日この頃です。

こんな予定です。

  • 11/2(金)CTCフォーラム2018@品川
    • LINE@+Azure AD B2Cで新卒採用業務を改善した話し。登録率6倍、ログイン率が2倍、とそれなりの結果が出たので、事例を中心にお話しします。
    • 申込リンク(もう満席ですが・・・)
  • 11/5(月)~7(水)Tech Summit 2018@プリンスタワー東京
    • 細かくはこのポストの中で解説しますが、最近Azure AD B2Cづいていたので素のAzure ADの話を久しぶりにします。といっても正攻法は面白くないので、導入を決めた後に現場で起こるアレコレと裏技的な対応方法について解説します。
    • 出番は7日(水)の昼(ランチセッション!)です。
    • 申込リンク
  • 11/19(月)大学ICT推進協議会(AXIES) 年次大会@北海道大学
    • 大学へのAzure AD B2C + LINE@、Facebook導入の事例の発表です。この時期の北海道は寒そうだなぁ・・・
    • 出番は19日(月)です。
    • 申込リンク
  • 11/20(火)~22(木)Consumer Identity World APAC 2018@シンガポール
    • 海外遠征です。だいぶ慣れてきた?とは思いますが英語が下手なのは相変わらずなので、もう少し練習します。前日まで北海道にいるので、AXIESの出番が終わったら、そのままシンガポールへ移動です・・・
    • 内容はAzure AD B2C+SNSを使ったBYOID(Bring Your Own Identity)の話で、European Identity & Cloud ConferenceやIdentiverseで話した内容+最新のアップデートの予定です。ID on Blockchainを使ったパスワード撤廃みたいな話しやデモもやれるといいな、と思っています。
    • 出番は21日(水)です。
    • 申込リンク
  • 12/3(月)ID&IT for Education@一橋
    • ID&ITの教育機関向けバージョンです。私は慶應SFCの斉藤先生とBlockchain & BYOIDということで、ID on Blockchainの話をします。
    • 申込リンク


というわけで、直近のTech Summitの内容を少し深めに。
タイトルは
「アンドキュメンテッドAzure AD
 ~現場で遭遇する予期せぬ事態と対応~」
ということで、カタログ・スペックではわからないAzure ADの深い話をレベル200(初心者向け)に話すというよくわからないことになっています。(本当はレベル400/上級者向けのつもりだったんですが、色々と手違い?で蓋を開けたらレベル200になってました)



ちなみに、Azure AD Connectに無理をさせたり、Azure AD単体で出来ないことを他者製品と組み合わせたり、と裏技を中心に話す予定なので、録画、スライド公開はNGにする予定です。現場に来られた方だけにこっそりと、という感じです。
(というよりもMSのオフィシャルイベントで堂々と話せる内容じゃないだけです。おいおい本ブログで個別に紹介していくことは出来るネタもあるので、その辺は適当に)


と、言うことで11月~12月はあちこちに出没しますので、会場でお会いしましょう!

TechSummitのおさらい①:Azure ADで非SSLアプリとのSSOを構成する

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

ようやく秋口からのセミナーラッシュが落ち着いてきたので、先日のTechSummitでお話しした非公開ネタを解説していきたいと思います。

内容的にマイクロソフトの公式イベントでお話しするにはあまりにも非サポートだったり、別の会社の製品との組み合わせを紹介しすぎたり、と大人の事情満載だったので当日は撮影禁止&資料・動画公開なしとさせていただいたネタです。

当日お話しした内容は公開可のモノも含めると以下の通りです。


  1. 非SSLな開発環境とSSOを構成したい!
  2. SaaSアプリとのSSO時のトラブルシュートあれこれ
  3. Azure AD Premiumは買えないけど複雑なことをやりたい
  4. SaaSアプリへのプロビジョニングがちょっとアレな話
  5. マルチフォレストのオンプレADとの同期すときのあれこれ
  6. マルチフォレスト構成時のパスワード同期元/先を制御したい!

と、言うことで順番に解説していきたいと思います。
今回は1番目の「非SSLな開発環境とSSOを構成したい!」です。

Azure ADがSSOを構成するアプリはSSLじゃないとダメ!?

すでにAzure ADをお使いの方はご存知だと思いますが、Azure ADを使ったアプリとのSSOを構成するには、アプリをSSL化しておくことが前提となります。
この時に困るのが、開発環境をどうするか?という話です。もちろん余裕のある方は開発環境を含めてSSL化しておくことも可能でしょうし、最近はLet's Encryptなど無償の証明書を発行してくれる機関もあるので、こちらを活用して行くことも可能なのでニーズは減ってきていると思いますが、やはり面倒ということもあり何とか手軽に非SSLな開発環境でもSSOを構成していきたいところです。
※もちろん非SSLな環境を推奨している訳ではありませんので誤解なきよう。。。

非SSLなアプリを構成しようとすると何が起きるか?

先ほど、標準のAzure ADだとアプリのSSL化が前提となっている、という話をしましたが、具体的に何が起きるのか?を先に説明しておきます。
といっても単純にSAMLアプリの場合はAssertion Consumer Service(ACS)、OpenID Connectアプリの場合はReply URIを設定する際にhttpsスキーム以外だと怒られて設定が出来ない、というだけです。


ここで、考えるべきなのは
  • このエラーはUI上でのValidationの問題なのか?
  • それともデータを保存する際のValidationの問題なのか?
ということです。

個人的な経験からすると、Azure ADの構成情報の実体データは割りと素な状態でストアされており、管理者はPowerShellやAPI(そしてオマケとして管理ポータル)で設定を行うという構造になっていますので、今回についてもACS/ReplyURIの元データを何とかして修正できれば目標を達成できるはず、と考えました。

Azure ADにおけるアプリ登録情報の実体

ということで、管理ポータルの存在は一旦忘れて登録されたアプリケーションの構造を生データで見ていきましょう。
まずは一番単純な方法としてPowerShellを使います。※ここは時間の関係でTechSummitでもお話ししなかった部分です。

Azure Active Directory Module for Windows PowerShellを使いますので、インストールしていない人は「Install-Module -Name AzureAD」あたりで先にモジュールをインストールしておいてください。

取り敢えず「Connect-AzureAD」でAzure Active Directoryへ接続しましょう。
次に登録済みアプリケーションの情報を確認するために「Get-AzureADApplication」を実行します。

登録されているアプリがずらりと出てきます。


この中から、構成をしたいアプリケーションを見つけて、ObjectIDを指定して再度「Get-AzureADApplication」を実行して構成情報を確認します。この時、パイプでflをつけると細かいパラメータが見えます。
こんな感じです。
「Get-AzureADApplication -ObjectId xxxxx | fl」

その中にReplyUrlsというパラメータが見えます。

SAMLだろうがws-federationだろうがOAuthだろうがOpenID ConnectだろうがReplyUrlsです。潔すぎです。
この値がSAMLの場合はACSのURL、ws-federationの場合はwreply、OAuth/OpenID Connectの場合はReplyURIですね。

PowerShellを使って値を変えてみる

アプリの構成を取得するときに使ったのが「Get-AzureADApplication」なら構成を変更するときに使うのは「Set-AzureADApplication」です。

ただ、このReplyUrlsは配列で値が入るので、セットしたい値は配列としてセットします。PowerShellの場合は「@("値1","値2")」という形式が必要です。

ということで、
「Set-AzureADApplication -ObjectId {アプリのGUID} -ReplyUrls @("http://{ACSのURL}")」
をしてあげます。

以上、終了です。

先ほどと同様にGet-AzureADApplicationで確認するとちゃんとhttpスキームでReplyUrlsが登録されていることがわかります。もちろんデフォルトのhttpsを残したままhttpのモノを追加してもOKです。単純に配列に値を追加すれば良いだけですので。

結果、非SSLなアプリケーションへもSSO出来るようになりました。


管理ポータルでも構成が出来る

どうしてもPowerShellに抵抗がある人は手を挙げてください。
はい、実は管理ポータルでも構成変更が出来ます。
(こちらがTechSummit当日にご紹介した内容です)

やり方は登録されているアプリのマニフェストを直接編集します。
変更する内容はPowerShellの場合と同じく、ReplyUrlsの値です。





スライドにも書いてありますが、ここを変えても元々のエンタープライズアプリケーションのSSOの設定の表示が変わるわけではありません。


取り敢えず今回は一つ目の話を解説しました。
2つ目以降についても順次紹介していきたいと思いますので、しばしお待ちください。


TechSummitのおさらい②:Azure ADとSaaSアプリのSSO構成時のトラブルシュートあれこれ

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

前回に引き続きTechSummitのフォローアップです。

今回は2つ目のネタ「SaaSアプリのSSO構成時のトラブルシュートあれこれ」についてです。

簡単に言うと、同じ種類のSaaSアプリを複数インスタンス(例えば本番環境と開発環境とか)を単一のAzure ADとSSOの構成をしようとすると動きがおかしくなる「ことが」ある、というお話しです。

よくあるシーンはこんな感じで、本番・開発の2環境を用意したいけど、Azure ADってテナント毎、ユーザ毎のライセンスなので出来ればAzure ADは単一の環境で済ませたいよね、っていう話です。

TechSummitでは個人的な経験を基に、G Suiteを複数インスタンス用意してSSOを構成しようとしたとき、たまに発生する問題を紹介しました。
※ちなみにSalesforceでも起きることがあるようですが、すべてのアプリで発生するわけではありません。また、G Suiteでも毎回起きるわけではありません。

何が起きる(た)のか

先ほど書いたように、毎回起きるわけでもなく、発生条件も良くわからない状態なので、ここに書いたことが必ず起きるわけでもなく、他に発生する問題がある可能性もありますが、とりあえず私が体験したことを書いていきます。

  • NameIDの値のマッピングが上手くいかない(UPNを使ってくれない)
  • SP EntityIDが一致していない、と言われる


NameIDのマッピング不良と対策

まずは前者です。
初期状態のAzure ADはG SuiteのSSO構成時、NameID属性としてuserPrincipalName属性をマッピングします。また、G SuiteのNameID Formatの指定はunspecifiedです。

通常、この構成だとAzure ADはuserPrincipalNameの値をそのままG Suiteへ渡すのですが、なぜか仮名が生成されてNameIDとして渡されてしまうことがあります。通常はNameID FormatがTransientやPersistent以外は仮名が生成されることは無いはずなのですが、何かがおかしいです。


これを解消しようとすると、Azure AD側のでNameID Formatを明示的に指定してあげる(つまり、G Suiteからの指定を無視する)必要があります。
G Suiteはメールアドレス形式でNameIDの値が飛んでくるのを期待しているので、NameID Formatをemailaddress(電子メールアドレス)にしてあげます。


これでうまくいきます。


SP EntityIDの不一致

次に、SSOを試みた時に出てくる「AADSTS65005: Misconfigured application」エラーへの対策です。このエラーはAzure AD側でアプリケーション構成がおかしいので見直せ!というエラーです。


最近はAzure ADのSSO構成も人にやさしくなっており、エラーの詳しい原因が管理ポータルからある程度確認できるようになっています。(Salesforceが昔から実装していた機能ですね)
これまでSAMLのやり取りをトレース&解析しないとダメだったのですが、この機能が出来てかなり楽になりました。

この機能を使って先のエラーの原因を探ると、なぜかSP EntityID(要するにアプリケーションを一意に識別する情報)がマッチしていない、と言われます。どう見ても一致してるんですが・・・
もちろんアプリケーションが一つしか構成されていない状態ではこのようなことは言われないのですが、G Suiteを複数インスタンス構成するとタマにこのエラーが出ます。
※ちなみに昔はもっとひどかった(構成するとユーザの割り当てが混ざったりしていた)ので、マシにはなったんですが・・・


実はこのエラーが出ると、Azure AD側ではどうしようもなく、強引に複数のG Suiteインスタンス間でEntityIDが絶対に重複しない様に構成を工夫するしかなくなります。
今回やったのは、片方のG Suiteについて、Google側でEntityIDにドメイン固有情報を含めるのを辞める、という苦肉の策です。
これで複数のG Suiteインスタンス間で必ず異なるEntityIDが使われるようになるので、問題が解決します。(本来はこんなことをしなくても必ず異なるEntityIDは使われるんですが)



まぁ、今回紹介したものは発生することもある、というレベルなので仕組みを理解した上で適度に使ってもらえれば、というレベルの話でした。

引き続きフォローアップをしていきますので、お楽しみに。


TechSummitのおさらい③:Azure AD + Auth0 で条件付きアクセスを構成する

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

そろそろディープになってきました。公式イベントで話すにはかなり気が引けるネタ度Maxです。

今回はAuth0(おーすぜろ)とAzure ADを組み合わせることで複雑なことをやろう!という話です。

もちろんAzure ADにはPremium P1/P2という複雑なことをやりたい人向けのプレミアなライセンスがありますので、お金に余裕のある方、一気通貫でサポートを頼みたい方は迷わずそちらを選んでください。

Auth0とは?

Auth0もMicrosoftやOkta、PingIdentity、OneLoginなどと同様にIDaaS(Identity as a Service)を提供しているサービスプロバイダです。jwt.io辺りで有名ですね。
ちなみにFounderは元マイクロソフトのEugenio Paceです。「A Guide to Claims-Based Identity and Access Control」をVittorio Bertocciと一緒に書いた人ですね。まだ彼がMSにいる時代にやり取りをしてサイン本をもらったりしたもんです(遠い目)。最近は共著のVittorioもAuth0へ移ったのが個人的なビッグニュースでした。

少し特徴的なのは「開発者向け」である、という売り出し方をしているところですね。開発者向けたる所以は、ひたすらかゆいところに手が届くから、というのが最大の理由だと思います。

このAuth0、実は別のサービスとしてWebtaskというFaaS(Function as a Service)を提供しており、ID関連の機能の各所にこのWebtaskをどんどん差し込んでいくことが出来るんです。このことにより、例えばid_tokenの中身を見て処理を実行したり、ID登録直後に別の処理を走らせたり、など開発者がやりたい放題出来てしまいます。


Azure AD + Auth0?

さて、Azure ADとAuth0を組み合わせると何が出来るのか?という話に移りたいと思います。
Auth0はAuth0自体にIDを保持して自身がIdPとして振舞う以外に、外部のIdP(Connectionと呼んでいます)とID連携する機能を持っています。また、当然のごとく外部のSPとID連携することもできます。
このことを使い、IDの保持とベーシックな認証機能はAzure ADで、複雑な処理(今回は条件付きアクセスと多要素認証)はAuth0で担当、というようなことを実現することが出来ます。
使えるプロトコルも多様なので、アプリ(今回はG Suite)とAuth0の間はSAML、Auth0とAzure ADの間はOpenID Connect、という構成を組んでみました。


Azure ADのアプリ(RP)としてAuth0を登録

早速構成していくわけですが、まずはAuth0の外部IdPとしてAzure ADを構成するためには、Azure ADのRelying Party(RP)としてAuth0を登録してあげる必要があります。具体的には、ReplyUrl(応答URL)にAuth0のエンドポイント(Callback)を登録し、Auth0側に設定するためのClient IDとClient SecretをAzure ADから払い出します。

Azure ADのアプリ登録メニューより登録を行います。
 Azure ADに登録するAuth0のCallback URLは以下の通りです。
  https://{テナント名}.auth0.com/login/callback


Auth0の外部IdPとしてAuth0を登録

次は、逆側の設定なので、Auth0にAzure ADの情報を登録していきます。
ちなみにAuth0はビルトインのConnectorとしてAzure ADが用意されているので、こちらを使ってもいいですし、OAuthを使ってカスタム接続するためのExtensionもあるのでこちらを使って接続しても問題はありません。

こちらがビルトインのAzure ADとの接続Connector

こちらがOAuthを使うExtension


私は後者のExtensionを使っています。(というかビルトインでAzure ADが存在しているのを知らなかった・・・)
Azure ADの認可エンドポイント、トークンエンドポイントと先ほどアプリ登録した際に取得したClient IDとClient Secretを登録します。

ちなみに、例のWebtaskを使ってGraph APIでAzure AD上のユーザ情報を取得することが出来ます。SAML Assertionに属性を入れてアプリに渡す必要があるので、必要な属性を取得する様にスクリプトを作ります。
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);
});
}


直観的にわかりやすいスクリプトだと思うので、あまり解説する必要もないとは思いますが、トークンエンドポイントから取得したアクセストークンがコンテキストとコールバック先のオブジェクトと一緒に渡ってくるので、Graph APIにアクセスして必要な情報を取得、Profileとして設定して返却してあげる、という流れです。

G SuiteとAuth0をID連携

ここはこれまで何度となく解説してきたG Suiteのシングルサインオン設定の世界なので、G Suite側は目をつぶっていても構成できてしまう世界だと思いますので、Auth0側の設定を中心に。

ちなみにAuth0にはApplicationギャラリー的なプリセット・アプリのリストは存在しません。めちゃくちゃシンプルにNative App、SPA、Regular Web App、Machine to Machine Appの4種類しかありません。

G Suiteなど通常のアプリを使う場合はRegular Web Appを選びましょう。

また、Regular Web Appを選んだとしてもデフォルトではアプリと言っても単純なOAuthのクライアント登録しか出来ないので、AddOnという形でSAML等のプロトコルを設定してあげる必要があります。
SAMLの設定もかなりプログラマブルなので、Assertion内の各種パラメータをガリガリと書いていきます。本当に痒い所に手が届きます。ほぼ出来ないことは何もないので、Assertionの書き方の方言でうまくアプリと繋がらない、というトラブルとは無縁だと思います。その代わりSAML Assertionの中身の仕様について熟知している必要はありますが。


この構成のページからIdP MetadataやAssertion署名用の証明書のダウンロードなども可能なので、エンドポイントや証明書をG Suite側に設定してあげれば完了です。

これで一通り単純なシングルサインオンについて出来るようになっています。


条件付きアクセスを構成する

ここまでだとAuth0がG SuiteとAzure ADの間に挟まっている必要性が全くないので、最初に書いた通り、条件付きアクセスを構成してみます。
本来Azure ADではPremium P1のライセンスが必要な機能です。

Auth0での条件付きアクセスを構成するには、Rulesメニューよりルールを構成します。
このルールもJavascriptでガリガリと書いていくことが出来るので、ものすごく柔軟です。アクセス元の状態はContextから取得できるので、ソースIPやUser Agentなど様々な情報を見て多要素認証の適用の有無など各種条件を設定することが可能です。
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);
}


ここまで構成すると社内アドレス以外からG Suiteを使おうとすると多要素認証(今回はGoogle Authenticator)を要求される様になります。



こんな感じでAzure AD+Auth0で見た目はぼぼAzure AD Premiumの条件付きアクセス、ということが実現できてしまいました(笑)。

まだまだネタは続きます。では次回!

TechSummitのおさらい④:Azure ADからSaaSアプリへのプロビジョニングのアレコレ

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

引き続き、TechSummitのおさらいをしていきます。
今回はAzure ADからSaaSアプリへのプロビジョニングの話しです。

Azure ADからプロビジョニングできるアプリケーションの条件は以下の通りです。

  • ギャラリーに掲載されていてプロビジョニングに対応しているもの
  • SCIM2.0に対応しているもの

現状(2018年12月現在)ギャラリーに掲載されているアプリは3,057個で、プロビジョニングに対応しているのは30個ですので、やはりプロビジョニングはハードルが高いですね。
こちらが一覧です。


サービス名
Amazon Web Services (AWS)
Asana
BlueJeans
Bonusly
Box
Cerner Central
Cisco Spark
Concur
Cornerstone OnDemand
DocuSign
Dropbox for Business
G Suite
GitHub
GoToMeeting
Jive
LinedIn Elevate
LinkdIn Sales Navigator
Lucidchart
Netsuite
Pingboard
Salesforce
Salesforce Sandbox
Samanage
ServiceNow
Slack
Tableau Online
ThousandEyes
Workday
Workplace by Facebook
Zendesk

ここに記載がないアプリケーションの場合や自分で開発しているアプリケーションの場合は、SCIM2.0に対応していればある程度対応させることが出来ます。
ちなみに、以前はSCIM2.0に対応している、かつ「Azure ADでSCIMのエンドポイントの保護をしていること=Azure ADが発行したアクセストークンで認可されること」という縛りがあったのですが、最近カスタムのアクセストークンでもアクセスできるようになりました。(Azure AD上へ固定で設定する必要があり、自動リフレッシュなどもできず微妙ですが)

このシークレットトークンにカスタムのアクセストークンを指定します。指定しなければ従来と同じく、Azure ADで発行されたアクセストークンを使ってAPIへアクセスします。


さて、本題です。
TechSummitでは実際にプロビジョニングをやってみると起きる問題についてG Suiteとの連携を例に解説しました。

もちろんすべてのアプリケーションで発生する問題ではありませんが、ざっくり言うと、

  • 複雑な同期ルールは設定できない(例えば、人事発令後7日以内は所属を新旧で兼務させる、などは無理)
  • プロビジョニング設定をしてテスト接続をして保存するとエラーが出てどうしようもなくなる(これはG Suite限定かもしれませんが)
  • 標準外の属性を定義してマッピングしても同期されない(これもアプリに依存)
のような話があり、カタログスペック的にプロビジョニングに対応してるから使える!と思い込むと痛い目にあいます。

すこし具体的な例とワークアラウンドを含め紹介していきます。

プロビジョニング設定時にエラーが出てどうしようもなくなる件

先にも書いた通り、G Suite限定かもしれませんが、プロビジョニング設定をして保存をした時にエラーが出ることがあります。しかも、このエラーが出てしまうと二度とプロビジョニング設定を行うことが出来なくなります。

どうやら、既知の問題らしく、ワークアラウンドとしてSSO用のGSuiteとプロビジョニング用のG Suiteを分けて定義すると上手く動くんですが、アプリケーションへのユーザの割り当てなど結構面倒くさいです。


追加属性のマッピングが上手く反映されない

これも良くある質問で、アプリケーションの種類にかなり依存する話っぽいです。
例えば、経験上ServiceNowなんかはある程度カスタム属性をマッピングしても動いてくれましたが、G Suiteは全くダメです。
しかも、実環境でよく使われるOU(orgUnitPath)が上手くプロビジョニング出来ないのは致命的でgithubでも昔からissueが立っているくらいです。


同じく、G Suite側で作ったカスタム属性も全く無視されちゃいます。


では、どうするのか?

使えないから諦められるのか?という話になりますが、Azure AD自体のプロビジョニング機能を使うのは、現状ある程度割り切った環境でないとあきらめた方がベターです。

ということで、
  • Azure AD ConnectをMIM的につかう(カスタムMAを使う)
  • Azure FunctionとGraph API Subscriptionを使って自前プロビジョニングする
の2択が現実的です。
※開発を伴うので、サポートをどうするかを含め熟考の上で使ってください。

Azure AD Connectの魔改造

まぁ、みなさんご存知のとおりAzure AD Connectの実体はMIM(Microsoft Identity Manager)です。しかもAzure AD ConnectにはSynchronization Rules Editorが付属しており、かなり優秀なので、MIMにもこのエディタをバックポートしてくれないかな、と本気で思います。

話しがそれましたが、実体がMIMなのでMIM用に作ったカスタム管理エージェントを組み込むとほぼ何でもできます。


ちなみに、MIMとAzure AD Connectではインストール時のフォルダ構成が異なるので、管理エージェントを後から組み込む場合はAzure AD Connectに合わせてバイナリを移動してあげる必要があります。

後は、先のSynchronization Rules Editorで同期ルールを書けばうまく動くようになります。

Graph APIのSubscriptionを使う

別の方法はGraph APIのSubscriptionを使う方法です。
SubscriptionとはAzure AD/Office365上のオブジェクトに特定のイベントが発生した時に外部のAPIへWebhookを飛ばす機能です。
通常はOffice365のメールボックスにメールが配信されたら外部APIを叩く、などといった使い方をするのですが、Azure AD上のユーザに更新がかかったら変更内容を通知する、という使い方をすることでプロビジョニングに応用できます。
ちなみにプロビジョニング処理自体はAzure Function等を使って完全に自前で実装することになります。

Subscriptionを作成する際もGraph APIを使います。
対象のリソース(users)と検知対象のアクション(updated)、Webhook通知先URLを指定してSubscriptionを作成します。

尚、現状だと検知対象のアクションとしてcreatedやdeletedを指定するとエラーが出るのでupdatedしか使えません。作成と削除はAzure ADのプロビジョニング機能を使い、更新はSubscription経由で実施する、という構成にしないといけません。

ちなみに作成したSubscriptionオブジェクトの有効期限は最大3日間なので、期限が切れる前に更新をしないと自動的に削除されてしまいます。


Subscriptionが有効な状態でユーザオブジェクトに更新がかかると指定したURLに対してWebhookが飛んできます。
この内容をパースして適切な処理を行いましょう。G Suiteの場合はAdmin SDKを使ってG Suite上のユーザの属性を更新する、などの処理ですね。



今回はこのくらいです。
プロビジョニングは結構鬼門なので、使う場合は十分に事前調査~準備をしてから使い始めるようにしてください。

Auth0でLINEログインを行う(メールアドレスの取得も)

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

Auth0楽しいです。
LINE Loginも楽しいです。

と、言うことでAuth0を使ってLINE Loginを実装してみます。

ちなみに、Auth0の古田さんが以前書いていらっしゃるQiitaを見ればそのままなんですが、メールアドレスが取れない!という課題が解決していないので、そのあたりもカバーしてみます。

古田さんのQiita:Auth0でLINEログインを実装してみた(v2.1対応)
 https://qiita.com/furuth/items/6df4334c3821ffc69d9c

ざっくり解説すると以下のとおり実装します。細かい手順は古田さんのQiitaを見てください。

  1. Auth0のExtensionの「Custom Social Connections」を使う(流石にLINEはビルトインされていない)
  2. LINE側に登録したClientID、ClientSecretをAuth0のExtensionに設定する
  3. Auth0のExtensionは基本的にOAuthなので、ユーザ属性はLINEのProfileエンドポイントから取得する

LINEの場合、この3番が曲者ですね。
以前、紹介したとおり、LINE Loginでメールアドレスを取得できるようにはなりましたが、あくまでid_tokenの中に入っており、Profileエンドポイントからは取得できないんです。

以前のポスト


と、言うことでAuth0のExtensionの中のプロファイル取得スクリプトでなんとかするしかありません。

が、このプロファイル取得スクリプト、先に書いた通り、OAuthな前提なので、access_tokenを基にProfileエンドポイントへアクセスして属性を取得するようなサンプルしかありません。

今回はここでid_tokenをとってきて中からメールアドレスを取り出したいので、以下のようにスクリプトを書き換えます。access_tokenは使いません。
function(accessToken, ctx, cb) {
var i = JSON.parse(jwt.decode(ctx.id_token));
var p = {
user_id: i.sub,
name: i.name,
picture: i.picture,
email: i.email
};
cb(null, p);
}

ちなみに、LINEが返してくるid_token(JWT)はヘッダにtyp: JWTの記載がないので、node.jsのjsonwebtokenライブラリがうまくjsonオブジェクトに変換をしてくれず、stringで結果が返ってきてしまします。そのため、2行目でJSON.parseをつけてjsonオブジェクトに変換しています。
※Azure ADなどの場合はtyp: JWTがヘッダにあるので、JSON.parseは不要でした。jwt.decodeの第2引数にjson: trueってつけるとうまいことやってくれる、というドキュメントは見たことがあるんですが、今回は上手く動きませんでした
※場合によってjwt.decodeで怒られることがあるみたいなので、その場合は
 var jwt = require('jsonwebtoken');
 を追記してみてください。

Tryボタンで動作確認ができ、ログインするとこんな感じでid_token内の属性が取得できます。



Google+のサービス提供終了に伴うbloggerへの影響と本ブログにおける対応

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

先日アナウンスされた通り、2019年4月でGoogle+のサービス提供が終了しますね。

ご存知の通り、本blogはGoogleが提供しているbloggerを使っているので、何か影響があるのか調べてみました。
結果、個人的にはそれほど大きな影響ではなさそうなので、放置することにします。

■Googleからの発表内容と本ブログへの影響

2018年12月の発表、およびその後のメールなどによると、影響と対策は以下の通り。
※赤字部分が自身、本ブログに影響がありそうなところ
※今後アップデートがある可能性もあるので、一次ソースを見て対策をしてください。(本ポストの内容により影響が出ても責任はもてません)

  • 個人のGoogle+アカウントを持っている人、Google+ページを持っている人
    • 2019年2月4日
      • 新規にGoogle+プロフィール、ページ、コミュニティ、イベントの作成ができなくなる
      • 対策)特になし
    • 2019年4月2日
      • Google+アカウント、ページ等のコンテンツの削除を開始
      • 対策)コンテンツのダウンロードと保存をしておくこと(Googleフォトは消えないので大丈夫)
  • Google+コミュニティのオーナー、管理者の人
    • 2019年3月上旬〜
      • コンテンツのダウンロードと保存が可能になる
      • 対策)ダウンロードしておくこと
  • Google+ログインのボタンをサイトやアプリに配置している人
    • 今後数週間
      • ボタンが機能しなくなる(Googleログインのボタンが代わりに表示されることもあり)
      • 対策)ボタンの撤去。Googleログインのボタンが表示された人はそのまま使える(Googleアカウントでログイン)
  • Google+を使って自身のサイトや他のサイトへコメントを追加している人
    • 2019年2月4日
      • BloggerでGoogle+を使ったコメント機能は使えなくなる
      • 対策)他の機能でコメントする
    • 2019年3月7日
      • 他のサイトでGoogle+を使ったコメント機能は使えなくなる
      • 対策)他の機能でコメントする
    • 2019年4月2日〜
      • 既存のGoogle+で作成されたコメントが順次削除される
      • 対策)ダウンロードして保存しておくこと
  • G Suiteを使っている人
    • ビジネス向けGoogle+はサービス継続(新機能追加、デザイン変更あり)
    • ただし、G Suiteアカウントが外部Google+ユーザと共用しているページやコミュニティ、サークルなどについては一般向けGoogle+と同様に影響を受けるので対策は必要
    • 詳細はこちら
  • Google+ APIを使っている人(開発者)
    • 2019年3月7日
      • 全てのGoogle+ API(Google+ REST APIなど)が停止
      • Google+に関連するscope(例えば、plus.meやplug.login)を使った認可リクエストも受け付けられなくなるので注意

■本ブログにおける対応

特に大きな影響はないので、基本方針は「放置」とします。

一部影響があるのは以下。

  • プロフィール(私のプロフィール)
    • 対策)Bloggerプロフィールに戻します





  • コメントとリンク(そんなに使っている人もいないと思いますが)
    • Google+アカウントでのコメントは使えなくなります
    • 過去にGoogle+でコメントした人のコメントは消えます(特にこちらでバックアップ、どこかへ移行・公開はしません)
    • Google+への共有はできなくなります




まぁ、大部分の方には影響ないですね。

[LINE Login]QRコードログインでメールアドレスもパスワードも不要に!

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

ついにLINE LoginがブラウザシナリオでのQRコードログインをサポートしました!
このことにより、LINEへのメールアドレスとパスワードの登録がない人でもPCのブラウザやスマホの標準ブラウザ以外でWebアプリへのLINEログインできるようになりました。
(永らく待ち望んでいた機能なのでとっても嬉しいです)

公式アナウンス
 https://developers.line.biz/ja/news/tags/line-login/


■従来の制限(ブラウザシナリオ)

従来もQRコードログインはPCやMac、iPad用のLINEアプリへのログインには使えていましたが、PCブラウザやスマホでも標準ブラウザ以外でLINE Loginを使ったWebアプリへアクセスすると、メールアドレスとパスワードを使ってログインする必要がありました。

もちろんスマホの場合はLINE Loginの自動ログイン機能が使える環境であれば、ブラウザからLINEアプリが呼び出されて自動的にログイン、ブラウザへ制御が戻る、という流れでメールアドレス・パスワードを使わないログインが実現できていました。

しかし、この自動ログイン機能はカスタムスキームを使ってLINEアプリを呼び出すところまではOKなのですが、標準以外のブラウザだとLINEアプリからブラウザへの戻す時に戻し先ブラウザの制御を行うことが出来なかったため、標準ブラウザの場合に制限されていました。
ということで、自動ログイン機能を使う場合は、以下の制限があります。
  • iOSの場合
  • LINE 7.5.0未満:アプリ内ブラウザで、LINEログインv2を実装したウェブサイトにアクセスすると、自動ログインできます。
  • LINE 7.5.0以降:アプリ内ブラウザまたはSafariブラウザで、LINEログインv2を実装したウェブサイトにアクセスすると、自動ログインできます。 
  • LINE 7.12.0以降:アプリ内ブラウザまたはSafariブラウザで、LINEログインv2またはv2.1を実装したウェブサイトにアクセスすると、自動ログインできます。 
  • Androidの場合
  • LINE 7.14.0未満:アプリ内ブラウザまたはChromeなどの外部ブラウザで、LINEログインv2を実装したウェブサイトにアクセスすると、自動ログインできます。 
  • LINE 7.14.0以降:アプリ内ブラウザまたはChromeなどの外部ブラウザで、LINEログインv2またはv2.1を実装したウェブサイトにアクセスすると、自動ログインできます。
  • 出典)https://developers.line.biz/ja/faq/


    ■QRコードログインが付かなかったことによる制限

    新規にLINEアプリを登録する時、SMSさえ通じればメールアドレスの登録は必須ではなく、パスワードも不要なため、スマホ・ネイティブな世代の殆どがメールアドレスもパスワードも登録しない状態でLINEの利用を開始していると思われます。
    もちろん、LINEもアカウントのリカバリの容易さなどを理由にメールアドレスとパスワードの登録を推奨していましたが、現実問題登録していないアカウントもそれなりの数、存在していました。(数字は言えませんが)

    上記の制限事項もあり、LINE Loginをブラウザシナリオで実装する際は、ある程度の数「使えない」ユーザが存在することを前提に設計を行う必要がありました。

    以前よりLINEさんにはブラウザでもQRコードログインをサポートしてもらえるようにお願いはしていたのですが、ようやく実現した!!というのが今回の発表です。

    ■早速使ってみる

    では、早速使ってみます。(といっても見た目は地味ですが)

    LINE Loginを使うWebサイトにアクセスするとLINEへリダイレクトされます。
    (ちなみに、QRコードログインを使うには、LINE Login v2.1を使っている必要があります)

    ログイン画面が変わっています。下の方に「QRコードログイン」がみえます!
    早速クリックすると、QRコードが表示されます。(一部マスクしています)

    おもむろにスマホを取り出してQRコードをスキャンします。
    (友達追加の時に使うアプリ内のQRリーダーを使います)

    ログイン確認をされるので、ログインボタンをタップします。
    すると、ブラウザに認証番号が表示されるので、スマホ側で数字を入力します。

    ここで入力します。


    問題なく確認が終わると、ブラウザ側でログイン処理が完了、アプリへ遷移します。



    ということで、メールアドレスもパスワードも使わずにアプリケーションへのログインができるようになりました!
    Microsoftアカウント、Yahoo! JAPANのパスワード・レス・ログインに続いてLINEも同体験を実現してきており、ようやく人類がパスワードを捨てることが出来る日がくる予感がしてきました。

    [LINE Login]LINE Developer CommunityでOpenID Connect(+少しAzure AD B2C)の解説をしました

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

    そういえば去る3/8にLINE Developer Communityの勉強会でLINE Loginを題材にOpenID Connectの解説をしてきました。(公開資料にはのっけてませんがちょっとだけAzure AD B2Cの話しもしました)

    どうもアイデンティティの分野って概念と実装の両方を勉強しないとちゃんと理解できないことが多いので、座学+ハンズオンみたいな感じで勉強する形があっているんじゃないかな?と思っています。

    資料とコードはこちらに公開しています。


    コード
    https://github.com/fujie/line_login

    今回はOpenID Connectの基本的な流れを理解してもらうことが目標だったので、特にLINE LoginのSDKも使いませんでしたし、サンプルコードもステップ by ステップでストップしながら流れを理解してもらうことを想定したものなので、プロダクション環境ではくれぐれも使わない様にしてください。。。

    ひっそりと申込を開始した割にすぐに定員が埋まってしまったのと最終的にキャンセル待ちが参加できた方の数と同じくらい存在したので、2回目以降の開催も考えていかないとダメですね。(どうしてもハンズオンを入れると1回あたりの人数が絞られますし)

    ということで乞うご期待。


    早くもクラスメソッドの方がレポートを書いて頂いておりました。感謝です。
     [レポート] 実装して理解するLINE LoginとOpenID Connect入門 に参加してOAuthとOpenID Connectについても学んできた #linedc
     https://dev.classmethod.jp/report/mrmo-linelogin-20190315/

    [Azure AD B2C] Custom Policyが遂にGA!

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

    Public Preview開始から約2年、ようやくAzure AD B2CのCustom Policy(Identity Experience Framework)がGAしました。


    公式アナウンス
     Azure AD B2C custom policies to build-your-own identity journeys reaches general availability
     https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Azure-AD-B2C-custom-policies-to-build-your-own-identity-journeys/ba-p/382791

    といっても何のことか、という方もいらっしゃると思いますので、簡単に。

    Azure AD B2Cには
    ・ビルトインポリシー
    ・カスタムポリシー
    の2種類があります。

    ざっくりいうと、ビルトインポリシーで出来るのは、
    ・プリセットされた外部IDプロバイダ(FacebookとかTwitterとか)の利用
    ・サインアップ、サインイン、プロファイル変更、パスワードリセットというアクション
    ・OpenID Connectを使ったアプリケーションへのID連携
    です。

    まぁこれでも十分と言えば十分なのですが、カスタムポリシーを使うことで、
    ・プリセット以外の外部IDプロバイダの組込み(LINEとかYahoo! JAPANとか、SAML IdPとか)
    ・複雑なアクション(複数のIDプロバイダのIDの紐づけとか、外部のREST APIの呼び出しとか)
    ・SAMLなどOpenID Connect以外のアプリへのID連携
    など、割りとなんでもできてしまいます。

    もちろん、今回のGAでカスタムポリシーのすべての機能がGAしている訳ではありませんが、Azure AD B2Cを使って出来ることが大幅に広がりました。

    ※現状のリリース状況(Preview/GA)はこちらから確認できます。
    https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-developer-notes-custom

    まだまだドキュメント等、充実しているとは言えませんが、今後に期待です!



    [Azure AD B2C]各種エンドポイントにつくポリシー指定用パラメータが邪魔な件

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

    完全に自分メモです。
    Azure Active Directory B2Cって色々と器用なことが出来るのですが、その動作はポリシー(ユーザーフロー)という単位で定義され、クライアント(アプリケーション)から呼び出されます。
    図)標準のポリシー(ユーザーフロー)定義

    図)カスタムポリシー

    サインアップとか、サインインとか、プロファイル編集などなど、各種動作を統一されたエンドポイントで実行するために、このポリシーを各種エンドポイントを呼び出す際、「https://hoge.b2clogin.com/hoge.onmicrosoft.com/oauth2.0/v2.0/authorize?p=B2C_1_XXXX」のようにクエリパラメータにp=ポリシー名という形でポリシーを指定して動きを変えていきます。

    ※ちなみにポリシー名のPrefixは、
    ・標準ポリシー(ユーザーフロー)だと、「B2C_1_XXX」
    ・カスタムポリシーだと、「B2C_1A_XXX」
    です。

    しかし、OAuthやOpenID Connectの非MS製ライブラリを使うとき、かなりの確率で問題になるのが、エンドポイントにクエリパラメータが付いた状態がスタート、というところです。

    なぜなら、よくあるライブラリにはエンドポイントアドレスを設定、client_idなど各エンドポイントへのアクセスを行う際にクエリ指定するパラメータは個別に指定、ライブラリが自動的に
     https://hogehoge.com/oauth2/authorize?client_id=aaa....
    みたいに連結して動こうとするため、最初からエンドポイントアドレスにクエリが付いているAzure AD B2Cだと、
     https://hogehoge.com/oauth2/authorize?p=B2C_A_xxx?client_id=aaa....
    のように?をつけてしまったりするんです。※本来はもともとパラメータが付いているので、追加パラメータは&で繋いでほしいのですが、想定されてないのだと思います。


    ということで、今回はAzure AD B2Cのエンドポイントアドレスにクエリパラメータを使わない方法の紹介です。

    といっても単純に以下を使うだけです。
    (.well-known/openid-configurationのアドレスです。これを叩けば対応するauthorizationとかtokenエンドポイントのアドレスが取れます)

    ドメインデフォルト(パラメータあり)パラメータ無
    b2cloginhttps://テナント名.b2clogin.com/テナント名.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=B2C_1_ポリシー名https://テナント名.b2clogin.com/tfp/テナント名.onmicrosoft.com/B2C_1_ポリシー名/v2.0/.well-known/openid-configuration
    onmicrosoft(非推奨)https://login.microsoftonline.com/テナント名.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=B2C_1_ポリシー名https://login.microsoftonline.com/te/テナント名.onmicrosoft.com/B2C_1_ポリシー名/v2.0/.well-known/openid-configuration


    エンドポイントアドレスがかなり長いですが、既存のクライアントとの連携などを行う場合は、こちらを使った方がベターです。

    自己主権型アイデンティティとブロックチェーンの話し

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

    ちょうど先日のidconでこの辺りの話をしたので、少し自分のためのおさらいの意味も込めて整理しておこうと思います。

    まず背景として、昨年度から理事を務めさせていただいているOpenIDファウンデーションジャパンで、本人確認に関する新しいワーキンググループである「KYC(Know Your Customer) WG」を2019年1月に立ち上げ、WGリーダーを務めさせていただいております。
    WGでは犯罪収益移転防止法や携帯電話不正利用防止法など各業界における本人確認のルールの調査や、Decentralized Identifier(DID)などの最近KYCと関連づけて語られる技術の調査をしたりしている訳です。
    ちょうどパスポートの真正性確認に使う公開鍵を外務省が公開する・しない、という話が盛り上がっているあたりの領域です。

    本人確認とアイデンティティとブロックチェーン

    そして、何故かこの領域になると、自己主権型アイデンティティ(Self Sovereign Identity/SSI)とか、先ほど出てきたDIDだ、とかいうキーワードがどこからともなく持ち上がってきてやたらとブロックチェーンが銀の弾的に扱われてしまう、というのがID業界?の中の人としても結構な謎だったりするわけです。

    そもそもブロックチェーンを仮想通貨以外にも適用しよう、という話は数年前からあり、例えば2016年のCloud Identity Summit 2016(CIS、現Identiverse)でもPingIdentityがSwirds社と提携してセッションの正当性の管理にHashgraphを使うPoCをやったりしていました。以前このブログでも少し紹介しましたね。

    また、自己主権型アイデンティティという話もUser Centric IdentityとかDoc Sealsが提唱したIntention EconomyのVRMという形で以前からあった文脈と繋がっているものだと思われますので、特にブロックチェーンの出現によって新たに出現した話ではありません。

    そして、当然の事ながら本人確認とブロックチェーンにはかなりの距離があります。ブロックチェーンが出てきたから本人確認が劇的に変わるわけでもなさそうですし。

    ブロックチェーンで解決できるアイデンティティにまつわる課題とは?

    となると、結局ブロックチェーンをアイデンティティの領域に応用することで何がうれしいんだろうか?という話になるわけですが、よく出てくる話としては、

    • プライバシーの保護
    • アイデンティティの証明

    あたりがメジャーなのかな?と思います。他にも先のPingIdentity+Hashgraphでシングルサインオンのセッション管理を分散データベースとしてのブロックチェーンで行うことでシングルログアウト問題を解こうとした、というような話はありますがいまいち普及していません。(わかりやすいユースケースだったので個人的には良かったと思うのですが)

    それぞれの話題を見ていくと何か見えてくるのか?と思うのですが、まだブロックチェーンの必然性が見えてきていないな、というのが個人的な感覚です。

    プライバシーの保護とブロックチェーン

    ここはまさに自己主権型アイデンティティという話なわけですが、課題意識としては、「個人が自分の意思でコンテキストに応じた自己像を提示できるようにする」、そして「個人の意思に反してコンテキスト外の自己像を推測されたり形成されたりしたくない」という話なので、必要なこととしては、

    • ユーザがアプリケーション(Relying Party)へログインする際に、Identity Providerへ認証要求を行うことによる、Identity Providerによるユーザ行動の把握を防ぎたい
    • ユーザがアプリケーション毎に提示するアイデンティティを選択的に形成したい(要はどの属性を渡すか、もしくは値そのものを渡さなくてもアプリケーションが要求している属性を満たすことを証明する)
    • アプリケーション同士が結託することで属性を補完しあって提示するつもりのないアイデンティティを勝手に形成されることを防ぎたい

    というようなことなわけです。

    こうなってくると、ブロックチェーンというよりもゼロ知識証明とか仮名(SAMLのnameid-formatのtransientとか、OpenID Connectのsub_type=pairwise)の方がしっくりくる領域です。今更ながら2012年くらいに盛り上がったU-ProveとかIdentity Mixerバンザイです。そういえば昔Kantaraのセミナで話したなぁ。

    アイデンティティの証明とブロックチェーン

    一方でアイデンティティの証明をするためにブロックチェーンを、という話については見方によってはある程度芽はあるのかもしれません。
    ブロックチェーンの「一度記録すると変更しにくい」といういわゆるImmutabilityの特徴を考えると、一度発行した属性を過去にさかのぼって改竄する、というような属性値ロンダリングみたいな話は難しくなるのかもしれません。

    経済産業省が主催で2月に開催されたブロックチェーン・ハッカソン2019では学位や職歴をブロックチェーンを使って確実に証明できないか?ということがテーマでした(私も審査員+ワークショップの実施という形でかかわらせていただき、非常に面白かったです)。つい先日、調査報告書も公開されたので時間がある方は見てみると面白いです。

    ここはEthereum勢はERC725や735という形でこの領域に注目していて、OriginProtocolがPlaygroudを公開していたりもして、今後も発展していく可能性は十分にあるのかな?と個人的には思います。

    しかし、よく考えると結局はアイデンティティの発行元がきちんと発行したアイデンティティである、ということの担保はこれまでもデジタル署名でしてきたわけで、ブロックチェーンがあるから劇的にこれが改善するわけではありませんし、ブロックチェーン上に発行されたアイデンティティ(属性の値)そのものを全部公開する、というのはあまりにも乱暴なわけです。

    PKIを補完する意味でのブロックチェーン

    そうなるとどうやって落としどころをつくるんだ?というだんだん本末転倒な話の方向に進んでくるわけですが、「あー確かにな」という課題の一つである「アイデンティティの発行元が消滅したり、発行元によってアイデンティティを否認や改竄されるリスクへの対応」というユースケースがにわかに持ち上がってくるわけです。

    この辺りが、ID2020プロジェクトでUNHCRがMicrosoftとAccentureと共同でやっているような難民=国家(アイデンティティ発行者)によってアイデンティティを否認された人々の身元を保証するためにブロックチェーンを活用しよう、という話につながったり、先の経産省のハッカソンの大きなテーマである少子化に伴い教育機関がつぶれていくという予想がつく中で如何にして自分の学位を証明するか(要は卒業した大学が消滅してしまった場合に誰が卒業証明書を発行してくれるのか?)という話がブロックチェーンと繋がって出てくる所以だったりします。

    確かに、国家等のアイデンティティの発行元によって自分のアイデンティティが消される、という緊急事態(プライバシーに優先するくらいの状況)において自分のアイデンティティを改竄出来ない状態にする緊急避難先としてブロックチェーンを選ぶのは確かに悪くないかも知れません。
    また、同様にアイデンティティ発行者が消滅したとしても以前に発行されたアイデンティティ(署名されたアサーション)の検証をするための公開鍵をブロックチェーン上に保管しておけば、誰かが勝手に「過去にこの大学を卒業した。その証明はこのアサーションである。すでに誰も公開鍵を持っていないから署名検証は出来ないけどね」というようなことを言い張るというリスクへの対応は出来るでしょう。

    ブロックチェーンも色々、標準化は?

    ある程度ユースケースが見えてきたところで考えないといけないのは、ブロックチェーンも色々、という話です。EthereumもありますしBitcoinブロックチェーンもあります。またパーミッションドなのかパブリックなのか、などの分類も様々です。
    そして最も重要なのはいかに耐改竄性が高いといってもブロックチェーンの系自体が消滅したりクローズする可能性は当然ゼロではない、というところです。

    こうなると、

    • 特定の系に依存しない
    • 必要に応じて系を引っ越せる
    ような仕組みというか標準を定めていく必要性が出てきます。

    その辺りに取り組んでいるのがDecentralized Identity Foundation(DIF)というわけです。
    ここでは主に、リファレンスモデルの策定やDecentralized Identifier(DID)や関連するメタデータ(DID Document)、検証可能なアイデンティティ情報の表現方法(Verifiable Claims/Presentation)などの標準化と、複数のブロックチェーンの系を跨いで存在するアイデンティティ情報のLookupをするためのUniversal Resolver(DNSみたいなもの)の仕組みを定義しています。

    この辺りは、先日のidcon(didcon)でお話したので、こちらの資料を見て頂ければと。(まだ私の調査も浅いのと、DIF自体の定義も議論の途中で非常にふわふわした状態ですが)


    当日のまとめはこちら

    いずれにしても、この領域が今後どうなっていくのか?については興味深く思っているので、引き続き調べて行こうと思います。



    European Identity & Cloud Conference 2019でBYOID+DIDの話をします

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

    昨年に引き続き今年もミュンヘンで開催されるEuropean Identity & Cloud Conferenceでお話させていただくことになりました。

    公式サイト
     https://www.kuppingercole.com/events/eic2019

    アジェンダを見ていると、AIとDecentralized Identity(ブロックチェーン)が半々くらいですかね。

    私は昨年に引き続きBYOID(Bring Your Own Identity)のテーマでケーススタディ+昨年シンガポールで開催されたConsumer Identity World APACで少し頭出しをしたBYOID+Decentralized Identityのテーマで、動くものを少しお見せしようと思っています。

    こんな感じの仕組みです。

    外部ユーザを招待してOffice365(Teamsとか)を使ってもらうシナリオの一種ではあるんですが、通常のAzure AD B2Bでゲストの招待だとドメインのホワイトリストやTOU(Term of Use/利用規約)への同意くらいしか相手を確認する方法が無いので、その部分でDecentralized IdentityのVerifiable Claimsを使って証明書を提出させて本人確認を行う、というシナリオです。

    このことにより、外部ユーザは組織アカウントでもLINEやFacebookなどの個人アカウントでのサインアップ+証明書を提出することによりTeamsやAzure ADに参加したPCへのログインなどが出来るようになります。この辺りをAzure AD B2CやAzure Functionsなどを使って自動化をしています。
    外部IDを受け入れる側の組織ではID管理やパスワード管理をする必要が全くありませんので、組織の形態にもよると思いますが使える場面も出てくると考えています。

    こんなことも出来るようになります。


    ちなみにID Proofing周りはOSSテクノロジー社のLibJeIDとuPortを使って実装しています。

    おいおいこの辺りの話しも解説したいと思います。
    (月末に開催されるde:code 2019でも触れる予定です)

    de:code 2019でKYCとDecentralized Identityの話をします

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

    先日のEuropean Identity & Cloud Conferenceでの登壇に引き続き、今年もde:code 2019でお話させていただきます。Webサイトには所属組織名として会社名も書いてありますが、今回は基本的にOpenIDファウンデーション・ジャパンの帽子でのお仕事です。

    春のde:code、秋のTech Summitと日本マイクロソフトの大型イベントでここ数年連続でセッションを持たせていただいておりますが、大型のイベントでの登壇はオーディエンスの属性も様々なので内容とレベル設定に気を使いますね。

    今回は「これからのKYCとIdentity on Blockchainの動向」というタイトルで、金融機関等におけるKYCの課題とIdentity on Blockchain、いわゆるDecentralized Identityが解決するための手段になりうるのか?という観点で最近の動向についてお話させていただこうと思います。そして、この内容を「レベル200=初級者向け」に解説しなければならない、というまた難題を・・・。(前回レベル詐欺と言われたので今回は反省して細かい部分は最低限に抑えるつもりではあります)

    内容的にはOpenIDファウンデーション・ジャパンのKYCワーキング・グループで議論している内容や、先日ポストした自己主権型アイデンティティの話を中心に、KYCにおける属性情報の受け渡しと検証を誰がどうやって簡単かつ確実にするのか?みたいな話について私の考えをお話しようと思っています。

    フェデレーションの様に一部のIdentity Providerに依存するモデルから、自己主権型アイデンティティでの主権・自由と引き換えに責任を自分で負うモデル、情報銀行の様に属性情報の管理を委託するようなモデルなど、色々な考え方への遷り変りの話なども少し紹介できればと思っています。


    では、当日お会いしましょう!

    Sign In with AppleとのID連携現状のまとめ&Azure AD B2C連携

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

    WWDC'19でSign In with Appleが発表されてから皆Apple IDに夢中※1ですね。まぁ、アプリのレビューガイドライン問題※2とか色々とありますが、日本人は不思議とiPhoneが大好きなので下手したらGoogleアカウントより普及してるのかもしれません。(パスワードを覚えているかどうかは別でしょうけど)

    ※1.今日(6/9)時点で私が把握しているSign In with Apple関係の記事


    ※2.問題の概要
    「サードパーティログイン採用のアプリはSign In with Appleを使うことを義務付ける」というレビューガイドラインが出たこと。Apple曰く、Relyingパーティに一切の個人情報を提供せずに認証だけを行うことができるためプライバシーに考慮している、という言いっぷりですが、逆にAppleが誰がどのアプリにログインしているかを把握するってこと?という気持ち悪い感じになっています。また、アプリ開発者はSign In with Appleを実装しなきゃダメ、という変な強権発動も流石Apple、という感じです。(個人の感想)


    とは言え、Sign In with Appleが世の中に出てきたのでとりあえず色々とつないでみたくなります。私もAzure AD B2CとAuth0にはとりあえず繋いでみました。

    というわけで、今回はAzure AD B2Cとのつなぎ方を解説します。
    (先に書いた英語版のblogの日本語訳です)

    ********************
    WWDC'19でアップルが「Sign In with Apple」という機能を公表しました。このポストではこの新しい機能をどうやってAzure AD B2Cで使うかを説明したいと思います。もちろん、この機能をIdentity Experience Framework(カスタムポリシー)を使って構成することもできますが、今回はビルトインポリシーのOpenID Connect IdP連携の機能(Preview)を使って構成します。


    最初にどのような動きになるのかビデオに撮ってみました。



    前提事項

    • アップル開発者アカウント(最低1年のサブスクリプション契約が必要)
    • Azure Active Directory B2Cのテナント
    • Azure WebApps等のWebホスティングサービス(Metadataのアップロード用)

    アップル開発者コンソールでクライアントを構成する

    「Sign In with Apple」はOAuth/OpenID Connect的な仕組みを採用しています(完全にプロトコルに準拠している訳ではなさそうですが)。そのため、それらのプロトコルに慣れ親しんでいる方であれば、実装するのはそれほど難しい話ではありません。

    アップル管理者コンソールでOAuth/OIDCのクライアントを作成することが出来ます。手順については先に紹介したOktaのブログを参考にしました。とても良いブログだと思います。
    https://developer.okta.com/blog/2019/06/04/what-the-heck-is-sign-in-with-apple

    構成するための手順は以下の通りです。
    1. Sign In with Appleを有効にしてApp Idを登録する
    2. Service Idを登録する(これがclient_idとして使われます)
    • ドメインの所有権を確認する
    • redirect_uriを構成する
  • Sign In with Appleで利用する鍵を登録する
  • 登録した鍵をダウンロードして署名付きJWTを作る(これがclient_secretとして使われます)
  • Azure AD B2C上のIdentity Providerを構成する

    Azure AD B2CでIdentity Providerを構成する前に、Apple Idに関するディスカバリ・ドキュメント(metadata)を作っておく必要があります。なぜなら、Appleは現在のところmetadata(/.well-known/openid-configuration)を公開していないためです。

    私はAzure WebApps上に作成したmetadataを公開しましたが、任意のWebサービスを使うことが可能です。

    Azure AD B2CのビルトインのOpenID ConnectのIdPを構成する際、metadataには以下の情報を記載する必要があります。
    • Issuer
    • Authorization Endpoint
    • Token Endpoint
    • Jwks Endpoint
    また、metadataを公開するURIは./well-known/openid-configurationで終わっている必要があります。

    こちらが作成したmetadataです。

    さて、これでAzure AD B2Cのコンソールからビルトインポリシーを構成する準備が整いました。

    新しいIdentity Providerを追加する。

    OpenID Connect(preview)を選択する


    metadata uri、client_id、client_secretを設定する。


    sub属性を必須とされている属性へマッピングします。現状、Appleは名前やメールアドレスをid_tokenの中に含めて返してこないのでsub(pairwiseな値)しか使えません。

    作成したIdPを利用する様にUser Flow(ポリシー)を構成する

    Azure AD B2Cのコンソールでの最後のステップはUser Flowを構成することです。今回はSign In and Sign Up(v2)のポリシーテンプレートでApple IdPを使う様にフローを構成しました。

    アプリケーションへ渡すための属性フローを構成します。


    これで設定はおしまいです。

    Azure AD B2Cに登録したアプリケーションから作成したポリシーを指定してID連携をすればApple Idでのログインが出来るようになっているはずです。


    ********************

    と、言うことでまずはAzure AD B2Cでの構成方法を紹介しましたが、Auth0など他のものへの組込みについても解説できればと思います。(既に他の方も紹介されていますが)

    Sign In with Apple連携その後。続々とIDaaSと連携~Auth0編

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

    前回のポストでAzure AD B2CとのApple ID連携を紹介しましたが、その後も各社が情報を出してきているのでUpdateしておきます。
    やっぱりApple ID強いですね。

    各社公式記事


    特にAuth0はカスタムコネクションではなく、ベータ版ながらもビルトインでの接続を早くも出してきています。

    話は変わりますが、先日のAuth0のCEOのEuginioさんが来日された時に発表されたLINE Loginとの連携についても早くビルトインで繋げられるようになればいいですね。

    現状LINE Login連携はカスタムコネクションで実装する必要があるので、今すぐつなぎたい人はこちらで。


    と、話を元に戻します。
    今回はAuth0のビルトインコネクションでのApple Id連携を試してみます。

    ◆コネクションの有効化~設定

    ダッシュボードを開き、ConnectionsよりSocialを選ぶとApple[BETA]が出てきますので、このスイッチをONにします。

    続いて、前回Azure AD B2Cに設定したのと同様にclient idなどのApple側の値を設定していきます。
    設定するのは、
    • Client ID
    • Client Secret Signing Key
    • Apple Team ID
    • Key ID
    • 取得する属性(名前、メールアドレス)※要するにscopeにnameとemailがつきます(なんだかうまく動いていない気がします)
    ポイントはAppleからダウンロードした秘密鍵を張り付けるだけでclient secretを自前で生成しなくて済むのが非常に便利です。




    設定が終わってSAVEをするとTRYボタンが現れるので、クリックすると設定が上手く行っているか実際にログインして確認が出来ます。



    「It Works!」が出ればOKです。

    ◆実際のアプリケーションに組み込む

    Auth0のダッシュボードからアプリケーションを作成し、Connectionsタブを開くと先ほど設定したAppleが出てきますのでスイッチをONにします。※今回は昔作ったアプリケーションを流用していますので、アプリケーション名が変ですw


    これで設定は終わりです。
    実際のアプリケーションへアクセスするとAuth0のログイン画面が表示され、その中にAppleが出てくれば成功です。
    ※ちなみに上2つはカスタムコネクションで設定したLINE LoginとApple Id連携で、今回設定したApple Id連携は一番下のボタンです。


    まだ属性の取得周りなど上手く動いていなさそうなところもありますが、今後ブラッシュアップされてくると思うので、期待しておきたいと思います。

    Identiverse 2019参加メモ(Day1)

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

     今週ワシントンDCで開催されているIdentiverse 2019にきています。私はまだIdentiverseがCloud Identity Summitと呼ばれていた2016年から合わせて通算で3回目の参加となります。(昨年度はスピーカーとしての参加でしたが、今回は純粋にオーディエンスとしての参加なので、大いに楽しみたいと思います)

    尚、今年は10周年ということで会場のあちらこちらに10周年を祝うモニュメントがあったり、毎年恒例のTシャツも10周年記念モデル?となっていたりしてお祭りムード全開です。(残念ながら例年おもしろTシャツのデザインをしていたPing Identityの方が退職されたとのことで、今年は1種類だけでした)

    10周年記念オブジェ

    10周年記念Tシャツ

    しかし、何と言っても今回の目玉は最終日に予定されているスペシャルゲスト、Steve Wozniakのスペシャル・キーノートです。
    こちらは最終日に改めてレポートします(体力が持てば・・・)


    と、言うことで初日の参加メモ(と言うか旅行日記)です。

    ◆Identiverseとは

    まず、Identiverse(旧Cloud Identity Summit)をご存知ない方のために簡単にイベント自体の説明をしておきます。詳細はこちらに書かれている通りですが、ざっくり言うと「デジタルアイデンティティやセキュリティ分野のリーダーやユーザーが集まって来るべきデジタル世界のVisionやテクノロジーについて語らう場」で、元々はPing Identityが主催するCloud Identity Summitとしてスタートして今年で10年、200以上のセッションがあり、2000名以上の方が参加するEuropean Identity & Cloud Conferenceに並ぶグローバルで最大規模のアイデンティティ・イベントです。

    日本人も10名程度ではありますが、毎年参加されています。(ここでしかお会いしない方々もいたりして・・・)

    また、グローバルなアイデンティティ界隈のリーダーの方々にも直接あって近況の交換をすることのできるIDマニアにとって非常に重要なイベントでもあります。
    今年も初日のレジストレーションに並んでいる時にSalesforceのVPのIan Glazerに声をかけてもらったり、廊下でUnikenのNishantと話をしたり、MicrosoftからAuth0に移籍して早1年、我らがVittorio Bertocciと写真を撮ったり、と日本ではなかなかできない体験ができます。

    ◆Day1で参加したセッション

    今回は奇跡的に時差ボケ解消に成功したので、初日から力つきることなく朝から晩まで通してセッション参加しました。

    簡単な感想などを添えてそれぞれのセッションを紹介します。
    ちなみにアジェンダはこちらから見ることができます。

    • Introduction to Identity Part 1 / 2 by Ian Glazer, Pamela Dingle, Steve Hutchinson
      • 言わずと知れた大御所によるデジタルアイデンティティとはなんぞや、と言う解説セッション。
      • 標準技術から利用シーンまで網羅的かつわかりやすく解説してくれたので初学者に取っては非常に貴重な機会だったと思います。
      • それなりに広めの部屋でしたが立ち見が出るほどの大盛況でした。
      • かい摘んで解説すると、こんな感じでした。
        • B2Eの世界における従業員IDの管理のようなトラディショナルなID管理から、B2Cの世界における顧客IDの管理のようなモダンなID管理への潮流があり、これからは「個人にフォーカスしたID管理」が主流になってくる
        • B2E、B2B、B2Cのそれぞれの世界におけるID管理を「Admin-Time(管理時の目線)」と「Run-Time(実行時の目線)」で深掘り、関連するID管理の実施事項を解説してくと言うスタイル
        • 管理と言う目線では以下のキーワードについて概要及び技術標準(SCIMなど)を解説(Ian Glazerが担当)
          • Source of Truth(アイデンティティ情報の源泉)からディレクトリやアプリケーションなどの各種レポジトリへのプロビジョニングの流れ
          • その前段にあるIdentity ProofingについてB2E、B2B、B2Cでの違い
          • 権限管理、ロール管理、アイデンティティ・アナリティクス、特権ID管理
        • 利用時の目線では同じく概要から標準を解説(Pamela Dingleが担当)
          • 認証・認証要素(Active Factor/Passive Factor)とAdaptive Authenticationについて
          • シングルサインオンとは
          • APIセキュリティと委任(WS-Trust vs OAuth2.0)
          • UXについて(Discovery時のNASCAR問題、同意取得、プロファイル管理、登録やリカバリのセルフサービス化など)
        • 最後にSteve HutchinsonがAdmin-TimeとRun-Timeを合わせて全体像を語る、と言う締め

    • Modern Identity for Developers 101 by Vittorio Bertocci
      • 言わずと知れたVittorioのセッション
      • 旧来のIdentityシステムからモダンなアーキテクチャへの移り変わってきた理由をわかりやすく解説
        • 旧来はネットワーク境界の中にシステムがあり、各システムがアイデンティティ関連の機能(ユーザーストア、認証機能など)を持っていた
        • その後、複数のシステムを横断的に使いたい、と言う要望に答えてディレクトリシステムやKerberosなどネットワークレイヤに近い層でシングルサインオンを実現
        • しかしクラウドやB2Bなどネットワークの境界を超える必要が出てきたので、Federationテクノロジーが必要になってきた(モダン・アイデンティティの世界)
      • Developer向けのセッションなので、モダン・アイデンティティの世界を支える各種要素(Identity ProviderやRelying Party、id_token、access_tokenとセッション管理など)の基本的な考え方を実際のデモ(Auth0とASP.NET Coreアプリ)をFiddlerでトレースしながら解説

    • Google master class: Enabling BeyondCorp in your organization today by Google
      • ベンダーセッションなので製品・サービスに特化した解説
      • Vittorioのセッションでもあった通り、もはやネットワーク境界がセキュリティの境界となり得ない世界(Identity is the new perimeter)となってきているので、VPNやFirewallではなくアイデンティティ・アクセス管理とデバイス管理を統合的に行うことでセキュアな世界を作りましょう、と言うのがBeyondCorpの基本的な考え方
      • Identity、Context、Rules Engine、Enforcement pointを経てアプリケーションやデータへ到達できる、と言う流れ(以下、概要)
        • Identity : 利用者のアイデンティティ。Cloud Identityが該当
        • Context : 利用者がどのような状態なのか(デバイス状態やネットワーク)。Device Trustの設定など
        • Rules Engine : IdentityとContextに応じて必要な認証や認可ポリシーを判断するためのエンジン。Access Control Managerで設定
        • Enforcement point : 判断結果の応じたポリシーを実行する。Cloud IAP、Cloud IAM、VPC Service Controlなどで対象システムやAPIに応じて制御を行う
      • 最後にデモとして特定のバージョン以上のMacOSからでないとGmailが開けなくなる、と言うようなシナリオを紹介

    • US Army: The secrets of a Successful ABAC Deployment by Accenture Federal Service, NextLabs
      • 事例セッション
      • US ArmyのSAPシステムの権限管理をNextLabsのソリューションを使ってABACで最適化したよ、と言う話
      • ABACの基本的な考え方はNIST SP800-162の通り。XACMLベースです。
      • やりたいことはRealtime SoD、Realtime continues authentication/Risk-aware authorization
      • ベストプラクティスは以下の通り
        • 属性のクオリティは大事
        • ポリシーは100個以下におさめて再利用可能な設計をすること
        • RBACとABACは共存できる
      • US ArmyではNextLabsのソリューションを使い、SAPの標準の権限管理のさらに上位のレイヤーで権限管理を行った
      • 最終的にはこんな感じ
        • 権限管理に使った属性は5つ未満
        • ポリシーは10〜20個の間
        • 属性はGRCで管理

    • Decentralized Identity: Intersection of Identity and Distributed Ledger by Microsoft
      • マイクロソフトによるDIDのオーバービュー
      • 今日のアイデンティティに関する3つの課題
        • Too many passwords
        • Data ownership, privacy
        • Data oversharing
      • DLTはこれらの課題を解決できるのか?と言う問いに答えるのが、Identityと分散台帳をとり持つDecentralized Identity
      • DID AuthやVerifiable Credentialsを使うことである程度上記の課題が解決できそう。MSも最近IONを出したよ
      • しかし残課題として、UXやRP側から見たExperienceの改善や、アカウントリカバリーや鍵のローテーションの問題があるので、頑張って対応していく
      • そして、DIDはPIIなのか?という話も今後議論されていく問題。。。

    • Delivering a Trusted Digital Identity System by Mastercard
      • この辺りになると疲労度マックスなのであまり頭に入ってこなかったです。。。
      • 金融機関と言うよりテック企業になってきていて、デジタル空間での信頼を従来の社会と同様に作っていく、と言う話。
      • マスターカードのロゴのオレンジの丸は信頼を表している?と言うような話をしていた気がします
    • Throwing away the Clipboard : Digital Identity & Blockchain for Healthcare by Aetna, TrustedKey
      • 医療に関連する情報のポータビリティをTrustedKeyを使って実現しよう、と言う話(ただし、電子カルテの代わりになったり、ブロックチェーン上に医療履歴を載せようと言う話ではない)
      • 解決したい課題はユーザの利便性。
        • 保険証や本人確認書類を何度も提示しないといけない状態を解消したい。実際の医療行為を受けている時間より手続きを待っている時間の方が長いのは勘弁してほしい。
          • 医者に行く前のオンライン予約
          • 病院の受付
          • 薬局の受付
          • 医療履歴を管理するWebサイトへの登録
      • 医療機関、薬局などがIdentity Issuerとなり、TrustedKeyの提供するウォレットに情報をストア(ブロックチェーンベース)
      • 各種機関やオンラインサービスへQRコードを使って情報を提示することでUXを改善できる

    • Fastfed - A new standard to make SSO easy by AWS
      • OpenID FoundationのFastFed WGの発表
      • 現状、SSOを有効化しようとすると、IdP側に設定をした値をコピーしてRP側に設定、RP側の設定結果をIdP側にまたコピーして、、と言う流れになり非常に煩雑
      • FastFed WGでは設定や属性マッピングの自動化を行うための標準を検討している
      • AWSへのSSOをGoogle IdPで実施するデモを披露
        • AWSコンソールからGoogleアカウントを入れるだけで自動ディスカバリ〜自動設定が行われる
      • 個人的に非常に期待しているWGだったりするので、本格的に実装されてくるのが楽しみです
    • Self Sovereign OpenID Connect - a ToDo List by Nat Sakimura
      • 米国OpenID Foundationの理事長である崎村さんのセッション。
      • Self Sovereignってみんな騒いでるけど、ブロックチェーン=Self Sovereignじゃないよ、OpenID Connectでもいいよ、と言う話
      • モデルとしては、こんな感じ
        • SIOPを中心とした世界観
        • CP(Claims Provider)とIdP(SIOP)を明確に分離して、間をAggregated ClaimとかDistributed Claimで繋ぐ
      • ただ、まだまだやることもあって、以下がToDo List
        • SIOPを簡単にCPへレジストレーションできる仕組み(Dynamic Client Registration)
        • SIOPが発行するSelf IssuedなIdentifier(公開鍵のハッシュ)とCPの属性のバインディングの方法
        • 過去に遡った署名の管理(ブロックチェーンの出番かも)
        • 鍵のリカバリの仕組み
        • SIOPがオフラインでもRPが属性を取得できる仕組み
          • 基本的な考え方はDistributed Claimの利用。RPが直接CPへ問い合わせできる
        • SIOPのアドレスの解決
          • ブラウザ設定とリクエストヘッダーで解決できるような仕組みが良いのではないか?



    とりあえず初日はこんなところです。


    ちなみにワシントンDCの街中は結構坂もあるので、電動スクーターや電動自転車のシェアリングサービスがそこら中にあります。以前はカーシェアだけしかやっていなかったLyftがスクーターに手を出したりしていてまさにMaaS元年って感じなのかも知れません。(写真はBird)
    Viewing all 769 articles
    Browse latest View live