2017年11月22日水曜日

LINEログインとBotの自動リンク機能が一般公開

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

先日のLINE Developer Dayで発表されたLINEログインとBotの自動リンク機能がいよいよ一般公開されました。
また、同時にBotとユーザの友だち関係が取得できるAPIも同時に公開されているため、従来Webhookでfollow/unfollowのイベントを取得して保存して状態を管理しておかなければならなかったのがリアルタイムに状態把握が出来るようになり、Bot開発者はとっても楽になりました。

LINEログインチャネルにボットをリンクできるようになりました
https://developers.line.me/ja/news/#link-your-bot-to-your-line-login-channel-2017-11-21

それぞれ動作イメージです。

◆LINEログインとBotの自動リンク

基本は以前紹介したエントリと変わりませんが、DeveloperコンソールからリンクするBotを自分で設定できるようになりました。


チャネル内にLINEログインとMessaging APIを作成、LINEログインのチャネル設定からリンクするBot(Messaging API)を設定します。

この設定をして、LINEログインをすると認可画面でBotを友だち追加する許可が表示されます。



尚、この機能を使うには、前提事項がありますので、注意が必要です。

  • LINEログインのversion 2.1を使うこと
  • アプリケーションタイプがWebであること
  • 同一プロバイダ内にBotがあること


◆友だち関係の状態を取得する

もう一つが、最新の友だち関係の状態を取得するAPIです。
2つ方法があります。

  • 認可コードを取得する際にCallback URLへcodeとともに返ってくる「friendship_status_changed」の値を見る(状態の変化の有無の確認)
  • 状態取得用API(Social API)エンドポイントをGETする


2つ目のSocial APIエンドポイントへアクセスして状態確認をするのが一番任意のタイミングで確認できるので便利かも知れません。

Social API
https://api.line.me/friendship/v1/status

クエリ方法は単純でAuthronizationヘッダにaccess_tokenをつけてGETするだけです。
trueが返ってくれば友だち、falseだと友だちではないかBlockしている状態です。


さてさて、早速Azure AD B2Cとの連携モジュールを少し改修して便利にしていかなきゃ、と思います。

Firefoxの更新でSAML Tracerアドオンが利用不可に・・・

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

Firefoxのバージョンが上がりましたね。スクリーンショットが撮れたりするのは良いんですが、SAML Tracerなどのアドオンが使えなくなってしまったのは全国3000万のSAMLerの皆さんには受け入れがたい事実です。


※2017/12/6続報。対応バージョンが出ました。一安心。
 http://idmlab.eidentity.jp/2017/12/firefoxsaml-tracer.html

仕方がないので別のアドオンを探してみると、SAML Message Decoderというモノがあったので早速入れてみます。


インストールすると、メニューバーにアドオンが追加されるので、早速SAMLを使っているサイトへアクセスします。
アイコンを右クリックするとExport messagesというメニューが出てくるので、ここをクリックしてトレースデータをExportするようです。
SAML Tracerのようにリアルタイムでトレースが見れないのが非常に残念です。


Exportしたファイルはjson形式で保存されるのでエディタなどで開くと確かにメッセージが表示されています。。。



決して見やすいとは言えないですね。。。
SAML Tracerのバージョンアップに期待しておきましょう。

2017年11月10日金曜日

Tech Summit で使った Azure AD B2C + LINE チュートリアル

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

Tech Summitが終わりましたね。
私は先に告知させていただいた通り、Azure Active Directory B2C と LINE の連携の話をさせていただきました。

[告知] Tech Summit 2017で Azure AD B2C+LINE、Yahoo! ID辺りの話をします
http://idmlab.eidentity.jp/2017/10/tech-summit-2017-azure-ad-b2clineyahoo.html


セッションの動画公開は行わない予定ですが、資料は来週以降に公開されるそうなので、その時はまたお知らせしますが、ここではセッション内でお見せしたデモ環境をご自身で作っていただくためのチュートリアルを紹介します。

Azure AD B2C + LINE連携 / チュートリアル
https://github.com/fujie/ts2017

置いてあるのは、
・手順:readme.md
・ポリシーテンプレート:policy_template_base.xml、policy_template_susi.xml
・テスト用アプリケーション:test.php
です。

