2018年2月15日木曜日

[SAML]IdPの動作テストに使えるテストSPサイト

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

Azure Active Directory(Azure AD)を含むSAML IdPを構築していると、どうやってテストするかに悩みますよね。

以前、simpleSAMLphpをAzure Web Appにデプロイしてテストする方法を紹介しましたが、今回はもっと簡単な方法を紹介したいと思います。

使うのは、RSAが提供しているSAML 2.0 Test Service Providerです。そのまんまの名前です。
 RSA SAML 2.0 Test Service Provider
 https://sptest.iamshowcase.com/



サイトの説明を読んでいると出来ること、出来ないことはあるようですが簡単なテストであればすぐで出来そうです。

出来ることは以下の通りです。

  • IdP Initiated SSO
  • SP Initiated SSO
  • AuthenticationContextClassRefを指定することによる認証方式の指定
  • アサーション内の属性の表示
  • 認証状態の表示
  • 特定ユーザに指定した認証方式を要求する

逆に出来ないことは、こちらです。

  • 署名付きの認証リクエストを送る
  • 暗号化されたSAMLアサーションを受け取る


普通にテストする分には十分です。


ということで使ってみました。IdPはAzure ADを使っています。試したのはSP Initiated SSOです。

◆SPの情報を確認する

まずはテストサイト側でシナリオを選びます。
InstructionメニューからSP Initiated SSOを選択します。

するとDOWNLOAD METADATAというボタンが表示されるので、ダウンロードしておきます。これはSP側のMetadataなので、この中にあるSP EntityIDやAssertion Consumer Service(ACS)のURLを、IdPであるAzure AD側へ設定します。

ダウンロードしたMETADATAを開くとこんな感じでEntityIDとACSのURLがありますのでコピーしておきましょう。

◆Azure ADにアプリケーション(SP)を登録する

Azure ADを開き、エンタープライズ・アプリケーションよりギャラリーにないアプリケーションを選択してアプリケーションを作成します。
(SAML系のアプリケーションは、アプリケーション登録のメニューではなく、エンタープライズ・アプリケーションを使いますので注意してください)

適当な名前でアプリケーションを作り、シングルサインオン設定でモードにSAMLベースのSSOを設定、Identifierに先ほどのSP Metadata内のEntityIDを、Reply URLにACS URLを張り付けます。

次に、同じ画面の中からAzure AD側のMETADATA(IdP Metadata)をダウンロードしておきます。

これでAzure AD側のSAML設定はおしまいです。

◆SPにIdP(Azure AD)の情報を登録する

このファイルを先ほどのテストサイトへアップロードします。


アップロードが上手くいくと、ログイン用のURLが払い出されます。

SAML関係の設定はこれで完了です。
本当に簡単です。


◆テストする

あとは先ほど表示されたURLへアクセスすればAzure ADへリダイレクトされるのでログインすればOKなんですが、初期状態のAzure ADはアプリケーションを使えるユーザを割り当てないとログインできないので、アプリケーションへのユーザ割り当てを無効化しておきます。(もちろん明示的にユーザを割り当ててもOKです)


これで本当に準備OKです。
早速先ほど生成されたログインURLへアクセスしてみます。するとAzure ADへリダイレクトされてログインできます。

上手くいくとログインしたユーザのIDが表示されます。


画面をスクロールしていくとSAMLアサーション内の情報が順番に表示されるので意図した通りの情報がSP側へ伝わっているかどうかの確認ができます。

Subjectの情報


認証状態の情報

属性の情報


もちろんアサーション全体を表示することも可能です。



本当に簡単にテストが出来てしまうので非常に便利です。
IdPを構築してもSPがないのでテストがやりにくい、、、という方はぜひお試しください。

2018年2月13日火曜日

[Azure AD]Duo Securityを使った3rdパーティ多要素認証を行う

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

昨年10月に公表されてから時間が経ってしまいましたが、Azure Active Directory(Azure AD)でマイクロソフト純正の多要素認証プロバイダ(いわゆる買収したPhoneFactorですね)ではなく、サードパーティの多要素認証プロバイダ(今のところ、RSA、Duo、Trusonaの3社)を使って多要素認証が出来るようになっています。(現在、Preview)
※ちなみにAzure AD Premium P2のライセンスが必要な機能です。高いので私はトライアル版を使っています。

公式ブログ
 Azure AD + 3rd party MFA = Azure AD Custom Controls
 https://blogs.technet.microsoft.com/cbernier/2017/10/16/azure-ad-3rd-party-mfa-azure-ad-custom-controls/


