APIゲートウェイでSaaSのIDを簡単に管理する①

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

先日、CDATAさんのイベントで、CDATA API Serverを利用してローカルADのアカウントをSalesforceへプロビジョニングする、というデモをお見せしました。

当日は時間も限られていたのと、あくまでAPI Serverの活用事例の一つとして紹介したので、あまり細かい話はしなかったのですが、ID管理をやっている方々からは、このデモの仕組みをもう少し細かく知りたい、という声も頂いたので少し細かくご紹介していきたいと思います。

当日の資料はこちら。

アイデンティティ API とデータ統合プラットフォームの活用 from Naohiro Fujie

まずは、どのようなデモをお見せしたのか、動画を用意しているので最初にこちらをご覧ください。

使っている道具は、
・オンプレミスのActive Directory
・Azure AD Connect＋REST Management Agent（カスタム）
・Azure Active Directory
・CDATA API Server 2017J
・Salesforce.com
です。
*ちなみにAzure AD ConnectへカスタムManagement Agentを組み込む場合、所定の手続きを踏まないとサポート対象外となります。今回は手元にちょうどあった環境を使ったのでAzure AD Connectを使いましたが、本番環境ではMIM（Microsoft Identity Manager）やExgen LDAP Managerなど汎用的なID管理ツールを使ってください。

こんなことをしなくてもAzure ADから直接Salesforce.comへプロビジョニングすればいいじゃん、という話はありますが、手軽にテナントが用意できるSaaSなのであえてSalesforce.comを選択しています。もちろんCDATA API Serverが接続用のドライバを持っているサービスであれば何でも構いません。


では、早速環境の解説をしていきます。

１．オンプレミスのActive DirectoryからAzure ADへの同期環境を構成する

これは、特に特殊なことはしていません。Office365向けのID基盤を構築する時と同様にAzure AD Connectを構成します。

ものすごいシンプルな構成です。ローカルADもexample.localですし。。。

２．Salesforce.comのテナントを用意し、Azure ADとシングルサインオンを設定する

これも良くあるものなので、何も細かいことは気にしません。
以下の手順で設定をしていきます。

・Salesforce.comへのカスタムドメインの追加

・Azure ADにSalesforce.comアプリの追加とシングルサインオン設定
　サインオンURL、EntityIDにSalesforce.comに設定したカスタムドメインを指定し、証明書をダウンロードしておきます。

・Salesforce.comへAzure ADとのシングルサインオン設定
　Azure ADからダウンロードした証明書のアップロード、Issuerの設定、SSO URI、SLO URI、Salesforce側のEntityIDの設定を行います。設定すべきURI等の情報はAzure ADの設定ページに手順を含め記載されています。

ここまででシングルサインオンは出来るようになります。

３．API ServerとSalesforce.comを接続する

API Serverはここから評価版のダウンロードができます。
http://www.cdata.com/jp/apiserver/

ただ、この本体にはSalesforce.comとの接続に使うドライバが同梱されていないので、別途Salesforce.comドライバ（ADO.NET版）をダウンロードします。
こちらも評価版があります。
http://www.cdata.com/jp/download/?f=ado

インストール自体は次へ、次への世界なので何も気にすることは無く、インストールが終わるAPI Serverが起動してきます。
ちなみにデモでは手元のWindows 10の端末で動かしています。

設定メニューより接続タブを開き、新規に接続先を追加します。

接続先アプリケーションとしてSalesforceを選択します。

Salesforce.comへの接続に使うユーザIDとパスワードを入れ、保存します。

ちなみに、信頼されていないネットワークから接続している場合は、セキュリティ・トークンの設定が求められることがあります。

このエラーが出た場合は、Salesforce.comに管理者でログインし個人の設定からセキュリティ・トークンをリセットし、メールで送られてくるセキュリティ・トークンをAPI Serverに設定します。

次に、Salesforce.comのユーザを管理しているテーブルをAPI Serverのリソースとして定義し、REST APIとして公開します。
同じく、設定メニューの中のリソースタブを開き、リソースを追加します。

データソースに先ほど定義したSalesforce.comへの接続を選択します。

ユーザ情報が格納されているテーブルの名前はその名の通りUserなので、選択して保存します。

Userテーブルのカラム一覧が自動的に取得されるので、そのまま保存します。

ここまででSalesforce.comのUserテーブルをAPI ServerがREST APIとして公開できました。
最後にAPI接続を行うためのAPI Server上のユーザを定義します。
ユーザタブを開き、追加をします。

ユーザ名と実行できるメソッドを指定して保存します。

保存すると認証に使うAuthトークンが表示されるのでユーザ名と合わせてメモしておきます。

これで設定は完了です。