基本的には手順に従って作業をしてもらえればとりあえずLINEでテストアプリケーションへログインできるようになりますので、一度試してみてください。

2017年11月8日水曜日

[Office365+AD FS管理者向け] Azure ADのエンドポイント追加による可用性の向上

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

Azure AD単体(要はクラウド認証)でOffice365を使っている人には関係ありませんが、AD FSやサードパーティのIdPを使ってOffice365やAzure AD連携されたアプリケーションを使っている人は、近々エンドポイント追加の作業が必要になりそうです。
公式アナウンス)New Azure Active Directory resilience features: action required
https://cloudblogs.microsoft.com/enterprisemobility/2017/10/27/new-azure-active-directory-resilience-features-action-required/

正式なアナウンスは追ってあるようですが、要するに可用性を向上するためにAzure ADのACS(Assertion Consumer Service)のエンドポイントが増えたので、AD FSとかサードパーティのIdPでOffice365やAzure ADを使っている人は対応してね、ということらしいです。
※ちなみに、Azure AD ConnectでAD FSを構成している人は自動的に構成が変更されるみたいです。

こちらが変更までのAD FSの構成です。

手動で追加する場合はPowerShellで一括で登録することもできますし、この画面で追加しても大丈夫です。
一括追加のスクリプトは以下の通りです。
$rp = Get-AdfsRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline
$endpoints = New-Object System.Collections.ArrayList
if ( $rp.AdditionalWSFedEndpoint ) { $rp.AdditionalWSFedEndpoint | %{$endpoints.add($_)} }
$endpoints.add("https://stamp2.login.microsoftonline.com/login.srf")
$endpoints.add("https://ccs.login.microsoftonline.com/ccs/login.srf")
$endpoints.add("https://ccs-sdf.login.microsoftonline.com/ccs/login.srf")
set-adfsrelyingpartytrust -targetname $rp.Name -AdditionalWSFedEndpoint $endpoints


結果、こんな感じになります。


尚、Azure ADと外部IdPを連携する際のsp-metadataを見るとまだ上記のエンドポイントは記載されていないのですが、今後は追加されてくるのかも知れませんね。

参考)Azure ADのsp-metadata
https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml

2017年11月6日月曜日

11/30までにAzure AD管理者がやっておくべきこと:条件付きアクセスの設定移行

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

いよいよ今月末(11月30日)でAzureクラシックポータル(旧ポータル)が廃止されます。

公式アナウンス)Marching into the future of the Azure AD admin experience: retiring the Azure AD classic portal
https://cloudblogs.microsoft.com/enterprisemobility/2017/09/18/marching-into-the-future-of-the-azure-ad-admin-experience-retiring-the-azure-classic-portal/

Azure ADの管理機能も「ほぼ」新ポータルへ移行されたのですが、旧ポータルでアプリケーション単位で設定をしてきた条件付きアクセスの設定が新ポータルの条件付きアクセスでは触れず、メンテナンスは新・旧でバラバラに行う必要がありました。

この状態で旧ポータルを廃止されるとかなり困ったことになるのですが、先日ようやくマイグレーションパス(というか緩和措置?)が発表されました。

公式アナウンス)This one is important: Time to migrate your v1.0 Conditional Access policies to v2.0!
https://cloudblogs.microsoft.com/enterprisemobility/2017/10/23/this-one-is-important-time-to-migrate-your-v1-0-conditional-access-policies-to-v2-0/

簡単に言うと、旧ポータルの条件付きアクセス(v1.0)を新ポータルの条件付きアクセス(v2.0)でも見えるようになる(だけ)の機能の発表です。

11月30日の廃止の1か月前のアナウンスというタイトな感じなので、早くやっておかないとハマりそうな感じ満載です。(しかもPreview機能という・・・このまま永遠にPreviewなんだと思いますが)

ということで、早速試してみます。

◆旧ポータルの状態の確認

まずは旧ポータルで現状を確認しましょう。アプリケーションの構成から条件付きアクセスの確認をすることが出来ます。そういえばネットワークの場所ベースとデバイスベースが独立したメニューになっていたんですね。この画面も見納めかと思うと画面ショットを撮りまくっておきたい気分になります。



◆新ポータルから旧ポリシーを確認する

