FB Message API Callback as an Azure Function

Published on:
Tags:

今日は Azure Function で FB Message API Callback を作ってみます。

Azure Function は、Azure Portal の Marketplace で “Function App” って検索すると出てきますね。

Azure Function in Marketplace

Function App の Deploy がおわったら、QuickStart から “Webhook + API” を選びましょう。

Azure Function QuickStart

以下の様な Node.js のテンプレートアプリが出来上がります。

Azure Function Template

まずは FB Message の WebHook としてこの Function を登録します。

Read on →

Windows Server 2016 版 ADFS を触ってみた

Published on:
Tags:

MVP になったことですし、早速 Azure 常に Windows Server 2016 の VM 立ち上げて、次期バージョンの ADFS を動かしてみました。

想定ユースケースは、Native App とその Backend Server があって、Backend Server が Native App 向けに提供している API 用の Access Token も、ADFS が発行するというものです。

まさしく今後エンプラで増えていくであろうパターンですね。

Setup Hybrid Client on ADFS

ADFS Manager に “Application Groups” っていう設定が増えてるんで、そこから “Native Application and Web API” ってのを選択して、Connect RP (= OAuth Client) を登録します。

New Hybrid Client

スクショいっぱい撮るのが面倒なのですっ飛ばしますが、こんな感じで Native App とその Backend Server を ADFS に “Application Group” として登録しました。

Registered Hybrid Client

ちなみに、この時 Backend には特に Native App と別の client_id が発行されたりはしません。

ここまでで、ADFS 側の準備は完了です。以降、こちらの gist に沿って、Step by Step で見ていきます。

Read on →

Microsoft MVP Award を受賞しました

Published on:
Tags:

2016年度の Microsoft MVP Award を受賞させていただきました。

これもひとえにあんのパパのおかげです。パパは2007年4月 Microsoft 入社ということなので、僕が新卒になったころからの MS エバンジェリストってことっすよ。

通常であればにいさんと呼びたいところですが、今回新たな MVP も産んだことですし、Identity 業界の慣習にならって積極的にパパ呼ばわりしていきたいとおもいます。

また、Award のカテゴリーは “Microsoft Azure” ってなってたので、ふぁらおぅにぃさんが腹ちがいのにぃさんになった感じですかね、きっと。

どこまで今回の MVP Award のカテゴリーにマッチしてるのかはよくわかってないんですが、僕がいま興味あるエリアは AzureAD & ADFS の Connect サポート、Graph API、Windows 10 の FIDO サポートあたりなんで、その辺りでいろいろ遊びながらこのブログとかで記事書いていければいいなと思います。

もちろんエディタは Visual Studio Code で。(まじこいつ起動はえー!Atom より圧倒的に起動はえー!!)

とりあえず Microsoft Edge の FIDO 実装で遊ぶためにも、Surface Pro4 を買わないとですね!

ということで、つい先日 Windows Server 上で新規ファイル作成すらできなくてがく然とした Windows 音痴な僕ですが、今後ともよろしくお願い致しますm m

ps.
新規ファイル作成は、右クリックじゃなく、メモ帳開いて [Ctrl] + [S] な。

独立 & YAuth.jp 設立

Published on:
Tags:

昨日を最終出社日として、GREE 正社員生活を終えました。4月からは独り会社作って独立します。

転職じゃなくて独立で、契約形態変えて GREE さんともお仕事する可能性十分あるので、あまり退職っていう実感はないのですが、これもまぁ一応退職エントリー…ですかね?

新会社での業務内容としては、Identity まわりのコンサルとか技術支援とかをメインでやる予定。

ありがたいことにすでに数件4月以降の仕事依頼もいただいており、気軽に新しい案件受けづらい状況なのですが、もし興味あればご連絡いただければと思います。

ID の専門家として仕事しつづけるとしたら、1社に閉じるより数社の仕事同時にこなす方がいいんじゃないかとか、そういう流動的に動ける人もこの国に数人いたほうがいいんじゃないかとか、そういうのが独立のきっかけとしてあるので、いろんな会社のお話聞いてみたいです。

Read on →

「OAuth 認証」を定義しよう

Published on:
Tags:

「OAuth 認証」って言葉が出てくると、「認証と認可は違う」とか言い出す人が出てきて、大体の場合「OAuth 認証」言ってた人たちがやりたいことの話とはズレた議論が始まるので、もういっその事「OAuth 認証」とは何かを定義してみましょうかね。

「OAuth 認証」で Relying Party (RP) がやりたかったこと

RP (OAuth Client) は、ブラウザの前にいる人を、認証したかったんですよね?

もう少し正確にいうと、ブラウザの前にいる Entity が、RP 側で把握しているどの Identity と紐付いているか、というのを知りたかったんですよね?

いきなり Entity とか Identity とかいう専門用語が出てきてアレですが、そのあたりのことは先日の OpenID TechNight #13 でもお話ししたので、以下のスライドの Entity・Identity・Authentication・Authorization のあたりのページを見てください。

で、あるサービスが End-User を認証したいって思った時って、普通は当該サービスが事前に当該 Entity に対して ID と Password を登録させて Identity Record (「サービスアカウント」と言ってもいい) を作成し、後日当該 Entity が当該サービスに訪れた際は登録済みの ID と Password を提示させて当該 Entity に紐づく Identity を確定するわけです。

でも Identity Federation (上記スライドでは「ID 連携」と表現している) という手法を使うと、外部のサービス (Identity Provider, IdP) の Identity を当該サービス (Relying Party, RP)の Identity と紐付けて管理することで、End-User から直接パスワードを預からなくても、ブラウザの前にいる Entity (= End-User) に紐づく IdP 側の Identity に紐付いた RP 側の Identity を確定できるので、結果として End-User に紐づく RP 側の Identity を確定することができます。

で、どうやって IdP と RP がそれぞれに管理している Identity を紐付けるのか、というのが、Federation Protocol の肝なわけですが、「OAuth 認証」というのはその一種です。

Read on →