ようやく試してみましたので、簡単に紹介して行きます。
ちなみに今回はDuoを試してみました。
(RSAはトライアル版がなかったのと、Trusonaは個別に設定をしてもらわないとダメらしく断念しました)

後、ちなみに自前でカスタムMFAプロバイダを作ってAzure ADと連携させるってこともプロトコル上は可能になっていますが、現状はマイクロソフトに承認を受けたプロバイダしか登録が出来ないということなので、こちらはもし調整がついたらやってみたいと思います。

では早速。

◆Duoのアカウントを作る

まずはココからです。
Duoのサイトへアクセスし、右上にあるStart Trialをクリックすると無償トライアルへのサインアップが出来ます。
登録を進めると、アカウントのアクティベーションを行う場面が出てきます。

ここではDuo MobileというモバイルアプリをインストールしてQRコードを読み込む必要があります。
早速インストールしてADD AccountでQRコードを読み込みます。
うまく追加できるとこんな感じでアカウントが表示されます。


横道にそれますがDuo Mobileは端末の状態を確認して問題があると警告を出してくれます。問題があると画面の下部に表示されるのでFix Nowをタップすると詳細が見れます。
今回はiOSが最新でない、という警告でした。他にもTouch IDが有効になっているか、とか脱獄していないか、などについて確認が行われます。

なんだかんだでセットアップが完了するとDuoの管理コンソールへたどり着きます。


ひとまずこれでDuoのアカウント作成は完了です。

◆Azure ADと接続するためのアプリケーション設定を行う

ややこしいんですが、Azure ADから見てDuoはIdentity Providerです。ということは、Duoから見るとAzure ADはRP、つまりアプリケーション(OAuthクライアント)となります。
(ちなみにAzure ADとDuoの間はOpenID Connectで繋がります)

ということで、Duo上にAzure ADをアプリケーションとして登録する必要があるのですが、DuoではプリセットでAzure ADと接続するための設定が入っていますので、こちらのテンプレートを使っていけば非常に簡単にセットアップが出来ます。

アプリケーションの検索画面に「Microsoft」とキーワードを入れるとAD FSやOWAなどと共にAzure ADが出てきますので、こちらを選択します。

アプリケーション設定画面に行くとシンプルに「Authorize」というボタンが現れますので、こちらをクリックしていきます。

するとAzure ADのログイン画面が出てきますので、管理者でログインします。するとAzure ADのディレクトリへの読み取り権限などを要求されるので認可を行います。
ちなみに、DuoでMFAしてログインする通常の流れにおいてはDuoがIdP、Azure ADがRPという構成ですが、ここではディレクトリの情報を読み出すためにDuoがRP、Azure ADがIdPという構成になります。ややこしいですね。

上手くいくと、Duoの管理画面にAzure ADに設定するための構成情報(json)が表示されます。

ここで表示されるjsonは後でAzure AD側に設定するのでコピーしておきます。

これでDuo側の設定は完了です。
非常にシンプルです。

◆Azure AD側にDuoをカスタムMFAプロバイダとして登録する

DuoのようなカスタムMFAプロバイダは条件付きアクセスの一つの条件として扱われます。そのため、設定は条件付きアクセスの中のCustom controlsというメニューから行います。(Azure AD Premium P2のライセンスが割り当たっていないとこのメニューは出てきません)

ここでNew custom controlをクリックすると、いきなり巨大なテキストボックスが現れるので、先ほどのjsonを貼り付けてCreateをクリックします。

これで完了です。
上手くいけば、こんな感じで一覧にDuoが出てきます。

後は、普通の条件付きアクセスと同じです。
ポリシーを書く時のControlとしてDuoMFAを要求する、という形で設定すると条件に当てはまったアクセスだとDuoのMFAが要求されます。


◆テストしてみる

ポリシーの作成が終わったら念のためポリシーの適用が正しく行われるか確認してみます。
 ※事前に確認するには先日紹介したWhat Ifを使うと便利です。
 http://idmlab.eidentity.jp/2018/01/azure-adwhat-if.html

該当のユーザでの初回アクセスだとMFA設定を促されますので、画面に従いMFA設定を進めます。

利用するMFAの方法を選択します。

モバイルを選択したので、携帯の番号は入れさせられます。この辺りはAzure AD純正のMFAと一緒ですね。

何故かモバイルの種類を選択させられます。アプリのインストールを促すためでしょう。

