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とつないだ例です。




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


2017年9月28日木曜日

#linedevday 参加!LINE LoginがOpenID Connect対応したので早速試す

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

本日はLINE Developer Day 2017にお邪魔して来ました。

大盛況でした。
先日プレス発表させていただいた通り、最近はエンタープライズからコンシューマまで、と仕事の幅が広がっておりまして、その中でもLINEはやはり外せないのでちょっと場違いな感じがしつつもがっつりと朝から晩まで参加させてもらいました。

先日のプレス関係
 [リリース]LINE/Yahoo! IDを使ってOffice365へのログインを便利にする
 http://idmlab.eidentity.jp/2017/09/lineyahoo-idoffice365.html


先日のJICSでもお世話になった御代田さんの話を含め個人的な注目ポイントは、

  • LINE LoginがOpenID Connectに対応
  • 2018年春を目途に2要素認証とQRコードログインに対応
  • LINE LoginとBot連携(Botへの友達登録を認可に含められる)
  • LINE Login側でのセッション管理が可能に
  • Flexible Rich Menu APIでID連携状態の取得と動的なメニュー構成の変更

でした。

その中で取り敢えずLINE LoginのOpenID Connect対応とBot連携許可のあたりを試してみました。(Bot連携は特別にAPIを使えるように設定してもらいました)

ますはOpenID Connect対応です。例によってAzure WebAppsで簡単なアプリを書いて連携させてみています。

まずは仕様から。
ドキュメントはここにあります。
https://developers.line.me/en/docs/line-login/web/integrate-line-login/

API version 2まではOAuth2.0ベースでしたが、今回リリースされた2.1(刻むなぁ)からOpenID Connectベースとなったため、わざわざアクセストークンを取得してからProfileエンドポイントへ属性を取りに行かなくてもIDトークンに基本属性は入ってきてくれます。尚、メールアドレスや電話番号などこれまでパートナー向けのProfile APIでしか提供されなかった属性もIDトークンでは取得できるようになるようです。(現時点ではまだ取れません)

取り敢えずはcodeフローしか試していませんが、必要な情報は以下の通り。

  • Authorizeエンドポイント
    • https://access.line.me/oauth2/v2.1/authorize
  • Tokenエンドポイント
    • https://api.line.me/oauth2/v2.1/token
  • ClientID/Secret
  • Redirect Uri


若干エンドポイントに違和感が。。。v2.1って刻むなぁ、というあたりとAuthorizeエンドポイントとTokenエンドポイントのホスト名が異なるあたりががが。

ClientIDはLINE用語ではChannel ID、Client SecretはChannel secret、Redirect UriはCallback URLです。いずれもDeveloper Consoleで設定が確認できます。



尚、認可リクエストの際にbot_promptというパラメータをつけるとログインと同時にBotと連携することが出来ます。こんな感じのパラメータをつけてリクエストを書きました。
        'client_id'=>$client_id,
        'response_type'=>$response_type,
        'redirect_uri'=> $redirect_uri,
        'scope'=>'openid profile',
        'state'=>$state,
        'nonce'=>$nonce,
        'bot_prompt'=>'normal'

ちなみにbot_promptに'normal'を指定するとScope指定と同じような感じでBot連携を認可することが出来ますし、'aggressive'を指定すると認可後、Botとの連携許可画面が別途出てきます。



これまではLINE LoginとBot連携をしようとすると個別に友達追加をしないとダメでしたが、この拡張によりよりシームレスに連携が出来るようになりました。

ちなみにbot_promptをaggressiveにするとscope認可の後に友達追加画面が出ます。

※「ブロック解除」になっているのは、テストのため一旦友達になってからブロック~削除をしたためです。

取得できるIDトークンの中身はいたってオーソドックスで、従来のProfileエンドポイントで取得できたuserIDがsub、あとはdisplayNameとPictureUrlが取れるくらいです。



