2018年3月5日月曜日

[告知]ISACA大阪支部月例会でID管理チェックリストについてお話しします

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

1月にJASAの定例研究会でID管理チェックリストについてお話しさせていただいたのですが、ほぼ同じ内容で今度はISACA大阪支部の月例会でお話しさせていただきます。

ちなみにJASAのイベントの様子はこちらです。
 JASAのイベント開催レポート
 http://www.jasa.jp/seminar/monthlyreport.html


詳細、申込はこちらからどうぞ。
 http://www.isaca-osaka.org/global_EventsDetail.php?eventsId=33

3月19日(月)が申込期限です。関西の方、ぜひお申込みください。(関西でこの手のイベントをやるのは結構レアですし)

前回より持ち時間が長いので、ネタを考えないと・・・

2018年3月3日土曜日

[LINE Login]emailアドレスをid_tokenに含めることが出来るようになりました

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

LINE Login v2.1で新たにメールアドレスが取得できるようになっています。

https://developers.line.me/ja/docs/line-login/web/integrate-line-login/#applying-for-email-permission

ポイントは以下の通りです。

  • 事前に申請が必要(ユーザに表示する同意画面のスクリーンショットが必要)
  • 特に承認の連絡はなく、いつの間にかメールアドレスが取得できるようになる
  • id_tokenの中のクレームとして取得できる
  • 当然ですが、scope指定でemailを設定する必要がある

以前は個別にパートナー登録が必要、かつprofile apiで取得しないと取れなかった属性なので大きな進歩です。

ということで、やってみます。

◆申請

LINE Developerコンソールを開きます。

Channel設定の下の方にメールアドレス取得申請が出来ています。

ここで申請をします。

この際、同意文書のスクリーンショットが必要なので、あらかじめ用意しておきアップロードする。

申請済み、となるのでしばし待つ。(いつ有効になったのかは不明です。私は申請当日はテストできなかったので、翌朝テストしたら取得できました)


◆クライアントの要求scopeを修正する

メールアドレスを取得するので、scopeにemailを入れてあげます。

◆アクセスする

後は実際に取得できるか確認するだけです。
アクセスするとクライアントがメールアドレスへのアクセスを要求していることがわかりますので、同意します。

ちゃんとメールアドレスが取得できました。

まだまだ全ユーザがLINEのプロファイルにメールアドレスを登録している訳ではないと思いますが、他方でメールアドレス登録を必須としているアプリケーションやサービスも多いので、メールアドレスをLINEから取得できればユーザのID登録の手間を下げることができ、離脱率をさげることが出来ると思います。

是非、活用して行きましょう。

2018年3月2日金曜日

[SAML脆弱性] 外部IdPと連携している場合は要対応

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

#コメント部分が本ポストの中でもコメントとして扱われて消えてしまっていたので修正しました。tkudoさんご指摘あざーす
#その他、もろもろ修正しました。酔っぱらって夜中に斜め読みしたらダメですねw

DuoがSAMLの実装に関する脆弱性に関するレポートをしています。

 ZDNetの日本語版記事
 https://japan.zdnet.com/article/35115353/

#しかし、中身は「SAMLプロトコルの」脆弱性じゃなくて、SP実装の不具合なので、「プロトコルの脆弱性」は言い過ぎだなぁ、、と思います。

例によって記事になると何のことかさっぱりわからないので、元ネタとなるDuoのレポートを読んでみました。
(実際に実験は出来ていないので、また時間があれば試してみたいと思います)

Duoのレポート
 Duo Finds SAML Vulnerabilities Affecting Multiple Implementations
 https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations

#Oktaのブログもわかりやすいです。
 A Breakdown of the New SAML Authentication Bypass Vulnerability
 https://developer.okta.com/blog/2018/02/27/a-breakdown-of-the-new-saml-authentication-bypass-vulnerability

簡単にまとめるとポイントは、以下の通りです。

  • 外部IdPへの認証要求への返答として帰ってきたSAML ResponseのNameIDにコメントが含まれていると、正規化~署名検証時をした後、コメント部分より前の部分しかNameIDとして扱われず、別のユーザになりすますことが出来てしまう
  • 影響を受けるのは以下の製品・サービス
    • OneLogin
    • Clever
    • OmniAuth-SAML
    • Shibboleth
    • Duo Network Gateway
  • 原因はSAML ResponseのNameIDの値の間にコメント(<!-- コメント -->)が存在した場合に、コメントの後ろの値を無視してしまうため(例:hoge@example.jpとhoge@example.jp<!-- コメント -->.evil.jpが同じNameIDとして扱われてしまう)
  • 対応方法は対策済みバージョンへアップグレードすること

要するに、こんな感じです。

通常はSAML ResponseをSPが受け取る動きは以下の通りです。

今回指摘された正規化~検証後の値の取り扱いに関するバグがあるとこうなります。

NameIDがメールアドレス形式の場合はSP側で別のユーザになりすますのは難しいとは思いますが、NameIDが社員番号などの番号だった場合は割と容易になりすますことが出来そうです。

例えば、
 攻撃者が「123<!-- コメント -->456」
  というユーザでIdPで認証すると
 SPがSAML ReponseのNameIDを「123」として扱ってしまう(コメントより後ろの「456」を正しく連結してくれない)ので、
「123」という全く別のユーザとしてSPへアクセスできてしまうことになります。

まずは皆さんがお使いのSAML SP(もしくは外部IdPと連携しているSAML IdP)が本件に該当するかどうか、対応版がリリースされているかどうかを確認して対策を進めてください。

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