既にインストール済みなのでI have Duo mobile installedを選んでスキップします。

ここでようやくQRコードが出てくるので先ほど管理者がやったのと同じくアプリを使ってアクティベーションを行います。

上手くアクティベーションが終わると、認証の方法を指定します。
毎回方法を聞いてくるか、PUSH通知 or ワンタイムコードの表示をあらかじめ指定しておくことが出来ます。
ここでは毎回方法を聞いてくるように指定しました。

ここで設定が終わったので、ようやく実際のMFAです。(次からはこの画面がスタート地点になります)
毎回聞いてくるように指定をしたので、方法を選択する画面が表示されます。

PUSHを選択するとモバイルアプリに通知がされてきます。

この辺りは純正と同じですね。
ここでApproveをするとログインが完了します。

◆補足(id_token_hintの利用について)

ちなみに、アプリ⇒Azure AD⇒Duoという流れでFederationが連鎖している状態でのMFAをやろうと思うと、セッション管理をちゃんと実施しないといけません。通常はAzure ADのIdPがDuo、という構成だとDuoで認証されたらそのままAzure ADでも認証されたことにしてしまうためです。
Azure ADが外部MFAプロバイダ連携をする際、セッションをコントロールするためにid_token_hintというものを使っています。

OpenID Connect coreのスペックではid_token_hintについて以下のように記載されています。
Authorization Server が以前発行した ID Token. Client が認証した End-User の現在もしくは過去のセッションに関するヒントとして利用される. もしこの ID Token に紐づく End-User が認証済, もしくはこのリクエスト中で認証された場合, Authorization Server はポジティブレスポンスを返す. さもなければ, Authorization Server は login_required のようなエラーを返す (SHOULD).

つまり、最初にAzure ADでID/PWDで認証された結果の情報をid_token_hintに入れた状態でDuoへ渡し、Duoで追加の認証が上手く行われたらポジティブレスポンス(何を返すか、についてはjsonの中に書いてある通りで、Duoの場合はMfaDoneというメッセージを返します)をAzure ADへ返します。

Azure ADからDuoへPOSTされるid_token_hint。認証されたユーザの情報が入っています。

これに対してDuoからの返事となるid_token。成功したのでMfaDoneが返っています。


細かくはスペックを読みましょう。
http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html



2018年2月7日水曜日

[Azure AD B2C]複数SNSアカウントの連携、GitHub連携等の追加機能がリリース

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

Azure Active Directory B2C(Azure AD B2C)の追加機能のリリースがアナウンスされています。

公式Blog
 Lots of News about Azure AD B2C feature updates!
 https://cloudblogs.microsoft.com/enterprisemobility/2018/02/05/lots-of-news-about-azure-ad-b2c-feature-updates/

これまでAzure AD B2Cの弱みの一つだったのが、SNSアカウントでサインアップしたAzure AD B2Cアカウントを他のSNSアカウント変更したり、追加で別のSNSアカウントを追加で紐づけることが出来なかった、という点でした。

これまでは、カスタマイズをすることにより、以下を実現してきました。
・ローカルアカウントにSNSアカウント(同時に一つだけ)を紐づける
 *Graph APIで作成したアカウント、もしくはメールアドレスとパスワードでサインアップしたアカウント
・上記のアカウントに紐づけたSNSアカウントを別のSNSアカウントへ紐づけ直す
 *同時に一つだけ、という制限があり最初に紐づけたSNSアカウントでログインは出来なくなる
※他にも色々とトリッキーなカスタマイズすれば出来ることは多々あるのですが、ここでは解説しきれないので省略します。


今回のリリースでGraph API経由でSNSアカウントの識別子をAzure AD B2Cへ書き込むことが出来るようになったため、このカスタマイズが柔軟に出来るようになりました。
(Preview機能、かつGraph APIを使った開発は必須。頑張ればカスタムポリシーでも組めなくはないとは思いますが)

このGraph API辺りの詳細は別途書こうと思います。


他にリリースされた機能は以下の通りです。
<プレビューとしてリリース>
・パスワードポリシーのカスタマイズ
・監査ログの出力(id_tokenやaccess_token、認可コードの発行の記録など)
・外部Identity ProviderとしてGitHubと連携
・多言語対応の強化
・アクセストークン関連の強化(Client Credentialのサポート?)
<正式リリース>
・外部Identity Providerとしてtwitterと連携
・Graph API(ver. 1.6)経由でのSNSアカウント識別子の操作(先ほどの話)