接続確認としてユーザ一覧を取得してみます。
APIメニューを開き、先ほど作成したリソースを開くとエンドポイントとメソッドが出てきます。

今回はテストなのでユーザ一覧を取得するので、単純にUserエンドポイントをGETします。
BASIC認証がかかり、ダイアログが出てくるので先ほど作成したユーザとAuthトークンをID、パスワードとして入力します。

上手くいくと、ユーザ一覧がODATA形式で取得出来ます。

これで、API Server経由でSalesforce.com上のユーザを操作するための準備はすべて整いました。

後は、Azure AD ConnectからAPI Serverで公開したAPIを叩くだけです。
この部分は若干コードを書くので、次回詳細は解説したいと思います。

ということで今回はここまでです。

[Azure AD] IE/Edge以外でAzure ADにSSOする（Desktop SSO）

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

これまでAD FSとAzure ADを比較する際に重要なポイントの一つだったのが、PCへのログオンからブラウザ・アプリケーションへのシングルサインオンです。これをDesktop SSOと呼んでいます。

AD FSは統合Windows認証が利用できるので、ドメインネットワークではDesktop SSOが実現できましたが、Azure ADの場合はWindows 10でWindows Hello for Businessを使わないとDesktop SSOは実現できませんでした。

また、AD FSの場合はChromeやFirefoxなどIE/Edge以外のブラウザでもDesktop SSOを行う方法がありましたが、Windows Hello for Businessを使った場合はIE/Edge以外のブラウザでDesktop SSOを行うことはできませんでした。

参考）MVP渡辺元気さんのBlog　：　「IE以外でADFSにSSOする」
　　　　http://blog.o365mvp.com/2014/07/07/sso_adfs_without_ie_2012r2/


この課題を解決するために新たなAzure ADの機能「Desktop SSO」のプレビュー版として公開されました。

　公式アナウンス
　　Enterprise Mobility and Security Blog
　　Introducing #AzureAD Pass-Through Authentication and Seamless Single Sign-on
　　https://blogs.technet.microsoft.com/enterprisemobility/2016/12/07/introducing-azuread-pass-through-authentication-and-seamless-single-sign-on/

　詳細ドキュメント
　　https://docs.microsoft.com/en-us/azure/active-directory/active-directory-aadconnect-sso


　動作イメージ（公式ドキュメントより）

このAzure AD Desktop SSOを利用すると、Windows 7/8/8.1/10のPCにおいてChromeやFirefoxを使った場合でもシームレスにAzure AD連携しているアプリケーションへサインオンできるようになります。（Windows 7/8/8.1でIEを使った場合でもSSOできるようになります）


セットアップは簡単で最新版のAzure AD Connectを使い、

• 認証方式に「Password Hash Sync」もしくは「Pass-Through Authentication」を設定する
• イントラネットゾーンに以下の2つのURLを入れる
• https://autologon.microsoftazuread-sso.com/
• https://aadg.windows.net.nsatc.net/

の2つを行うだけです。

結果、こんな感じで動きます。
Azure ADのログイン画面でIDを入れるとパスワードを入れることなく自動的にサインインが行われます。

ますますAD FSを使わなくても実現できることが増えてきました。。。。

[小ネタ]Azure ADからGoogle Appsへのプロビジョニング

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

今回は小ネタです。しかも事象からの推測ですのでタダの都市伝説かもしれません。

ご存知のとおり、Azure Active Directory（Azure AD）が持つアプリケーション連携の機能には「シングルサインオン」と「プロビジョニング（ID同期）」の2つがあります。

で、今回はプロビジョニングに関する小ネタです。
※プロビジョニングの細かい設定方法は以下の動画をどうぞ。（IdM実験室別館より）
　https://channel9.msdn.com/Blogs/IdM-Lab-Annex-MVP-for-Directory-Services-Naohiro-Fujie/AAD-Setup-App-3

Google Appsへユーザを新規にプロビジョニングした場合、作成されたユーザのステータスが「無効」になっている場合と「アクティブ」になっている場合があります。

＜そもそものGoogle Appsの仕様は？＞

Google Admin SDK Directory APIの仕様を見ると、新規に作成されたユーザはサスペンドされ（suspendedにtrueがセットされ）、サスペンド理由（suspensionReason）にWEB_LOGIN_REQUIREDがセットされ、初回ログイン時にアクティベートされる、と書いてあります。
https://developers.google.com/admin-sdk/directory/v1/reference/users
抜粋）

A new account is automatically suspended by Google until the initial administrator login which activates the account. After the account is activated, the account is no longer suspended

しかし、先に書いた通りAzure ADからユーザをプロビジョニングすると最初からsuspendedがfalseのユーザ（アクティブ）ができる場合と、仕様通りtrueのユーザ（無効）の両パターンができる場合があります。