既に皆さんの新ポータルから旧ポリシーが確認出来るようになっていますので、見てみましょう。Active Directoryを開き、条件付きアクセスを見ると、Classic Policies(Preview)というメニューが追加されています。


メニューを開くと、

  • [アプリケーション名] MFA and location policy(場所ベースの場合)
  • [アプリケーション名] Device policy(デバイスベースの場合)

という形でポリシーが見えるようになっています。

ポリシーを選択するとどのようなポリシーだったのか、内容の確認ができます。


では、早速移行してみます。

◆信頼済みIPリストの移行

まず、旧ポリシーでは信頼済みIPとして多要素認証の管理画面で指定したネットワークリスト(上限50個)しか指定できませんでした。
もちろん新ポータルでも多要素認証で指定したネットワークリストも使えますが、数の上限があるのと、一覧で書くしかないので使い勝手があまりよくありませんので、せっかくなのでこの機会にNamed Locationsを使いましょう。こちらを使えば、ネットワークに名前を付けることが出来るので、例えば事務所のロケーション毎にネットワークアドレス群に名前を付けて管理することが可能です。

もちろん、この画面からConfigure MFA trusted IPsをクリックすれば多要素認証のネットワークリストを確認・設定することが可能ですので、こちらから設定を移行しましょう。

新規Named Locationを追加するとネットワークに付ける名前、指定方法(IPレンジか、国や地域)、信頼済みIPとして扱うかどうか、実際のネットワークリストの指定を行うことが出来ます。ここへ多要素認証の信頼済みIPリストを移行しておきましょう。


◆ポリシーの移行(作り直し)

条件となるネットワークの移行が終わったら、旧ポリシーを参考に新ポリシーを作成します。
設定すべき項目は以下の通りです。

  • ポリシー名 : 任意の名前
  • 対象のユーザ・グループ : ポリシーの適用対象、除外対象ユーザ・グループの指定
  • 対象のアプリケーション : ポリシーの適用対象、除外対象アプリケーションの指定
  • 適用条件 : ポリシーの適用条件(ネットワーク、デバイス状態)
  • アクセスコントロール : 条件にマッチした場合のアクションの指定(多要素認証の要求やアクセスのブロック)
  • セッション : 現状はまだPreviewですが、一部のアプリケーション(SharePoint Online)における制限やCloud App Securityと連携したコントロールが出来ます。

まずは、適用対象のユーザとグループです。
よく使うポリシーとしてInclude(適用対象)に全員を入れておいて、Exclude(除外対象)に一部のグループを入れておいて一時的に多要素認証のデバイス(スマホなど)を忘れた人を救済する、というポリシーです。


次にアプリケーションです。
旧ポータルではアプリケーション単位にポリシーを作成する必要がありましたが、新ポータルでは全体に適用する共通ポリシーや一部の選択したアプリケーションへ適用するポリシーを作成することも可能になりましたので、この機会にポリシーの見直しをしても良いかも知れません。

次に適用条件です。
今回は移行元がネットワークの場所ベースの条件付きアクセスだったので、Locations設定でInclude(適用対象)をすべて、Exclude(除外対象)を信頼済みネットワークとして指定します。(ここでAll trusted locationsとすると多要素認証の信頼済みIPリストと、信頼済みとするにチェックを入れたNamed locationの両方のorをとったものが対象となります)

後はアクセスコントロールです。
条件にマッチした場合に多要素認証を要求する場合は、Grant accessにしてRequire multi-factor authenticationを指定しておけば大丈夫です。

最後に、ポリシーをEnableにして保存すれば適用が開始されます。


◆旧ポリシーを無効化し、動作確認を行う

ここで重要な注意点です。
新ポータルからは旧ポータルで作成したポリシーを無効にすることしかできません。失敗しても再度有効化しようとすると旧ポータルへアクセスして有効化しないといけません。
つまり、12月1日以降に新ポータルで無効化した旧ポリシーは二度と有効化することが出来ない、ということなのでリカバリーが出来る状態での動作確認は11月30日までしか出来ない、ということです。

しっかり計画を立てておきましょう。

新ポータルから旧ポリシーを無効化するには、先ほどのメニューより旧ポータルを選び、Disableをクリックするだけです。