GitHub連携はこれまでカスタマイズで対応していたので、正式対応したのはとても助かります。他にもInstagramなど独自カスタマイズで実装してしまっている連携先も色々とあるので、基盤側で取り込んでもらえると楽になれそうな気がします・・・


今後も色々と拡張が予定されているようなので引き続きウォッチしていきたいと思います。
ちなみにまだデプロイ中らしく、テナント毎に徐々にこれらの機能が有効化されてくるそうです。ゆっくり待ちましょう。

2018年2月2日金曜日

第1期 LINE API Expert に認定されました!

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

LINEさんが新しく始めたLINE API Expertに第1期生として認定されました。
主にLINE Login周り+Bot少々ですね。


LINEさんのプレス
LINEが提供するAPIなどの技術普及促進プログラム「LINE API Expert」、初の認定となる4カ国22名のメンバーを発表
https://linecorp.com/ja/pr/news/ja/2018/2030
今回は砂金さんが書いたLINE Engineering Blog
LINE API Expert第一期メンバーを発表します
https://engineering.linecorp.com/ja/blog/detail/248

今回は4か国22名が認定され、日本はそのうち5名、Loginは私だけ・・・やっぱりBot(Messaging API)の方がメジャーですもんね。(しかし錚々たるメンバー...)


この前の9月に本職でプレス発表させていただいたAzure AD B2C + SNS連携のB2C向けID+メッセージング基盤を開発するにあたり春先からLINE Loginを触らせていただいていていますが、秋のLINE Developer Dayで発表されたOpenID Connect対応など、どんどん進化していっているので非常に面白いプラットフォームになってきていると思います。

B2Cシナリオ以外にも組織の中へ自分のIDをどうやって持ち込むか、というBring Own Your Identity(BYOID)のシナリオも今後増えてくると予想しているので、Microsoft MVPとしてAzure ADなどのIDプラットフォームに加えてLINE APIについても引き続き情報発信などしていければ、と思います。

2018年1月22日月曜日

[Azure AD]条件付きアクセスのポリシー適用状態を確認する「What If機能」

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

Azure Active Directory(Azure AD)の条件付きアクセス機能を使うとアクセス元のネットワークやデバイス、クライアントアプリケーションの種類により、アプリケーションへのアクセスを制御(ブロックしたり多要素認証を要求したり)することが出来ます。

実際の案件で条件付きアクセスがどうやって使われているのか?については昨年のde:codeで紹介させていただきましたので、見てみてください。



ただ、この条件付きアクセスですがテストをするのが結構面倒なんです。当たり前ですが、すべてのアクセス元のネットワーク、デバイス、クライアントの種類を網羅的に準備することは中々現実的ではないので。

ということで先日新しくリリースされた条件付きアクセスのポリシーの適用状況をシミュレーションしてくれるテスト機能「What If」を使ってみます。


使い方は非常に簡単で、Azure ADの条件付きアクセスの設定画面からポリシー一覧を確認すると「What If」というボタンがあります。


これをクリックするとユーザ、対象のアプリケーションなどシミュレーションしたい条件を設定することが出来ます。

まず、ユーザを選びます。

次に対象アプリケーションを選びます。(すべてのアプリ、でもOKです)

後はアクセス元のネットワークアドレスとデバイスの種類、クライアントアプリケーションの種類を選択して、「What If」をクリックします。


すると適用されるポリシー一覧が表示されます。
この場合は多要素認証を適用するポリシーが出てきましたので、この条件だと多要素認証を要求されることがわかります。

逆に適用されないポリシー一覧も確認できます。その際に適用されない理由も含めて確認が出来るので、非常に便利です。



条件付きアクセス・ポリシーのネットワークアドレスの変更など構成変更をする際、事前にテストが出来るのでとっても便利です。

2018年1月18日木曜日

[告知]統合認証シンポジウム@佐賀大学で大学におけるSNSの活用について話します

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

昨年に引き続き今年も佐賀大学で開催される統合認証シンポジウムに登壇させていただくことになりました。

第11回統合認証シンポジウム
https://www.cc.saga-u.ac.jp/ias/#gsc.tab=0

日時:2018年3月1日(木)13:30~17:30
場所:佐賀大学教養教育大講義室


思えばLINEとAzure AD B2Cを組み合わせて学生や保護者などへのリーチャビリティの高いコミュニケーション基盤とそれを支えるID基盤のアイデアは昨年度の統合認証シンポジウムの後の宴会の場で産まれたものでした。最初は半分酔っ払いの思いつきでしたが、色々やってみると応用の範囲が思いのほか広くビジネスになってしまうのが面白いところです。