＜Google Apps上のユーザの状態＞

＜有効なユーザ＞

Directory APIでGoogle Appsを直接見ると、suspendedがfalseになっています。

この状態でログインすると、規約への同意をすればすぐにサービスが使えます。

＜無効なユーザ＞

同様にAPIを直接たたくとsuspendedがtrue、suspensionReasonがWEB_LOGIN_REQUIREDとなっています。APIドキュメント通りです。

この状態だと、ログイン時に本人確認が走ります。

＜Azure AD上でのアカウント状態の違い＞

何が違うのか？を追うためにAzure AD上でのユーザの違いを眺めると、、、

最初からアクティブになるユーザ：オンプレミスのADから同期されてきたユーザ
無効となるユーザ：Azure AD上に直接作ったユーザ

という違いがありました。
本当にこれが原因なのかどうかはよくわかりませんが、少なくとも私のテナントではこの部分しかアカウントの違いがなく、何ユーザ試してみてもこの動きになったので、何か関係しているのかもしれません。

マイクロソフトやGoogleに確認した訳ではないので、厳密には良くわかりませんが。。。

[Windows 10]Azure ADに参加したPCへリモートデスクトップ接続する

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

Windows 10がリリースされてから、Azure ADへの参加やHybrid構成など検証したいことはたくさんあるのですが、いかんせんクライアントOSなので都度手元の端末をセットアップしなおして、、というのが非常に煩雑です。

そんな時のAzure VMなのですが、Windows 10のイメージをVMで作っても接続がリモートデスクトップになるので、Azure ADへの参加するところまでは行けてもAzure AD上のユーザでどうやってログインしたら？？？という疑問がわいてきます。

単純にAzure AD上のユーザを入力してもログインできません。


と、いうことで、今回はちょっとした工夫をしてみます。
（Morgan Simonsen氏が検証していましたのでその方法の紹介です）

◆接続先コンピュータでの作業
流れとしては、リモート接続設定の構成変更およびAzure ADユーザで接続できるように権限設定を行っておきます。

リモートデスクトップの接続許可の「Allow connections only from computers running Remote Desktop with Network Level Authentication」のチェックを外します。

次に、「Select Users」を開いて「Authenticated Users」を追加します。

これで接続先コンピュータでの作業は終わりです。
（もちろん事前にAzure ADへの参加はしておいてください）

◆接続元コンピュータでの作業（RDPファイルの編集）
今度は接続元での作業です。

Azure VMを作成し接続するとRDPファイルがダウンロードされますので、こちらを直接編集していきます。
具体的にはメモ帳などでRDPファイルを開いて、以下の2行を追記します。
enablecredsspsupport:i:0
authentication level:i:2

編集後、保存します。

これで準備は整いました。

◆接続する
では接続するので、RDPファイルをダブルクリックで開いてみます。
すると、通常はRDPを開いた段階で認証が走るのですが、接続先コンピュータのログイン画面が表示されます。
ここまで行けば、通常のローカルコンピュータと同じでAzure ADのユーザをログインを行います。

尚、ユーザ名には「Azure AD\hogehoge@xxxx.onmicrosoft.com」という形で入力します。
※接続先コンピュータがTH2であれば、UPN（hogehoge@xxxx.onmicrosoft.com）だけでもログインできます。

無事にリモートログインできました。
ブラウザを起動してAzure AD連携しているアプリケーションにアクセスすると無事にMicrosoft Passportも動作しており、シングルサインオンできます。


ネタ元）
http://morgansimonsenblog.azurewebsites.net/2015/11/06/connecting-to-an-azure-ad-joined-machine-with-remote-desktop/

[Windows 10]TH2新機能 - BYOD（WorkPlace Join）でMicrosoft Passportを使う

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

Windows 10初の大型アップデートである「Threshold 2」が公開されましたので、早速新機能を順番に見ていきたいと思います。

なんといってもアイデンティティ屋さんにとっての一番大きなアップデートはBYODシナリオにおけるMicrosoft Passportのサポートです。

これまではAzure AD JoinのシナリオでしかMicrosoft Passportが使えず、職場のアカウントを追加（WorkPlace Join）してもOffice 365などへのシングルサインオンはできませんでしたが、今回のビルドからはMicrosoft Passportが使えるようになったので、BYODシナリオでもしっかりシングルサインオンしてくれます。

では、早速設定してみます。

今回は、ローカルアカウントを使ってPCにログインしていますが、その状態でアカウントの設定を開き、職場のアクセスメニューを開くと、これまでのビルドとは大きく異なるメニュー構成となっていますので、Azure ADにサインインをしてみます。

すると、なぜかメールとアカウントの画面に飛ばされるので、「他のアプリで使われるアカウント」から「職場または学校アカウントを追加」をクリックします。