今後の話としては、discovery(well-known)やuserInfo(まぁ、Profileエンドポイントがあるので良いとは思いますが)がまだないので、実装するという話と、先に書いた通りメールや電話番号などの属性をIDトークンへ追加するあたりが予定されているということでした。OpenID FoundationのCertificationも目指すそうなので頑張って欲しいですね。






2017年9月20日水曜日

[FIM/MIM]Forefront Identity Managerのメインストリームサポートは2017年10月10日まで

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

そういえばForefront Identity Manager 2010/2010 R2/2010 R2 SP1のメインストリームがもうすぐ終了します。
https://blogs.technet.microsoft.com/iamsupport/2017/02/22/warning-forefront-identity-manager-fim-mainstream-support-is-ending-10102017/



まだFIMを使っている人もいないとは思いますが、まだの場合はMicrosoft Identity Managerへのアップデートが必要ですね。
MIMが出たての頃はアップデートするのにかなり苦労しましたが、最近はちゃんと設定関係の引継ぎもできるようになっているので、ぜひアップデートしましょう。

ちなみに拡張サポートは2022年10月11日までですが、バグフィックスなどの提供がベストエフォートになってしまいますので、自己責任運用になりますね。

ちなみに私の開発環境の一部がまだFIMなので・・・・面倒だけどこの際アップデートします。

2017年9月7日木曜日

[リリース]LINE/Yahoo! IDを使ってOffice365へのログインを便利にする

こんにちは、富士榮@北海道です。

たまにはお仕事の話です。

本日、Azure AD B2CとLINE、Yahoo! JAPAN IDを連携させるソリューションを雇用主よりプレス発表しました。

SNSアカウントを活用するシステムの構築サービスを開始
http://www.ctc-g.co.jp/news/press/20170906a.html

Impressさん、日経電子版などのメディアに取り上げていただけました。

IT Leaders
 http://it.impressbm.co.jp/articles/-/14950
日経電子版
 https://www.nikkei.com/article/DGXLRSP456311_W7A900C1000000/
クラウドWatch
 http://cloud.watch.impress.co.jp/docs/news/1079437.html

本日北海道大学で開催されたCloud Week 2017で、本件に関する講演を行いデモを含めお披露目をさせていただきました。



簡単に内容を説明すると、Azure AD B2Cをカスタマイズし、
・LINEやYahoo! JAPAN IDなどの日本でメジャーなIdPへの対応
・Office365やG SuiteなどSAMLアプリケーションへの対応
・Microsoft Graphを利用し、Office365に届く重要なメールをLINEへも通知
・個別、一斉でのSNSへのメッセージ配信
というような仕組みをくみ上げたサービスとなっています。



こんな感じです。

動いている姿は以下です。


こんな流れです。
1.LINEで友達になる
2.LINEメニューから組織の払い出したID/PWDでOffice365へログインする
3.LINE IDと紐づけを行う
4.重要なメールはLINEへも通知する様に設定する
5.LINE IDでOffice365へシングルサインオンする
6.Office365へ重要なメールが届くとLINEのタイムラインへも通知される


他にも、公衆無線Wifiへのユーザ登録の簡素化などにも使えます。WeChatなどの中国のSNSにも対応しているので観光客向けのサービスとして無線LANを提供するようなケースを想定しています。


公衆無線Wifiを使った不正行為やいたずらが増えてきているらしいので、サービスレベルの向上(登録の簡素化)と利用者への到達性、証跡の確保の両立をしたい場合などはうまく使ってもらえると思います。

追記)
Cloud Week 2017で使った資料を公開したので、張り付けておきます。



尚、今後は以下のイベントで詳細を説明していきますので、是非ご参加ください。
・9/15 Japan Identity & Cloud Summit 2017
 https://nosurrender.jp/jics2017/
・10/13 CTCフォーラム 2017
 https://www.event-site.info/ctcforum2017/