後は動作確認として、適用条件に合致した・合致しない状態でアプリケーションへアクセスし、望んだ状態になるかどうか確認してください。


ということで、管理者の皆さんは急いでテスト~移行しておきましょう。

2017年10月17日火曜日

jwt.msとjwt.io。JWTオンライン・デコーダを比べてみる

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

eyJ・・・とくると脊髄反射してしまうID厨の方々は既にご存知だと思いますが、JWT(Json Web Token)の中身を眺めてデバッグをする時にとっても役に立つのがオンライン・デコーダです。

個人的には、Auth0が提供しているjwt.ioをずっと使っていたのですが、最近マイクロソフトが提供し始めたjwt.msも意外と便利なので比べてみます。

使い方はjwt.ioもjwt.msも共通で、eyJ・・・の文字列を張り付けると自動的にデコードされ、JSONが表示されます。

◆jwt.io

まずはjwt.ioです。

左側に張り付けると右側にデコードされたヘッダ、ペイロードが表示されます。
単純にペイロードの中身にどんなクレームが飛んでいるのかを見るには十分です。

jwt.ioの一番の特徴は各言語毎のJWTのハンドリング用のライブラリと対応状況を掲載しているところでしょう。Ruby用、PHP用ライブラリとして、OpenID Foundation Japanのnovの作品も紹介されています。


◆jwt.ms
次にjwt.msです。

ちなみに画面構成がものすごくシンプルなので、誰が運営しているのか見た目からは全く理解できませんが、whoisで調べるとちゃんとマイクロソフトがドメインの持ち主であることがわかります。

基本機能はjwt.ioと全く同じです。
画面上部に張り付けると下にデコードされた結果が表示されます。

jwt.msの一番の特徴は各クレームの情報が細かく確認できることだと思います。
Claimsタブを開くと各クレームの意味など細かい情報が出てきます。


まとめると、
・ライブラリを調べたい時はjwt.io
・各クレームの意味・仕様を細かく知りたい時はjwt.ms
といったところでしょうか。

まぁ、最終的には好みですね。


2017年10月16日月曜日

[告知] Tech Summit 2017で Azure AD B2C+LINE、Yahoo! ID辺りの話をします

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

9月、10月とイベント続きで、あまりblog書きなどの各時間が取れなかったのですが、もう少しイベントは続きます。

と、言うことで昨年と同じく今年もMicrosoft Tech Summitに登壇いたします。

公式サイト※早期申込割引は終わっちゃったみたいですが、お申し込みはこちらから。
https://www.microsoft.com/ja-jp/events/techsummit/2017/


昨年はAzure ADとアプリケーション連携の話とハンズオンラボの2本でしたが、今年は個人的ブームでもあるAzure AD B2Cネタです。

「Azure AD B2C と LINE 連携により実現する学校や企業における次世代 ID/メッセージ基盤」というタイトルでDay2の夕方16:25~17:15が出番で、先日リリースさせてもらった、LINEやYahoo! IDの連携をテーマにIdentity Experience Framework(IEF)をDeepに解説したいと思います。



IEFを50分で語りつくすのは不可能に近いので、Azure AD B2Cとは?みたいなところは、すっ飛ばしていきなり、フレームワークの構造の話から始めてしまうと思うので、初心者を置いてけぼりにする気がものすごくします。レベル400で足りるのだろうか、、という一抹の不安があります。。。

というわけでチラ見せします。
この画面を見てピンとこないと置いてけぼりになる・・・・ということは無い様に最大限努力はしたいと思いますが、まぁ全編こんな画面を見続けることなると思います。


まぁ、公式ドキュメントがほぼ存在しないという状態なので、プロトコルの仕様とマイクロソフトの開発陣のパラメータ命名規約のクセからXMLのエレメント名と設定値を推測しながら開発を進めていくという苦行をここ半年ばかりやってきたので、少しはわかりやすくご説明できるようになったんじゃないかな、と思っています。

この辺りをマスターすると、以下のような感じで色々なソーシャル・ネットワークをIdPとして使うことが出来る様になったり、外部のDBからRESTでClaimを取得したりすることが出来るようになります。※以下はInstagramとつないだ例です。




ということで、ぼちぼち資料作りを始めていこうと思いますので、当日お会いできることを楽しみにしております。