お決まりのAzure ADへのログイン画面が出てくるのでサインインしていきます。

多要素認証が必要なので、通知が飛ばされます。

ポリシーが適用されていきます。
このあたりのポリシーの中身はIntuneなんかで設定します。

作業PINの作成が要求されます。

作業PINなのか職場用PINなのかいまいちわかりませんが、気にせずPINを登録します。

作成が終わると準備完了！と言われます。

アカウントが追加されていることが確認できます。

さて、ここまでで準備は完了ですので、早速ログインしてみます。
そのままブラウザを起動し、アクセスパネルなどAzure ADと連携しているアプリケーションを立ち上げると、Microsoft Passportが有効になり、シングルサインオンされます。

なお、Azure AD上に登録されたデバイスを確認してみると、WorkPlace Join端末であることがわかります。

今後、Windows Server 2016も出てきますので、Microsoft Passportの適用範囲もさらに広がってくると思いますので、非常に楽しみな分野です！

[Google/ACS]6/1を迎えてAzureACSのGoogle IDプロバイダーはどうなった

2015/04/20をもってGoogleのOpenID 2.0のサポートが終了し、マイクロソフトもAzure ACS（アクセス制御サービス）のGoogle IDプロバイダー設定を6/1までに変更するようにアナウンスを出していました。

関連ポスト）
　GoogleのOpenID 2.0サポート終了による影響いろいろ（Azure ACS編）
　http://idmlab.eidentity.jp/2015/03/googleopenid-20azure-acs.html

　[Google]4/20を迎えてAPIはどうなった？
　http://idmlab.eidentity.jp/2015/04/google420api.html


と、いうことで6月を超えたのでACSがどうなったのかを確認してみました。
結果、まだOpenID 2.0が動いています。結構しぶといです。
（人によって動いていない、という話もあるようなので環境に依存するのかもしれません）

これまで通りの動きです。
１．アプリケーションの認証の設定を行います。

２．実行するとレルムディスカバリ画面がでます。

３．Googleアカウントでログインします。

４．認可をおこないます。

５．アプリケーションからGoogleの属性が取得できています。

このように中々しぶとい状況ですが、MSDNには以下のアナウンスが出ています。
https://msdn.microsoft.com/ja-jp/library/azure/dn927169.aspx

・2015 年 6 月 1 日 - ACS 名前空間は Google の OpenID 2.0 実装の使用を停止します。この日までに、ACS 名前空間の移行を完了して、Google OpenID Connect を使用する必要があります。この日までは、移行中に問題が発生しても、OpenID 2.0 にロールバックできます。
ほとんどの場合、アプリケーション コードの変更は必要ありません。アプリケーションに関連付けられているルール グループに ID プロバイダーとしての Google に対して "すべての要求をパススルーする" というルールが存在する場合は、コードの変更が必要になる場合があります。これは、移行によって Google からの新しい要求の種類 (サブジェクト) が ACS で利用可能になることから、アプリケーションが新しい要求の種類の存在を適切に処理できるようにコードを変更する必要が生じる場合があるためです。移行を正常に完了させるうえで、アプリケーションで新しい要求の種類を処理する必要はありません。
・2017 年 1 月 1 日 - Google の OpenID 2.0 と OpenID Connect の実装では、Google ユーザーを一意に識別するのに、異なる識別子を使用します。ACS 名前空間の移行後は、現在の OpenID 2.0 識別子と新しい OpenID Connect 識別子の両方をアプリケーションで使用できるようになります。この日までにバックエンド システムでユーザーの識別子を OpenID Connect 識別子に切り替え、以降は OpenID Connect 識別子のみを使用する必要があります。これには、アプリケーション コードの変更が必要です。

ACS側の移行が終わっても次は2017/01/01までに従来のOpenID 2.0で使っていた識別子（nameidentifier）ではなく、OpenID Connectの識別子（subject）を使うようにアプリケーションの改修を行う必要があるようです。
ACS側でのクレームのマッピングを修正する形にしたほうが柔軟な気もしますので、私ならACSのクレームマッピング（規則グループ）を変えますが。。
※この図のnameidentifierとsubjectのマッピングを合わせてあげる形にします。既存アプリケーションはnameidentifier属性を見ているはずなので、OpenID Connect対応した際にGoogleから取得できるようになるsubject属性を出力側のnameidentifier属性にマッピングしてあげればアプリケーションを改修する必要はありません。

まだまだ余裕はありますが、こちらの改修も早めに実施しておいたほうがよさそうですね。

※使えなくなる瞬間どうなるのかを確認したいので、あえてACSの設定を移行せずに残してあるのですが、中々使えなくならないので、今後も引き続きウォッチしていきたいと思います。