・11/08 Tech Summit 2017
 https://www.microsoft.com/ja-jp/events/techsummit/2017/
・12/13 AXIES年次総会
 URL未定

また、個別に仕組みが知りたい、という方はぜひご連絡ください!
(標準のAzure AD B2Cでは出来ないことを独自拡張でかなりカバーしているので)

2017年8月23日水曜日

[Azure AD/Office365]Azure AD Connectでカスタムコネクタを使用する

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

先日公開したAzure AD ConnectとCDATA API Serverを組み合わせたSalesforce.comへのプロビジョニングや、3年ほど前に公開したAzure AD ConnectからOpenAMのレポジトリとして構成したOpenDJへのプロビジョニングの記事では、Azure AD ConnectのMicrosoft Identity ManagerのSynchronization Serviceとしての機能を使ってカスタムのコネクタ(ECMA2エージェント)や組み込みのGeneric LDAP Connectorを使って「無理やり」、ADやAzure AD以外のシステムとの同期を実現していました。
※Azure AD ConnectにGeneric LDAP Connectorなどが同梱され始めたのは1年くらい前ですね。

実はこの構成、オフィシャルに公開されていなかっただけで、Premierサポートとの契約があれば使うことは出来たんですが、なかなかハードルが高いので、これまであまり言及してきませんでした。

しかし、Azure Active Directory PoCプレイブックの中に、しれっとGeneric LDAP Connectorを使ったオンプレミスLDAPとAzure ADの同期のシナリオが記載されていることに気が付いてしまいました(笑)

Generic LDAPコネクタ構成
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-playbook-building-blocks#generic-ldap-connector-configuration

流石に、こんな注意書きが添えられていてハードルを上げまくっています。まぁ、やってみるとそれほど難しくはありませんが。
これは高度な構成で、FIM/MIM に関する知識を必要とします。 運用環境で使用されている場合、この構成に関するご質問については、Premier サポートを使ってお問い合わせください。

Azure AD ConnectがGAしたタイミングで公開されたドキュメントに書いてある構成が徐々に実現してきている、ということですね。




ちなみに以下のドキュメントを見ると、オンプレミスのLDAPなどへAzure AD Connectを使って接続する構成はFR(今後サポート)となっており、正式にサポートされたわけではないので、実際に利用する場合はPremierサポートと十分に協議をすることをお勧めします。

ハイブリッド ID ディレクトリ統合ツールの比較
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-hybrid-identity-design-considerations-tools-comparison



2017年8月15日火曜日

JICS 2017開催!コンシューマから学術、エンタープライズまでIDに関与している人は参加必須です

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

お馴染みのVittorio Bertocci氏を招聘したJapan Identity & Cloud Summit(JICS)2014から3年、久しぶりにJICSが復活します。



今年は、ゲストが豪華です。

  • オープニング・キーノートはプレゼンのわかりやすさでは定評のあるSalesforce.comのChuck Mortimore氏
  • 続くキーノートはMicrosoft CorporationのAlex Weinert氏よりCloud Identity元年的な話でIdentityの将来を見据えた時にオープン・スタンダードの重要性について
  • そこからはブレークアウトセッションに分かれて金融、学術、ソーシャル、IoT、トラストフレームワークなど見所がたくさん
  • セキュリティネタではOWASP Japanのリーダー岡田氏
  • お馴染みOpenIDファウンデーション・ジャパンのエヴァンジェリスト達による標準技術(OAuth、OpenID Connect)の解説
  • クロージング・キーノートはこれまたIdentity界隈では知らぬ人はいない、Nishant Kaushik氏からNRI/OpenID Foundationの崎村さん、というこれまた必聴のセッションで畳みかけ。

見所満載です。

私もモバイル・ソーシャルのトラックとトラスト・フレームワークのトラックの2つを見ており、2コマ+VTR再放送で都合3コマも登壇するのですが、自分が出ている時間帯のセッションが聞けないのが非常に残念です。



