先日公開した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年くらい前ですね。
２．パラメータ定義（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;
}
使っている道具は、
・オンプレミスの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を構成します。
先日、Azure AD Connectに関するセキュリティ・アドバイザリが発表され、脆弱性対応版として最新版がリリースされました。 脆弱性対応のためとはいえ、一部ヘルプデスク運用が変わってくるので、Office365やAzure ADの管理者の方は十分に注意して運用マニュアルの修正などを行う必要があります。
日本語「要求したユーザーが対象のオンプレミス AD アカウントのオーナーであるかどうかを検証します。それは、対象のオンプレミス AD アカウントと、要求したユーザーの Azure AD アカウントの関係をメタバースで確認します。要求したユーザーがオーナーの場合、Azure AD Connect はパスワード ライトバック要求を許可します。そうではない場合、要求は拒否されます」
原文「it then validates whether the requesting user is the owner of the target on-premises AD account. It does so by checking the relationship between the target on-premises AD account and the Azure AD account of the requesting user in its Metaverse. If the requesting user is indeed the owner, Azure AD Connect permits the Password writeback request. Otherwise, the request is rejected」
このオーナー（is the owner）というのが何を指すのか、が全く分からず、ローカルAD上のOUや対象ユーザのセキュリティ構成でオブジェクトのオーナーにしてみたり、と色々とやったのですが、結局オーナー＝自身のアカウント、というオチだと思います。＃違ったらご指摘ください。
今回「脆弱性」として取り上げられた仕組みは基本的にFIM/MIMにおいても同じですので、管理者権限を持つアカウントのパスワードを、悪意のある別の管理者がリセットすることが出来ます。これを製品の脆弱性や不具合と呼ぶのは微妙ですが、FIM/MIMにおいては今回Azure AD Connectが行った対応は入っていませんので、管理者権限を持つユーザについては自分自身でしかパスワードを更新できない様にMPRを工夫する、などの対応が必要となります。
２．Enterprise IT seminar by professionals from global IT companies
日時 ：7月21日（金）14:30～17:00
申し込み：https://www.xlsoft.com/jp/products/cdata/seminar.html
タイトル：Designing cloud-based Identity and Access Management system for global enterprises
場所 ：エクセルソフト株式会社 セミナルーム
それぞれ簡単に内容を紹介します。
まずはCDATA Day 2017からですが、こちらはCDATA社のAPI Serverのローンチイベントということもあり、API Serverを使ってSCIMなどアイデンティティAPIを実装する話をします。（完全SCIM互換にするにはまだ若干機能不足はあるのですが、その部分は今後の期待ということで）
また、元々のCDATAの強みであるデータ統合基盤としてのアダプタの豊富さを利用してプロビジョニングを手軽に実装する方法なども考えられるので、その方面への活用についてもお話しできればと思っています。
先日ドイツで開催されたEuropean Identity & Cloud Conference 2017のKeynoteでOne IdentityのVPであるJackson Shawも話していましたが、現状各種アプリケーションのSCIMへの対応が中々進んでいない中で、ID管理製品側で専用のアダプタを開発するのではなく、データ統合プラットフォーム（クラウドベースのiPaaS/Integration Platform as a Serviceを含む）をID管理システムとターゲットシステムの間に挟む、という構成もあり得ると考えています。
こんな感じです。（出典：European Identity & Cloud Conference
2017 Keynote : When will Identity and Access Management be Digital Transformed
– Jackson Shaw / VP One Identity）
この辺りを（できれば）デモを交えながら話せれば、と思います。
次に、翌21日（金）に行われるEnterprise IT Seminarです。
こちらは外資系企業のIT部門や日系企業で現地法人とやり取りをするIT部門の方々を対象として、セキュリティ、ERP/CRM、アプリケーション開発、データ統合の4つのテーマでグローバル・プロジェクトをどのように進めるか、という話があり、私はその中のセキュリティ、アイデンティティ管理のコマを受け持ちます。（全編英語です）
投稿