と、言うことで昨年度はエンタープライズID管理のトレンドの話をしましたが、今年は大学におけるSNS IDの活用についてお話しします。
他にも著名な先生方が大学における業務改善のお話しをしてくださったり、お馴染み日本マイクロソフトの中田さんがOffice365の多要素認証についてお話ししてくださるそうですので、大学だけでなく一般企業においても有益な内容になると思います。

既に申込みも始まっていますので、是非お申込みください。

2018年1月15日月曜日

[Azure AD/Intune]ログイン画面からPINをリセットする(モバイル編)

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

前回はAzure AD JoinしているWindows 10 PCのPINをログイン画面からリセットする方法を紹介しましたが、今回は今更ながらですがWindows 10 MobileのPINをリセットする方法です。

今更ではありますが、最近Lumia 950を滅多に起動しなくなり、PINを忘れてFactoryリセット、、、という繰り返しをしていたので、最初からこの方法を実装しておけばよかった・・・と後悔したので。。

さて、やり方ですが実装方法は前回とほぼ同じですが、リセットの方法が若干異なります。(管理者がIntuneの管理画面からリセットします)

ということで早速。

◆必要な物、準備事項

  • デバイス
    • Azure AD参加したWindows 10 Creator Updateが動作しているデバイス(Creator Update/1703からこの機能は使えるとドキュメント上は書いてあります。が、私の環境が既にFall Creator Update/1709だったので1709でしか試していません)
  • ライセンス
    • 該当ユーザにIntuneのライセンスが割り当たっていること
  • 設定
    • IntuneでPINリセット用のプロファイルを構成していること

◆Intuneでデバイス構成プロファイルを作成する

ここはPC用と同じプロファイルが使えるので、前回紹介したものをそのまま使います。
尚、ドキュメント上はMicrosoft PIN Reset Service IntegrationとMicrosoft PIN Reset ClientをAzure AD上にプロビジョニングしておかないとダメ、とありますがどうやらこの手順は無くても動きそうです。(どうしても動きがおかしい場合は試してみても良いかも知れませんが)

念のため、Microsoft PIN Reset Service IntegrationとMicrosoft PIN Reset Clientのプロビジョニング方法です。

- Microsoft PIN Reset Service Integration

Intuneテナントの管理者でこのURLにアクセスし、ディレクトリへのアクセス権限を与えます。

承諾すると、エラーが出ますがこれでOKです。

- Microsoft PIN Reset Client

同じくIntune管理者でアクセスします。

こちらもエラーが出ますがOKです。
(カスタムスキームだったので、Azure AD Joinした端末へIntune管理者でログインしたり、Windows 10 Mobileからアクセスしてみましたが、結果は同じだったのであまり関係ないのかも知れません)


エラーは出るものの、上記2つを実行することでAzure AD上にサービスがプロビジョニングされます。私の環境ではあっても無くてもPINリセットは実行できたので無くてもOKかも知れません。


◆リセットする

モバイルの場合はPCとは異なり、ログイン画面から自分自身でPINをリセットすることはできず、あくまでIntune管理者へリセットを依頼することになります。

- 管理者によるリセット要求

Intuneの管理画面で対象のデバイスを選択、Overviewの一番右上のドロップダウンよりReset passcodeを選択します。

確認画面が出てリセット要求が行われます

しばらく(5分~10分くらい)して画面をリロードすると新しいPIN(テンポラリPIN)が表示されます。(7日間表示されるので、この間に利用者へ通知してリセットさせるという方式です)

- 利用者側の操作

管理者がPINのリセット要求を行うと一時的に端末がロックされます。

完了を押すと管理者から聞いたテンポラリPINコードを入力する画面が出てきますので、入力します。
(尚、不具合だと思うのですが、管理者側で発行したテンポラリPINコードにモバイルのキーボードで入力できない文字記号が含まれることがありました。その場合は再度管理者にテンポラリPINコードを発行してもらう必要があります)

入力が完了すると、自身で使うPINを登録することが出来るようになります。ここで設定したPINが以降デバイスのロック解除を行うPINとなります。

上手くいけばデバイスを使えるようになります。



もうWindows 10 Mobileを使うことも減ってくるとは思いますが、PINを忘れるたびにリセットして写真やデータが消える、ということもなくなるので使用頻度が減ってきた今がPINリセットを実装しておくべき時なのかも知れません。