定員は1000名くらいだったと思いますが、希望のセッションを登録時に選択する方式なので、早めに登録しないと聞けないセッションもあると思うので、ぜひ早めに登録を!

登録はこちらから。
https://nosurrender.jp/jics2017/

2017年8月14日月曜日

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

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

前回に引き続き、CDATA API ServerとID管理システムを使ってSaaS(今回はSalesforce.com)へのプロビジョニングを簡単に行う、という仕組みを作っていきます。

前回は、API ServerをSalesforce.comのUserテーブルへ接続し、ユーザの取得をしましたが、今回はいよいよID管理システム(今回はAzure AD Connect)を使ってユーザを作成します。

やることは非常に単純で、API Serverで定義されたリソース(実際はSalesforce.comのUserテーブル)に対してJSON形式で作成したいユーザの情報をPOSTするだけです。

◆投げ込むJSONを確認する

Salesforce.comの開発者ドキュメントを見ると、Userテーブルに新規レコード(つまり新規ユーザ)を作成する際に必須となる属性を確認します。

 SOAP API開発者ガイド)User
 https://developer.salesforce.com/docs/atlas.ja-jp.api.meta/api/sforce_api_objects_user.htm

これを見ると、以下の属性が必須との事です。
  • Username :ユーザ識別子。メールアドレス形式
  • Alias :ユーザの別名
  • Email :ユーザのメールアドレス
  • LastName :ユーザの姓
  • EmailEncodingKey :メールの文字コード
  • LanguageLocaleKey :ユーザの言語
  • LocaleSidKey :ユーザのロケール
  • ProfileId :ユーザのプロファイルのID
  • TimeZoneSidKey :ユーザのタイムゾーン
  • UserPermissionsOfflineUser :オフラインエディションの使用可否
  • UserPermissionsMarketingUser :キャンペーン管理の可否

ユーザを作成するには、最低限これらの値をJSON形式でAPI ServerのリソースへPOSTすればよい、ということなので、まずは直接POSTしてみます。

ただ、EmailEncodingKeyやProfileIdなど、何を値として設定すれば良いのかよくわからない属性もあるので、まずはSalesforce.com上に手動で作成したユーザをGETし、各属性にどのような値が入っているのかを確認すると以下のような値が入っていることがわかるので、この例をテンプレートにPOSTするデータを作成します。

属性
Usernamexxxxx@example.com
AliasFujie
Emailxxxxx@example.com
LastNameFujie
EmailEncodingKeyISO-2022-JP
LanguageLocaleKeyja
LocaleSidKeyja_JP
ProfileId(Chatter Free Userの場合)00e7F000001LotXQAS
TimeZoneSidKeyAsia/Tokyo
UserPermissionsOfflineUserfalse
UserPermissionsMarketingUserfalse


以下のようなJSONを作成し、Chrome ExtensionのAdvanced REST Clientを使ってAPI Serverに定義したリソースエンドポイントへPOSTをします。
{
  "Username": "test999@eidentity.jp",
  "Alias": "test999",
  "Email": "test999@eidentity.jp",
  "LastName": "Test",
  "EmailEncodingKey": "ISO-2022-JP",
  "LanguageLocaleKey": "ja",
  "LocaleSidKey": "ja_JP",
  "ProfileId": "00e7F000001LotXQAS",
  "TimeZoneSidKey": "Asia/Tokyo",
  "UserPermissionsOfflineUser": "false",
  "UserPermissionsMarketingUser": "false"
}


上手くいくと、HTTP 201 Createdが返ってきて実際にユーザが作成されます。


Salesforce.comの管理画面からユーザを確認すると実際に作成されていることがわかります。


◆管理エージェントの作成

投げ込むJSONがわかったところで、あとはID管理システムでJSONの生成からPOSTを自動化するだけです。

やることはFIM/MIM向けのECMA2エージェントとして以前公開したGeneric REST API Management Agentとよく似たようなことなので、このコードをカスタマイズしてみます。

細かいECMA2エージェントの開発方法は別エントリでそのうち解説しますが、以下の手順でGeneric REST API Management Agentを改造します。

1.スキーマ定義(GetSchemaメソッド)
 先にリストアップした必須属性を定義します。Username属性をAnchor属性として設定をしています。こんなコードになります。
                SchemaType personType = SchemaType.Create("Person", false);
                personType.Attributes.Add(SchemaAttribute.CreateAnchorAttribute("Username", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("Alias", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("Email", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("LastName", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("EmailEncodingKey", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("LanguageLocaleKey", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("LocaleSidKey", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("ProfileId", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("TimeZoneSidKey", AttributeType.String));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("UserPermissionsOfflineUser", AttributeType.Boolean));
                personType.Attributes.Add(SchemaAttribute.CreateSingleValuedAttribute("UserPermissionsMarketingUser", AttributeType.Boolean));
                Schema schema = Schema.Create();
                schema.Types.Add(personType);
                return schema;

 こうすることで管理エージェントで管理対象属性を選択できるようになります。


2.パラメータ定義(GetConfigParametersメソッド)
 API Server上のリソースURIや接続に使うAPI ServerユーザのAuthTokenを指定できるようにします。こんなコードになります。接続パラメータの部分だけで良いのでConnectivityの部分にパラメータを追加しています。
                switch (_page)
                {
                    case ConfigParameterPage.Capabilities:
                        break;
                    case ConfigParameterPage.Connectivity:
                        _configParametersDefinitions.Add(ConfigParameterDefinition.CreateLabelParameter("Connection parameters"));
                        _configParametersDefinitions.Add(ConfigParameterDefinition.CreateStringParameter(ConstDefinition.CFG_RESOURCE_URI, ""));
                        _configParametersDefinitions.Add(ConfigParameterDefinition.CreateStringParameter(ConstDefinition.CFG_AUTH_TOKEN, ""));
                        break;
                    case ConfigParameterPage.Global:
                        break;
                    case ConfigParameterPage.Partition:
                        break;
                    case ConfigParameterPage.RunStep:
                        break;
                    case ConfigParameterPage.Schema:
                        break;
                }

尚、テストなので、ValidateConfigParametersについては処理を入れておらず、指定されたパラメータの値の確認などは行っていません。

これで、管理エージェント設定画面で接続関連のパラメータを指定することが出来るようになります。ここにAPI ServerのリソースURIとAuthTokenを指定します。

3.インポート処理関連(OpenImportConnection/GetImportEntriesメソッド)
 まずはOpenImportConnectionで、設定パラメータからリソースURIとAuthTokenの値を取り出し、後続のGetImportEntriesで使えるようにグローバル変数にセットしておきます。
                resource_uri = _configParameters[ConstDefinition.CFG_RESOURCE_URI].Value.ToString();
                auth_token = _configParameters[ConstDefinition.CFG_AUTH_TOKEN].Value.ToString();

 次に、API Server(を経由してSalesforce.com)からユーザ情報を取得するGetImportEntriesです。やることはシンプルで、API ServerのリソースURIへAuthToken付きのGETリクエストを投げ、取得したJSONをパースしてConnector Space上のエントリに追加していくだけです。尚、本来はページング処理などをする必要があるのですが、今回はテストなので省略しています。
                var _csentries = new List<CSEntryChange>();
                string _importEntriesJSON = utils.GetContentsWithAccessToken(resource_uri, auth_token, null);
                var _getImportEntriesByObjectTypeResult = JObject.Parse(_importEntriesJSON).SelectToken("value").ToString();
                var _importObjectJSONArray = JArray.Parse(_getImportEntriesByObjectTypeResult);
                foreach (var _importObjectJSON in _importObjectJSONArray)
                {
                    var _csentryChange = CSEntryChange.Create();
                    _csentryChange.ObjectModificationType = ObjectModificationType.Add;
                    _csentryChange.ObjectType = "Person";
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("Alias", _importObjectJSON["Alias"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("Email", _importObjectJSON["Email"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("Username", _importObjectJSON["Username"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("LastName", _importObjectJSON["LastName"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("EmailEncodingKey", _importObjectJSON["EmailEncodingKey"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("LanguageLocaleKey", _importObjectJSON["LanguageLocaleKey"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("LocaleSidKey", _importObjectJSON["LocaleSidKey"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("ProfileId", _importObjectJSON["ProfileId"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("TimeZoneSidKey", _importObjectJSON["TimeZoneSidKey"].ToString()));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("UserPermissionsOfflineUser", false));
                    _csentryChange.AttributeChanges.Add(AttributeChange.CreateAttributeAdd("UserPermissionsMarketingUser", false));
                    _csentries.Add(_csentryChange);
                }
                var _importReturnInfo = new GetImportEntriesResults();
                _importReturnInfo.MoreToImport = false;
                _importReturnInfo.CSEntries = _csentries;
                return _importReturnInfo;

utils.GetContentsWithAccessTokenの中ではx-cdata-authtokenヘッダにAuthTokenをセットし、リソースURIにGETリクエストを投げているだけです。
                _httpClient.DefaultRequestHeaders.Add("x-cdata-authtoken", _accessToken);
                return await _httpClient.GetStringAsync(_url);


4.エクスポート処理関連(OpenExportConnection/PutExportEntriesメソッド)
 こちらは先のインポートとは逆で、実際にAPI Serverへユーザを出力(プロビジョニング)する処理です。
 OpenExportConnectionではインポート時と同じくリソースURIとAuthTokenを設定から取得し、PutExportEntriesでConnector Space内のプロビジョニング対象ユーザを取得してJSON形式に整形してリソースURIへPOSTを行います。
                foreach (CSEntryChange _csentryChange in _csentries)
                {
                    // build json to POST
                    var _attr = new Dictionary<string, string>();
                    // anchor attribute
                    _attr.Add("Username", _csentryChange.DN.ToString());
                    switch (_csentryChange.ObjectModificationType)
                    {
                        case ObjectModificationType.Add:
                        case ObjectModificationType.Update:
                        foreach (string _attribName in _csentryChange.ChangedAttributeNames)
                        {
                            var _attributeChange = _csentryChange.AttributeChanges[_attribName];
                            var _valueChanges = _attributeChange.ValueChanges;
                            if (_valueChanges != null)
                            {
                                foreach (var _valueChange in _valueChanges)
                                {
 if (_valueChange.ModificationType == ValueModificationType.Add)
 {
// new value
_attr.Add(_attribName, _valueChange.Value.ToString());
break;
}
 }
                                }
                            }
                            // build json
                            string _exportDataJSON = JsonConvert.SerializeObject(_attr);
                            string _exportResult = utils.PostContentsWithAccessToken(resource_uri, auth_token, _exportDataJSON, null);

                            _exportEntriesResults.CSEntryChangeResults.Add(
                                CSEntryChangeResult.Create(_csentryChange.Identifier,
_csentryChange.AttributeChanges,
MAExportError.Success));
                                break;
                            case ObjectModificationType.Delete:
                                // NOT Implemented
                                break;

先ほどと同じく、utils.PostContentsWithAccessTokenではAuthTokenをヘッダにつけてJSONをリソースURIへPOSTしています。

大きくはこれで終わりです。
後はビルドしてAzure AD Connectが読み込めるようにExtensionsフォルダ(初期値はC:\Program Files\Microsoft Azure AD Sync\Extensions)へDLLファイルをコピーしておきます。

参考までにソースは以下のレポジトリにあげておきます。
https://github.com/fujie/apiserver

◆管理エージェントの設定

*繰り返しになりますが、Azure AD ConnectへカスタムManagement Agentを組み込む場合、所定の手続きを踏まないとサポート対象外となります。今回は手元にちょうどあった環境を使ったのでAzure AD Connectを使いましたが、本番環境ではMIM(Microsoft Identity Manager)やExgen LDAP Managerなど汎用的なID管理ツールを使ってください。
次は、Azure AD ConnectのSynchronization Serviceに開発したECMA2エージェントを設定します。
コネクタの種類にExtensible Connectivity 2.0を選択し、DLLをロードします。



後は、先に示した画面の様に接続設定でリソースURI、AuthTokenを設定し、管理対象の属性を選択すれば管理エージェント自体の構成は終了です。

次は、Run Profileの設定です。これを設定しないとAzure AD Connectはインポート、同期、エクスポートの各処理を実行してくれません。また、プロファイルの名前をFull Import、Full Synchronization、Export、など決められた名称にしておかないと30分に一回の自動処理の流れに乗せてくれず処理がスタックするので命名は大事です。
尚、今回作った管理エージェントにはDelta Importの処理を実装していないので、プロファイルの定義は行えません。イベントログにDelta Importの定義が無いのでスキップしますよ~という警告が出ますが特に影響はないので無視します。


これでSynchronization Service側の設定は完了です。

◆同期ルールを定義する

後は実際のMetaverse上のデータと先ほど作成した管理エージェントのConnector Space上のエントリの属性のマッピング(同期ルール)の設定を行います。FIMやMIMではポータルでISR/OSRを定義してルールを設定するのですが、今回はAzure AD ConnectなのでSynchronization Rules Editorを使います。個人的にはFIM/MIMの設定画面よりもこのルールエディタの方が使いやすいので好きだったりします。

今回はプロビジョニングだけでいいので、アウトバウンド同期ルールを定義します。
DirectionはOutbound、Connectorは先ほど作成したAPI Serverを選択してAdd new ruleをクリックしてルールを作成します。(以下は作成後の画面)

LinkTypeにprovisionを選択することで新規にユーザを作成するためのルールとして扱われます。

MetaverseとConnector SpaceのユーザのマッチングはUserprincipalNameおよびUsernameを使うので、Join rulesは以下のように設定しています。

後は、本命の属性のマッピングです。
エンコードやロケール、プロファイルIDなどは面倒なので固定値を入れて、ユーザ固有の値だけMetaverseの情報をマッピングします。

これでSaveをするとすべての設定が完了です。

◆テスト

後は、ローカルのAD上にユーザを作成、Azure AD Connectの同期ジョブが動くと、Azure ADへのユーザ作成に加えて、API Serverを経由してSalesforce.comへもユーザが作成されます。

この辺りは前回も紹介したデモの動画を見てもらった方が早いと思います。



Azure AD Connectを使った関係で色々とトリッキーなこともしていますが、少なくともID管理システム側でSalesforce.com自体の存在を殆ど意識せずに構成をすることが出来ていることはご理解いただけるのではないでしょうか?
スキーマの設定についても動的に取得する様に管理エージェントを構成すれば、API Serverの先にあるのがSalesforce.comだろうがDynamics365だろうが基本設定を変える必要は全くなく、API Serverが上手くハンドリングをしてくれますので、従来の個別開発に比べて相当簡単に各種SaaSなどへのプロビジョニングを構成することが可能になります。

今後、クラウド・サービスの活用がますます増えてくると思われますので、既存のID管理システムを効率よく対応させていくための一つの選択肢として、API Serverのようなデータ統合プラットフォームを活用するのはアリかも知れませんね。

2017年7月29日土曜日

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

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

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



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

当日の資料はこちら。




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


使っている道具は、
・オンプレミスの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が接続用のドライバを持っているサービスであれば何でも構いません。


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

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

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

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


2.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の設定ページに手順を含め記載されています。

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


3.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を叩くだけです。
この部分は若干コードを書くので、次回詳細は解説したいと思います。

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