Quantcast
Channel: IdM実験室
Viewing all 771 articles
Browse latest View live
↧

[WAAD]Windows 8 の PowerShell で ServicePrincipal 関連の操作を行う

November 22, 2012, 9:31 am
$
0
0

既出情報ですが、意外と引っかかるのでメモとして書いておきます。

Windows 8 / Windows Server 2012 では Microsoft Online Services Module for PowerShell をインストールして ServicePrincipal 関連のコマンドレット（例えば Get-MsolServicePrincipal）を実行しても ObjectNotFound と言われてしまいます。



これは ServicePrincipal 関連のコマンドレッドが含まれるモジュール（MSOnlineExtended）を実行するのに PowerShell 2.0 のエンジンが必要なためです。※コントロールパネルの Windows の機能から見ると PowerShell 2.0 とありますが実際は Version 3.0 が実行されているからです。（プロンプトから $PSVersionTable を実行すると PSVersion の値が 3.0 となっているが確認できます）


この状態を解消するには、 powershell.exe の引数に -version 2.0 をつけて明示的に Version 2.0 で PowerShell を起動し、MSOnline モジュールおよび MSOnline Extended モジュールをインポートする必要があります。

コマンドプロンプトから以下を実行します。
> C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2.0

PowerShell が起動したら以下を実行します。

PS > Import-Module MSOnline
PS > Import-Module MSOnlineExtended


ただ、副作用があり Windows 8 用の Version 2.0 の PowerShell ISE が用意されていないので、Out-GridView などの機能が使えなくなります。。。
早く PowerShell 3.0 用の MSOnlineExtended モジュールがリリースされないかな。。。
↧
Search

[FIM2010]製品ロードマップ？

November 23, 2012, 5:00 pm
$
0
0

ソースが Directions on Microsoftで、こんなネタが。。（といっても 2011年4月なので古い情報でしょうけど）


既に CY2012 も終わろうとしていますが、Forefront Identity Manager 2012 なんていう話は出てきていないので、R2 のことかも知しれませんね。

誰か Directions on Microsoftのアカウント買ってる人がいらっしゃれば最新情報を！


元スライドはこちら。


↧
↧

[WAAD] ACS および コア機能が無償で提供

December 1, 2012, 3:35 pm
$
0
0
これは結構大きなニュースです。

これまで本当はいつから課金されるのかよくわからなかった 旧 AppFabric Access Control / Windows Azure Active Directory ですが、ようやく明確なアナウンスがありました。

- Windows Azure Team の blog
　Windows Azure Active Directory: Making it easier to establish Identity Management in the cloud
- Vittorio の blog
　Access Control & Core Directory Available at No Charge

以下の 2 つのコア機能については無償！ということです。素晴らしい。

  • アクセス制御（旧 Access Control Service）
    • Facebook 連携やオンプレミスの Active Directory などとの連携機能
  • コア・ディレクトリおよび認証
    • シングルサインオン、ユーザ・グループ管理、ディレクトリ同期、フェデレーション機能


we are announcing today that two key features of Windows Azure Active Directory are available at no charge.
  • Access control provides centralized authentication and authorization by integrating with consumer identity providers, such as Facebook, or using on-premises Windows Server Active Directory.  By having Access Control available you can create a single application that can allow users to login with both their Organizational Credentials stored in Windows Azure AD or Windows Server AD, or to login in using popular consumer service identity services like Microsoft Account, Facebook, Google, or Twitter.  Historically, Access Control has been priced based on the number of transactions. We are now making it free.
  • Core Directory & Authentication enables capabilities such as single sign-on, user and group management, directory synchronization and directory federation. These features are currently free in the Windows Azure AD Developer Preview and will remain free after it reaches general availability.

前者（ACS）についてはこれまでトランザクション課金でしたが無償化、後者（WAAD）については現在プレビュー提供ですが、GA後も無償のまま、ということです。

ちなみにこれまでの課金に関する表記。若干混乱気味でした。

↧

IdM プロジェクトの進め方

December 1, 2012, 3:45 pm
$
0
0
先日のオラクルセキュリティセミナでお話した事例紹介のプレゼンの中から IdM プロジェクトの進め方の部分だけ抜粋して公開しました。

今後 IdM プロジェクト管理をする方に少しはお役に立てれば、と。（＆ JNSA の宣伝込みｗ）

まぁ、言いたいことはゼロから手探りでプロジェクトを進めるんじゃなくて、先人の知恵を利用しましょう、ということと、段階導入をする上で合理的な効果測定をしていったほうが良いですよ、という話です。



↧

[Office 365 & WAAD] Graph API を利用したアイデンティティ管理

December 3, 2012, 2:30 pm
$
0
0

Office 365 Advent Calendarおよび Windows Azure Advent Calendar用のポストです。

まず、最初に何故 2 つの Advent Calendar へのクロスポストなのか？というあたりを解説するために、Office 365 と Windows Azure Active Directory の関係を解説して置くと、単純に Office 365 の アイデンティティ基盤が Windows Azure Active Directory だからです。

[図：Office 365 と Windows Azure Active Directory の関係]


Office 365 のユーザやグループの管理を行ったり、シングルサインオンを行う際は実際は Office 365 そのものではなく、Windows Azure Active Directory に対して操作をしている、ということです。

[表：Office 365 から見た Windows Azure Active Directory]

機能Office 365 から見た WAAD
シングルサインオン信頼するアイデンティティ・プロバイダ
⇒ここで認証されたユーザは信頼できる
ユーザ/グループ管理アイデンティティ・ストア
⇒このデータベースに保持されるユーザ情報（属性など）を利用する

さて、本日のお題です。

■Office 365 のユーザ管理の限界

これまで、Windows Azure Active Directory 上のアカウントを管理（追加・変更・削除・ライセンス割り当て等）を行おうと思うと、マイクロソフト公式のディレクトリ同期モジュールを使うか、個別に PowerShell で管理を行うしか方法はありませんでした。

参考：@IT / Office 365 とのアイデンティティ連携を実現する
　　　http://www.atmarkit.co.jp/ait/articles/1211/14/news069.html

　　　ディレクトリ同期ツールを使って Office 365 へのユーザ同期を行う
　　　http://idmlab.eidentity.jp/2011/04/office365.html


しかし、このディレクトリ同期ツール、現状ではそれなりに制限事項があります。
例を挙げると、以下のような事項が挙げられます。

・社内の Active Directory がマルチフォレスト構成だった場合、同期用のドメインを別途構築し、必要なアカウント情報を同期用ドメインに集める必要がある
・不要な（Office 365 を利用しない）ユーザでも同期してしまう（除外ルールの融通が利かない）
・ライセンス割り当ては個別に実施する必要がある
・50,000 オブジェクトまでの同期しかサポートされない
・メンバ数が 15,000 を超えるグループは同期出来ない
・認証プロキシサーバ以下の環境では使えない
　※認証不要な Proxy 環境化では netsh コマンドで https プロキシ設定をすれば OK
・（当然ですが）Windows Server でしか動かない

結果として、ディレクトリ同期を行った後、Office 365 の管理コンソールで不要なユーザを消したり、PowerShell でライセンス割り当てをしたり、、、とそれなりに管理者には負荷がかかるのが現実だと思います。


そこで登場したのが Windows Azure Active Directory Graph API です。
現在はまだプレビューですが、Graph API は RESTful な API なのでプラットフォームに依存せずに利用することができますし、各アイデンティティ管理製品のカスタムアダプタとして容易に実装することが可能となります。

先日、本 blog でもこの API を利用して Windows Azure Active Directory 上のユーザ情報を取得する方法を紹介しましたが、今回は
・ユーザの作成
・ユーザの更新
・ライセンスの割り当て
・ユーザの削除
を紹介したいと思います。

参考：[WAAD] REST Client で Graph API を直接実行する
　　　http://idmlab.eidentity.jp/2012/09/waad-rest-client-graph-api.html


■Graph API を利用するための準備

Graph API を利用して Windows Azure Active Directory 上のアカウントを管理するためには、
・サービスプリンシパルの作成
・テナント ID の取得
・作成したサービスプリンシパルへ適切な権限の付与
という 2 つの作業が必要です。

まず、サービスプリンシパルを作成します。
MSOnline / MSOnlineExtended の 2 つのモジュールを読み込んだ状態の PowerShell （Microsoft Online Services Module for Windows PowerShell）から
＞ Connect-MsolService
で MSOnline へ接続します。
その状態で、
＞ New-MsolServicePrincipal -DisplayName "<任意の名前>" -ServicePrincipalNames @("<任意の名前>") -Type Symmetric -Usage Verify - StartDate -EndDate
と実行します。

すると、以下のような結果が取得できます。

The following symmetric key was created as one was not supplied 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

DisplayName           : <指定した名前>
ServicePrincipalNames : {<指定した名前>, }
ObjectId              : BBBBBBBBBBBBBBBBBBBBBBBB
AppPrincipalId        : CCCCCCCCCCCCCCCCCCCCCCCCC
TrustedForDelegation  : False
AccountEnabled        : True
Addresses             : {}
KeyType               : Symmetric
KeyId                 : DDDDDDDDDDDDDDDDDDDDDDDD
StartDate             : 2012/12/03 8:00:00
EndDate               : 2015/12/03 8:00:00
Usage                 : Verify



この中で必要なのが、実行結果内の
・AppPrincipalId
・SymmetricKey
・ObjectId
の 3 つです。

次に、作成した Office 365 テナントの ID を取得します。
これも同じく PowerShell で
＞ (Get-MsolCompanyInformation).objectId
を実行して Guid を取得します。


さらに作成したサービスプリンシパルへの適切な権限を付与します。
Windows Azure Active Directory を操作するための権限は複数存在しますが、ユーザを管理するために必要な権限は User Account Administrator というロールが持っていますので、作成したサービスプリンシパルをこのロールメンバに追加します。
同じく PowerShell で
＞ Add-MsolRoleMember -RoleMemberType ServicePrincipal -RoleName "User Account Administrator" -RoleMemberObjectId <サービスプリンシパルの ObjectID>
と実行します。



ここまでそろえばあとは Graph API を実行するだけなのですが、実行するために必要なアクセストークンを取得する必要があります。
ここも RESTful API を使って取得することも可能ですが、今回は面倒なので Windows Azure Authentication Library　(AAL) を使ってアクセストークンを取得するプログラムを書いてみます。

参考：Windows Azure Authentication Library
　　　http://msdn.microsoft.com/en-us/library/windowsazure/jj573266.aspx

　　　※ちなみに AAL を使わずにアクセストークンを取得する方法は先に挙げたポストを参照してください。
　　　[WAAD] REST Client で Graph API を直接実行する
　　　http://idmlab.eidentity.jp/2012/09/waad-rest-client-graph-api.html


今回は簡単なプログラムを書きました。
using System;
using Microsoft.WindowsAzure.ActiveDirectory.Authentication;

namespace GetAccessToken
{
    class Program
    {
        static void Main(string[] args)
        {
            string TenantDomainName = "＜取得したテナントドメイン名＞.onmicrosoft.com";
            string TenantId = "＜取得したテナントID＞";
            string AppPrincipalId = "＜取得した AppPrincipalId";
            string SymmetricKey = "＜取得した SymmetricKey＞";

            AuthenticationContext context = new AuthenticationContext(
                "https://accounts.accesscontrol.windows.net/" + TenantDomainName);
            SymmetricKeyCredential credential = new SymmetricKeyCredential(
                AppPrincipalId + "@" + TenantId,
                Convert.FromBase64String(SymmetricKey));
            AssertionCredential assertion = context.AcquireToken(
                "00000002-0000-0000-c000-000000000000/directory.windows.net@" + TenantId, credential);
            System.Console.WriteLine("auth:" + assertion.CreateAuthorizationHeader());

        }
    }
}



このプログラムをコンパイルして実行すると Windows Azure Active Directory から Graph API 実行に必要なアクセストークンを取得し、コンソールに表示してくれますので、メモしておきます。

いよいよ Graph API の実行です。今回も先のポストと同様に Chrome Extension の Advanced Rest Client を使いました。


■Graph API でユーザを作成する
まずはユーザの作成です。
実行するクエリをまとめると以下の表になります。

設定値
エンドポイントhttps://graph.windows.net/advent2012.onmicrosoft.com/Users
メソッドPOST
ヘッダAuthorization取得したアクセストークン
x-ms-dirapi-data-contract-version0.8
Content-Typeapplication/atom+xml
ボディ<entry xmlns="http://www.w3.org/2005/Atom" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
<content type="application/xml">
<m:properties>
<d:ObjectType>User</d:ObjectType>
<d:AccountEnabled m:type="Edm.Boolean">true</d:AccountEnabled>
<d:DisplayName>織田信長</d:DisplayName>
<d:GivenName>信長</d:GivenName>
<d:Surname>織田</d:Surname>
<d:UserPrincipalName>nobunagao@＜テナントドメイン名＞.onmicrosoft.com</d:UserPrincipalName>
<d:MailNickname>nobunagao</d:MailNickname>
<d:Password>P@ssw0rd</d:Password>
</m:properties>
</content>
</entry>


うまくいくと HTTP 201 created が返され、作成されたユーザエントリの情報が XML （Accept ヘッダを application/json にしておけば JSON ）で返ってきます。


■Graph API でユーザを更新する
次に作成したユーザの属性を更新してみます。
作成時に UsageLocale を指定しなかったので、次のライセンス割り当てで問題が起きるため、UsageLocale 属性を更新してみます。（ライセンス割り当てにはユーザの所在地の指定が必要）

今回は PATCH メソッドを利用します。

設定値
エンドポイントhttps://graph.windows.net/advent2012.onmicrosoft.com/Users(‘＜対象ユーザ名＞@＜テナントドメイン＞.onmicrosoft.com’)
メソッドPATCH
ヘッダAuthorization取得したアクセストークン
x-ms-dirapi-data-contract-version0.8
Content-Typeapplication/atom+xml
ボディ<entry xmlns="http://www.w3.org/2005/Atom" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
<content type="application/xml">
<m:properties>
<d:UsageLocation>JP </d:UsageLocation>
</m:properties>
</content>
</entry>



うまくいくと HTTP 204 no-content が返されます。


■Graph API でライセンスを割り当てる
作成したユーザにはまだライセンスを割り当てていないので、ライセンスの割り当てを行います。
今回は Office 365 のプラン E3 を使ったので、該当する SkuId である「6fd2c87f-b296-42f0-b197-1e91e994b900」を割り当てます。

設定値
エンドポイントhttps://directory.windows.net/＜取得したテナントドメイン＞.onmicrosoft.com/Users('＜割り当てるユーザID＞@＜取得したテナントドメイン＞.onmicrosoft.com')/AssignLicense
メソッドPOST
ヘッダAuthorization取得したアクセストークン
x-ms-dirapi-data-contract-version0.8
Content-Typeapplication/json;odata=verbose;charset=utf-8
ボディ{"AddLicenses":
[
{
"__metadata":
{"type":"Microsoft.WindowsAzure.ActiveDirectory.AssignedLicense"},
"DisabledPlans":
{"__metadata":
{"type":"Collection(Edm.Guid)"},
"results":[]},
"SkuId":"6fd2c87f-b296-42f0-b197-1e91e994b900"
}
],
"RemoveLicenses":null
}


うまくいくと HTTP 200 ok が返され、アサインされたライセンスを含むユーザエントリ情報が XML もしくは JSON で返ってきます。
よく見ると RMSOnline なんていう文字列も見えるので、Office 365 の管理ポータルから見える以外のライセンスの準備も進んでいることがよくわかります。


■Graph API でユーザを削除する
最後に作成したユーザを削除してみます。
以下のクエリを実行します。

設定値
エンドポイントhttps://graph.windows.net/advent2012.onmicrosoft.com/Users(‘＜作成したユーザID＞@＜テナントドメイン＞.onmicrosoft.com’)
メソッドDELETE
ヘッダAuthorization取得したアクセストークン
x-ms-dirapi-data-contract-version0.8
Content-Typeapplication/x-www-form-urlencoded?


こちらもうまくいくと HTTP 204 no-content が返ってきます。





いかがでしたでしょうか？
まだまだプレビューですので、色々と検証してみる必要はありそうですが、上記のように公式のディレクトリ同期ツールを使わなくても Graph API を実行することによりアイデンティティ管理を柔軟に行うことが可能になることがわかりました。
私も Forefront Identity Manager 2010 用の Windows Azure Active Directory 用のカスタム管理エージェントを作ってみようとしているところなので、また完成したら公開したいと思います。


以上で私のポストはおしまいですが、明日は各 Advent Calendar は以下の予定になっているそうなので、引き続き参考にしてみてください。
・Office 365 ： Office 365 MVP 中村 和彦さん / http://simplesso.jp/
・Windows Azure ： Kentaro AOKIさん / http://kentablog.cluscore.com/

↧
↧

[Azure]新ポータルから Access Control 名前空間を作成可能に

December 22, 2012, 1:12 pm
$
0
0

Windows Azure のポータルが2012年5月にリニューアルされてからも Access Control（ACS）だけは旧ポータルからしか管理できませんでしたが、ようやく新ポータルからも管理できるようになりました。


新しい名前空間を作成することも可能になっています。


作成後、アクティブ化が完了するのを待ちます。


管理画面に遷移した後は以前と変わりません。



あとは、実現しなさそうですが、このプラットフォームの管理ポータルと、ディレクトリサービスの管理ポータル、オンラインサービスの管理ポータルの統合ですかねぇ。。
少なくとも同じサービス名がついてしまっている Windows Azure Active Directory（WAAD）の管理が複数のサブスクリプション、管理インターフェイスに分かれているので、もう少しシンプルになれば、と思います。
↧

4th MVP Renewal !!

January 1, 2013, 7:09 am
$
0
0

皆様あけましておめでとうございます。
無事に今年も更新させていただくことができ、ついに4年目に突入しました。



昨年の受賞時にはこんな事を書いていました。

昨年は FIM よりも AD FS2.0 をはじめとしたフェデレーションの話の方が当 Blog のネタとしても多かった気がしますが、今年は SCIM 元年？になる感触もあるので、ちゃんとプロビジョニングの話もしていきたいと思います。（手始めは FIM の SCIM アダプタの作成？）

また、外部向けに話をする際も、これまでは分野の性質上、企業のIT管理者向けにID管理システムの企画～プロジェクトの進め方みたいな話をすることが多かったのですが、今年は技術者向けの勉強会などで話する機会を増やしてもよいのかな？とも思っています。（ニーズがあれば、、ですが）

振り返ってみると、

  • プロビジョニング（SCIM）の話
    • SCIM の話は全然できてない。ただ、Windows Azure Active Directory の Graph API が出てきたので、そちらの話はそれなりに。
    • FIM のアダプタの実装については ECMA2.0 が正式にリリースされたので、 Google Apps 用アダプタはリリース。他のアダプタは結局時間切れ。今年こそは（汗
  • 勉強会での話
    • FIM / AD FS の話とハンズオンを実施できた。時間不足などの問題はあったので、リベンジ予定。。。

といった感じでした。

ということで、今年は、

  • FIM 用アダプタの拡充（SCIM / Windows Azure Active Directory）
  • FIM / AD FS ハンズオンのリベンジ

ですね。

後は、トラストフレームワークに関してようやく企業への適用も見えてき始めたので、そのあたりも少しずつ書いていければ、と思っています。

何はともあれ今年もよろしくお願いいたします！
↧

[FIM2010]R2 用の Service Pack 1 がリリース

January 10, 2013, 5:39 pm
$
0
0

US 時間の 1/7～1/9 に Oxford Computer Group 主催、レドモンドのマイクロソフト本社で開催されていた Redmond Identity, Access & Directory Summit 2013 で Forefront Identity Manager の Program Manager である Andreas Kjellman のセッションで FIM2010R2 向けの Service Pack 1 が発表され、 MSDN / Technet のサブスクライバーダウンロードで入手できるようになっています。

今日時点でまだドキュメントがTechnet/MSDN上には出てきていないので詳細な機能面の話は書けませんが、Windwows Server 2012 / SQL Server 2012 / SharePoint 2013 などの新しいプラットフォームに対応したのと、開発環境として Visual Studio 2012 に対応したりしています。他にも BHOLD Suite との連携用のコネクタの強化など色々とエンハンスされています。

ドキュメントがリリースされた段階でもう少し詳しく書いていきたいと思います。


なお、上述した Redmond Identity, Access & Directory Summit 2013 ですが、かなり濃い内容だったみたいです。Windows Azure Active Directory の ESE データベースの構成とか、中でのレプリケーションの話とか、、、
登壇者も Kim Cameron に Mark Wahl など有名人がいっぱい。。
http://www.oxfordcomputergroup.com/news/general-news/announcing-the-first-annual-redmond-identity-321.php

ようやく日本でも某アイデンティティクラスタのみなさんの努力で JICS（Japan Identity & Cloud Summit）とか開催されるようになりましたけど、こういう製品系の Geek な集まりってなかなかないんですよねぇ。。
↧
Search

[FIM2010]廃止される機能と将来に向けた計画

January 20, 2013, 8:09 am
$
0
0

Forefront Identity Manager 2010 R2 向けの Service Pack 1 がリリースされたところですが、今後の Synchronization Service 機能のサポートに関する情報が Technet に掲載されています。

　Deprecated Features And Planning For The Future
　http://technet.microsoft.com/en-us/library/jj879229(v=ws.10).aspx

概要をピックアップしておきます。
カテゴリ廃止される機能と対応方針
Web Service 設定インターフェイス次バージョンで廃止され、PowerShell コマンドレットが提供されることになる
管理エージェントビルトイン管理エージェントFIM CM、Lotus Notes、SAP R/3 用の管理エージェントが次バージョンで廃止される
Lotus Notes、SAP R/3 用の管理エージェントは新バージョンのもので置き換えられる
ECMA 1/XMA で開発された管理エージェントECMA 2.0 で置き換えられる
FIM Sync Service プロセス外での管理エージェント実行廃止され、管理エージェントは Sync Service と同一プロセスで実行される
パーティションの表示名の設定機能自体はなくならないが、WMI インターフェイスに代替名を提供するためだけに利用される
実行プロファイル複合プロファイル（Delta Import / Sync、Full Import / Delta Sync、Full Import / Sync）は廃止されるので、プロファイルの中で複数ステップを定義する必要がある。
属性の優先順位同一優先順位（Equal Precedence）の廃止。例外として FIM Service MA を使う場合は Manual Precedence が提供されないので Equal Precedence を利用する必要がある
Join ルール任意のオブジェクトへの Join は不可へ。Join ルールを定義するときは明示的にメタバース上のオブジェクトタイプを指定する必要あり
属性フローエクスポートされる値に対する Allow Nulls のチェックボックスを外せない様に。現在の環境でチェックがされていることの確認が必要
Do not recall attributes の廃止。属性は必ず再確認される
ルール拡張プロセス外実行廃止され、FIM Sync Service と同一のプロセスで実行される
トランザクションプロパティーインバウンド、プロビジョニング、アウトバウンド同期の各プロセスの間でデータの受け渡しをしない形で構成する必要がある
ExchangeUtils:Create55* メソッドの廃止Exchange Server 5.5 へのオブジェクト作成機能の廃止
インターフェイス（Mms_Metaverse）次バージョンで ClmUtils クラスメンバはすべて廃止される

既存の FIM のデプロイにも影響があるので、現在 FIM2010 を利用している方は一読し、以後の対応について検討を開始しておくことをお勧めします。


↧
↧

[Office365]サブスクリプションが切れたときの対応

January 20, 2013, 8:35 am
$
0
0

※直接はアイデンティティに関係ないのですが、Office 365 の検証サブスクリプションを次から次へと使うと起きがちなことなので、メモしておきます。

Office 365 の検証を行う際、PC に Office Professional Plus をインストールして Office 365 との連携を行っていると思います。
しかし、この状態で Office 365 のサブスクリプションの有効期限（体験版の有効期限）が切れると PC を起動する度にこんな画面が出てきて怒られます。


そんな時は、コマンドプロンプトより以下のコマンドを実行して Office Professional Plus のサブスクリプション構成を更新する必要があります。

C:\Program Files\Common Files\microsoft shared\OFFICE14\osaui.exe /F

コマンドを実行するとサブスクリプションの構成が始まります。




構成が終わって[閉じる]をクリックするとサブスクリプション ID の入力画面が出てくるので新しい Office 365 のサブスクリプションへサインインします。


構成が終わったら PC をリブートすれば OK です。



↧

RFC化された OAuth 2.0 の翻訳完了

January 22, 2013, 7:51 am
$
0
0
※1/24 追記：6749 core に加えて 6750 bearer についても翻訳が完了してます。

以前 OpenID Foundation Japan のワーキンググループで draft 22 の翻訳をした OAuth 2.0 ですが、先日お伝えした通り無事 RFC 6749 / 6750 となりました。

と、言うことで同じく OpenID Foundation Japan のワーキンググループで RFC 版の翻訳を行いました。




以下のページで公開されています。
　OpenID Foundation Japan ホームページ
　http://openid-foundation-japan.github.com/


draft 22 のベースがあるとは言え、たった数人で始めてから2週間弱で公開できたのは、素晴らしい参加メンバのみなさんのおかげと言えると思います。是非活用していただければと思います。

翻訳メンバ：

  • Boku Kihara (Lepidum)
  • Kazuki Shimizu (Lepidum)
  • Masaru Kurahayashi (Yahoo! Japan)
  • Naohiro Fujie (Itochu Techno Solutions)
  • Noboru Kurumai (Fujitsu)
  • Nov Matake
  • Ryo Ito (mixi, Inc.)
  • Tatsuya Katsuhara (NRI)
  • Yusuke Kondo (Yahoo! Japan)


↧

OpenID Foundation の会員登録方法

January 22, 2013, 8:11 am
$
0
0

そう言えば会員登録していなかったので、登録してみました。
※ちなみに OpenID Foundation Japan への登録ではなく、OpenID Foundationへの登録方法です。OpenID Foundation Japan への登録はホームページから問い合わせてください。

個人会員だと $25/Year です。

個人会員だと、以下のような特典があります。

  • Vote on OpenID workgroups, specifications, and community board members of the OpenID Foundation
  • Use the OpenID Foundation Member logo and signature on your blog, email, website, apps
  • Show your support for OpenID as a community-driven, user-centric identity for the Internet
  • Way to leverage financial support for an important grassroots community
  • Become part of the momentum of OpenID adoption and visibility


まずは、登録 URL へアクセスします。
　登録 URL
　https://openid.net/foundation/members/registration


サイトが表示されたら、まず最初に好きな OpenID でサインインします。


私は Google OP を使いました。




次に、Membership Type を選択します。個人登録をする場合は Indivisual - $25 を選択して、[Next Step] をクリックします。


Contact Information として OpenID Provider から取得した情報が表示されるので、必要に応じて修正して [Next Step] をクリックします。


次は規約への同意です。規約を熟読して問題なければチェックボックスにチェックを入れて [Next Step] をクリックします。


次は会費の支払いです。私が登録したときは何か調子が悪かったのかなかなか支払いがうまくいきませんでした。
支払い方法はクレジットカードか PayPal から選択できますので、私は PayPal を選択しました。


登録内容の確認画面が表示されるので、進むと PayPal にリダイレクトされ、決済を行います。




うまくいけばメンバシップ登録が完了し、メンバシップページへアクセスできるようになります。


皆さんもアイデンティティ界を盛り上げるため、是非登録してみてください。


↧

時代は認証から認可へ？ - XACML3.0 が OASIS 標準として承認

January 23, 2013, 7:45 am
$
0
0
なんだか色々なところで混同されたり誤用されている、「認証」と「認可」というキーワードですが、ちょっと整理をしておきましょう。

  • 認証（Authentication）
    • 要するに本人確認
    • @IT/セキュリティ用語辞典より
      • ネットワークやサーバへ接続する際に本人性をチェックし、正規の利用者であることを確認する方法。一般には利用者IDとパスワードの組み合わせにより本人を特定する。認証がなされると、本人が持つ権限でデータへのアクセスやアプリケーションの利用が可能となる。不正利用を防ぐため、パスワードの漏えいなどには十分な注意が必要である。
  • 認可（Authorization）
    • 認証済みのユーザに対してサービスやリソースへのアクセスを許可すること
    • @IT/セキュリティ用語辞典より
      • 認証（Authentication）によって確認された利用者を識別して、アクセス権限の制御を行い、利用者ごとに固有のサービスを提供すること。
      • 具体的には、利用可能なアプリケーションの制御、ファイルに対する“読み／書き／実行”の権限など、利用者の資格に応じて許可する。認可のための属性情報には、利用者ID／所属グループ／役職／部署／アクセス制御リスト（ACL）などがある。
      • 運用管理の面から、認可はACL（Access Control List）で与えることがセキュリティ上でも望ましく、SSO（Single Sign On）でもACLと組み合わせることが多い。

OAuth や 本日のタイトルにある XACML は「認可」のための仕組みです。
よく OAuth 認証なんていうキーワードを見かけますが、認可サーバへのアクセス時に通常実行される認証プロセスを都合よく使ってしまっているだけであり、OAuth の本質は scope に指定したリソースへのアクセスするためのアクセストークンを認可サーバから受け取って、そのトークンを元に保護されたリソースへアクセスをする、ということです。


脱線しましたが、XACML 3.0 が OASIS 標準として承認されました。
XACML とは何なのか？について、わかりやすく説明するほど詳しくはないので、少し古いですが以下の記事が参考になると思います。（現状他に日本語で解説されているサイトを見たことありません）

　@IT / PKIとPMIを融合させる次世代言語XACML

引用すると以下のように解説されています。
柔軟で拡張性のあるアクセス制御を実現するためのポリシー記述言語XACML（eXtensible Access Control Markup Language）について述べる。SAMLやXACMLはPKIと権限管理のインフラストラクチャであるPMI（Privilege Management Infrastructure）を融合させる次世代のフレームワークである。

で、XACML の歴史ですが、OASIS 標準の Web ページによると、
 - 2003年2月　：　1.0 承認
 - 2005年2月　：　2.0 承認
ということで、今回の 3.0 の承認までにかなり間が空いていたことがわかります。
※個人的にはまだ続いてたんだ、、、という感想だったり。。

いずれにしてもなかなか概念の理解および実装が難しい仕組みなのでなかなか浸透していないイメージがありますが、今回の新版の承認で少しは前進するのかも知れません。

スペックは下記 URL で公開されていますので、興味のある人は参照してみてください。
（まだ Candidate と記載されています）
　eXtensible Access Control Markup Language (XACML) Version 3.0


ちなみに、製品として実装されている例としては、Oracle Entitlements Server (OES) があります。

　製品ページ

ページ内には Sharepoint との連携に関するホワイトペーパーなんかも置いてあるので機会があれば実装してみたいなぁ、、と思ったりします。

　Securing Microsoft Office SharePoint Server (MOSS) with Oracle Entitlements Server 11gr2

↧
↧

ILM ブログ凍結・・・

January 30, 2013, 7:06 am
$
0
0

一つの時代が終わったというか、、、Active Directory を含む Microsoft の ID 管理に少しでもかかわった人なら一度は見たことがあるはずの ADSI / IdM サポートチームの blog が凍結されました。

　管理者は見た！ ～ AD と ILM 一家の秘密 ～
　http://blogs.technet.com/b/jpilmblg/




初めてのエントリが 2008 年 8 月 20 日と、この blog の開始直前（ちなみにこの blog は 2008 年 10 月開始）にオープンした blog ということで若干かぶり気味に、互いによりコアな？ネタを追い求めつつこれまでやってきたので非常に残念です。


ILM blog 第1回
　はじめまして。ADSI/ILM サポートチームです！
　http://blogs.technet.com/b/jpilmblg/archive/2008/08/20/adsi-ilm.aspx


　　※しっかりリンクを張っていただいておりました。


ちなみにこの blog の第1回
　早速始めてみます
　http://idmlab.eidentity.jp/2008/10/blog-post.html



何はともあれ、約4年半もの長い間お疲れ様でした！


↧

[FIM2010] R2 SP1 リリース後、初の HotFix

February 19, 2013, 3:17 pm
$
0
0

早くも HotFix(4.1.3419.0)が出てます。
　http://support.microsoft.com/?id=2814853

基本的にバグフィックスのみですね。

FIM Synchronization service
  • Issue 1
    • In some cases, the Exchange configuration options on the Active Directory Management Agent do not appear. These options will now always be visible even if Exchange is not detected in the source directory.
  • Issue 2
    • When Exchange post-processing PowerShell cmdlets are run during export on the Active Directory Management Agent, the host process can stop for many reasons. In this case, the Active Directory Management Agent continues the export but does not try to run the Exchange cmdlets. With the changed behavior in this fix, the export run is now stopped so that the process can be restarted from where it ended.
  • Issue 3
    • The Synchronization service crashes in certain scenarios when references to newly created objects are exported into ECMA2 Connector (also known as "reference retry").
  • Issue 4
    • An ECMA1/XMA with call-based export crashes the Synchronization service. This problem occurs in some scenarios in which the following conditions are true:
    • Reference attributes are constantly rejected by the target directory.
    • The Synchronization service is trying to determine which value is causing the problem. It does this by trying to export a multivalued reference attribute as several individual changes (known as "fourth pass reference retry").
  • Issue 5
    • A full import might be stuck at the "Completing-Obsoletions" stage if the obsoletion of an object cascades into the obsoletion of related objects.


FIM service and portal

  • Issue 1
    • If a user who has access to advanced pages for a group (typically, an administrator) made a change to the object in this view, the group would contain invalid members. If the user was trying to delete the group, the system would be in a state in which no additional requests could be processed.


尚、HotFix を適用した後、Syncronization Service で拡張エージェント（ECMA1/ECMA2）を使っている場合に「stopped-extension-dll-load」エラーが出る場合があるので、その場合はちゃんと MIISServer.exe.config ファイルの dependentAssembly セクションを編集して正しいアセンブリのバージョンを参照するように設定してあげる必要があります。

しかし、機械翻訳の「Forefront ユーザー マネージャー 2010 R2」ってやめてほしいですねｌ。

↧
Search

[ADFS2.0] Rollup 3 がリリース

February 19, 2013, 3:33 pm
$
0
0

今月はシアトルに来ていたりするので、前後を含め色々と忙しくてこんなネタばっかりです。。

AD FS2.0 Rollup 3 がリリースされています。
　http://support.microsoft.com/kb/2790338

これまでの Rollup では機能拡張があったのですが、今回はバグフィックスのみです。
- Rollup 1 / Office365 対応の強化
　http://idmlab.eidentity.jp/2011/10/ad-fs20-rollup-1-office-365.html
- Rollup 2 / SAML 仕様対応の強化
　http://idmlab.eidentity.jp/2012/05/ad-fs20-rollup-2.html


  • Issue 1
    • AD FS 2.0 does not issue an ActAs token for a relying party who is using a Security Assertion Markup Language (SAML) 2.0 bootstrap token. When this issue occurs, the following error is generated:
    • System.IdentityModel.Tokens.SecurityTokenException: ID4154: A Saml2SecurityToken cannot be created from the Saml2Assertion because it contains a SubjectConfirmationData which specifies an InResponseTo value. Enforcement of this value is not supported by default. To customize SubjectConfirmationData processing, extend Saml2SecurityTokenHandler and override ValidateConfirmationData.
    • After you apply AD FS 2.0 update rollup 3, AD FS 2.0 successfully issues the token in this situation.
  • Issue 2
    • AD FS 2.0 acts as a federation provider and receives an invalid SAML 2.0 signed request (for example, the signature is not valid or the requestor is unknown). In this situation, AD FS 2.0 rejects the request only after it forwards the request to the downstream identity provider and receives a valid SAML response.
    • In order to make sure the validity of the requests that are sent to the downstream identity provider, the expected behavior is that AD FS 2.0 validates SAML requests and rejects any requests that have invalid signatures.
  • Issue 3
    • AD FS 2.0 update rollup 2 introduced strict Uniform Resource Identifier (URI) checking. When AD FS 2.0 acts as a federation provider and trusts an identity provider whose identifier is not an URI, the response that is returned from the identity provider is rejected by AD FS 2.0. The validation fails because AD FS 2.0 tries to validate the value of the identity provider’s identifier. This behavior breaks previously functioning AD FS 2.0 deployments in which identity providers use non-URI identifiers. AD FS 2.0 update rollup 3 removes this URI checking.
  • Issue 4
    • Some relying parties require that signature certificates are applied to the relying party for SAML requests, as signature certificates provide a critical security validation function and are defined in the SAML 2.0 specification. AD FS 2.0 is capable of allowing unique signature certificates to be applied to a relying party trust, but it only allows the same certificate to be applied to one relying party trust per AD FS 2.0 farm. This restriction may allow multiple relying parties to use the same signing certificate for SAML requests. AD FS 2.0 update rollup 3 removes this restriction and allows multiple relying parties to use the same signing certificate for SAML request.
  • Issue 5
    • Consider the following scenario:
    • You use a third-party hardware security module (HSM) to speed up the signing processes.
    • You use the third-party HSM and to generate and store the private keys.
    • The private keys are for AD FS 2.0 signing and for AD FS 2.0 encryption certificates.
    • In this situation, the performance of AD FS 2.0 is not as good as when you use Microsoft CSP. AD FS 2.0 update rollup 3 significantly improves the performance of AD FS 2.0 when HSM is used.
  • Issue 6
    • AD FS 2.0 update rollup 1 introduces the Congestion Avoidance Algorithm. If you accidentally disable the Congestion Avoidance Algorithm by changing the configuration, a handle leak occurs on an AD FS 2.0 federation server proxy every time that the federation server proxy processes a request. AD FS 2.0 update rollup 3 removes the setting that enables you to disable Congestion Avoidance Algorithm by changing the configuration. You can fine tune the Congestion Avoidance Algorithm by adjusting the latencyThresholdInMsec and minCongestionWindowSize settings.

↧

#idcon mini に参加してきた

February 27, 2013, 8:55 am
$
0
0
Identity Conference Mini に参加しました。
　- http://atnd.org/events/36953


今日は、@hdknrさんによる OneID と Self-Issued OP の話と私が SCIM 関係の話をさせてもらいました。

@hdknr さんの OneID、Self Issued OP の話では、 OneIDのサービスの話が聴けました。
ざっくりいうと、OP で認証するときに ID / Password の代わりに、スマートフォンを使って認証する、という仕組みのようです。
流れとしては、
１．ブラウザで RP へアクセス
２．OneID によりブラウザ上に QR コードが表示される
３．携帯電話で QR コードを読み、OP へ＝認証
４．ブラウザへトークンが渡され、RP へアクセス可能
というような感じでした。

PC と 携帯の間で KeyPair を共有しており、認証済みの携帯で QR コードを使って OneID へアクセスすることで認証とみなす、という形です。

メリットとしては
・パスワードがいらない
・OP へ渡る属性は暗号化されており、OP の運営者でも内容を参照できない
という2点がメインです。


次に、私が SCIM の話をしました。
若干無理やりではありますが、Windows Azure Active Directory がプロビジョニング API として Graph API を採用しているのは何故か？今後サービスプロバイダは SCIM を使うのが良いのか？Graph を使うのが良いのか？という話をしました。結果的に答えはないのですが、私の個人的な考えとしては、SCIM が目指したのはあくまでスキーマやプロトコルの標準化によるコスト削減や複雑性の低減で、Graph の目指すオブジェクト（ノード）とオブジェクト間の関係性（Edge）の表現とは別お世界であり、今後は現行の SCIM の様に同一レポジトリ内のオブジェクト間の関係（memberとmemberofなど）だけではなく、Federation などによる外部レポジトリ上のオブジェクトとの関係性についても表現することが大切になるのではないか？という話をさせていただきました。

以下が、資料です。
スライドにも書きましたが、答えがない世界なので色々と議論が継続的にできれば、と思います。

↧
↧

[JICS]なかなか面白いサービス「Trulioo」

March 4, 2013, 5:30 pm
$
0
0

昨日～本日開催されているJapan Identity & Cloud Summit(JICS)に参加しています。

学認、OpenID Summit、Enterprise、Trust Frameworkなど色々なコンテンツがそろっていてものすごい情報量です。


その中で併設された展示ブースに出展されていた「Trulioo」の話を聞いて非常に面白い、と思ったので少し紹介します。

◆サービス概要
簡単に言うと、「ソーシャルIDの信頼レベルを判定してくれるサービス」です。

各種サービスへのサインインやログインにFacebookなどのソーシャルIDを使う、というのはすでにかなりメジャーな方法になってきていますが、一方で昨今メディアなどでも取り上げられている「なりすましアカウント」や「使い捨てアカウント」などを使ってサービスを利用することによる被害（例えば偽アカウントで商品を注文したり、宿の予約をしたり）も問題視され始めています。

そこで、各サービスはFacebookでのログインをさせる前に、Truliooのようなサービス（API）を利用して信頼レベルを判定することで、リスクを低減することが出来ます。

内部的な判定ロジックは非公開ですが、FacebookのIDからサービス側で保持しているデータベース等を利用して信頼レベルを判定するようです。

このAPIを実行すると、結果として信頼レベルが0～400で返ってきます。


この結果を使って各種サービスは利用者アカウントに対する各種アクションを決めてく、という仕掛けです。


◆使い方
まずはTruliooにサインアップします
https://trulioo.com/を開くと右下に[Wants To Try Our ProfilePlus API?]というボタンがあるので、[Register]をクリックし、各種情報を入力し、登録を行います。
※今はJICS特別サイトが用意されており、そこからだと更に登録が楽です。
　https://trulioo.com/jics/

登録が完了したら、Developerポータルへログイン出来るようになります。今回はテストなのであらかじめ用意されているテストツールを使って確認してみます。
右側のメニューからAPI Referenceを選択するとテストツールへアクセスできますので、このツールを使います。


このツールに設定するパラメータは、
・apikey
・provider（現状fb/facebook固定）
・token
の3つです。

まず、apikeyですが同じくDeveloperポータルのApp Setting & StatsのProfilePlus API Accessメニューから取得できます。


次にtokenですが、これはFacebook上のリソースへアクセスするためのaccess_tokenを設定します。
こちらもテストなので、FacebookのGraph APIエクスプローラを利用します。
Graph APIエクスプローラを開いた後、[アクセストークンを取得]ボタンをクリックし、必要な権限を設定し、アクセストークンを取得します。
必要になる権限は、
　・email
　・user_photos
　・user_groups
　・user_status
　・user_videos
　・user_events
　・read_stream
です。


apikey,tokenを取得できたら先ほどのツールへ戻り、パラメータをセットして[Try it out!]をクリックします。
すると、判定結果がjsonで返ってきます。
どうやら私のFacebookアカウントの信頼レベルは400（Normal - High）なようです。


今回はテストでしたが、Request URLにapikey,provider,tokenを付けてGETするだけなので、簡単にサービスへ組み込みが可能です。
例えば、Windows Azure Active DirectoryのAccess Control Serviceを使ってFacebookのアクセストークンを取得して、Truliooで信頼性レベルをチェックしてからサービスを利用させる、といった形が簡単に実装できそうです。

◆課題
ここまで簡単な紹介をしてきましたが、ざっと使った中で少し課題と感じた部分を書いておきます。

・ユーザ同意の取り方
　先にも書きましたが、Truliooを使う上で必要なパーミッションとして、以下へのアクセスが要求されます。
　・email
　・user_photos
　・user_groups
　・user_status
　・user_videos
　・user_events
　・read_stream

　しかし、Facebookへのアクセス時に表示される同意画面だけで「なぜその属性や情報が必要なのか？」を理解するのは中々厳しいのではないかと思います。（特にサービス自体を利用する上で不要と思われるものが多いため）
　と、いうことでサービス側の考慮点として、TruliooでFake Accountの判別をしていることをログイン画面などにしっかり記載しておき、なぜそれらの属性が必要なのかを利用者が理解できるようにしておくことが必要になるのではないかと思います。

◆まとめ
こんな感じです。
・ソーシャルIDでサービスを利用してもらう、というのはハウスリスト拡充の意味でも、サービス内でのアクティビティ向上の意味でも有意義である
・しかし、Fake Accountが多発するといった課題も抱えているのが実情である
・そこでアカウントの真贋レベルを確認するTruliooのようなサービスを使うのも一手である
・しかし、真贋を確認するために必要な情報の取得が発生するため、利用者に分かりやすい形での同意の取得を検討すべきである
↧

[IdM用語]NASCAR問題

March 8, 2013, 6:08 pm
$
0
0

アイデンティティ界隈では普通に使われている言葉なのに Google 先生に聞いてみても答えが出てこない言葉って結構あったりします。
その一つが、「NASCAR 問題」です。

日本語でそのまま検索すると Wikipedia の OpenID のページに以下のように記述があります。

Account ChooserOpenID Authentication 2.0, OpenID Connect のみではなく、SAMLなどでも問題になる ユーザーインターフェースの問題 (NASCAR問題、WAIF問題）を解決すべく検討されている 仕様。

どうやらユーザーインターフェースの問題らしい、というところまではわかりますが、具体的にどういう問題なのか、NASCARって何なのか、についてはよくわからないままです。



というわけで簡単に解説です。（もっとうまく解説できる、もしくは違うよ、という方はご連絡・ツッコミください！）

簡単に言ってしまうと、
OpenID や SAML などで外部 IdP を使ってサービスへログオンするとき、IdP が増えてくるとユーザが自分がログオンに使う IdP を探し出すのが難しくなって利便性が下がってしまう
という問題です。
ログオンメニューに Facebook のアイコンや Twitter のアイコン、Yahoo! や Mixi や、、、という様にずらりと並んでいるのを見たことはないでしょうか？

例えば OpenID Foundation のページへログオンするときは以下の様に自分が使う OP（OpenID Provider）を選択することになります。



で、Account Chooser を使うと一回ログオンした IdP の情報を覚えておいてくれるので、毎回使ってもいない IdP が沢山並んでいる中から自分が使う IdP を選んでログオン、という手間が省けますよ、という流れです。
ちなみに Account Chooser 自体に関する情報は OpenID Foundation Japan の Evangelist である @nov 氏、 @ritou 氏が解説しているので、ここを参照してください。

- @IT の記事 by @nov 氏
　セキュアで使いやすい認証UX標準化を目指すAccount Chooserプロジェクト
　http://www.atmarkit.co.jp/ait/articles/1301/28/news010.html

- r-weblife by @ritou 氏
　GoogleでわかるAccount Chooser
　http://d.hatena.ne.jp/ritou/20111119/1321688092


で、NASCARって何なのか？だけが残ってしまいました。
NASCAR（ナスカー）とは National Association for Stock Car Auto Racing / 全米自動車競争協会のことです。

こんな車が走ってるレースです。


これとアイデンティティとの関係ですが、車を良く見ると各スポンサーのロゴステッカーが所狭しと並んでいるのが見えると思います。これって先ほどの IdP のロゴが並んでいるのと似てますよね？ということで、NASCAR みたいだから NASCAR 問題ということです。

他にも色々とマニアック用語がありそうなので、時々解説していこうと思います。

↧

[Office365]AD FS2.0以外でSSOに挑戦

March 24, 2013, 9:32 am
$
0
0

先日の MS 安納さんのポスト「【IDM】Windows Azure Active Directory と Office 365 と外部 IdP の関係（予想）」を見て、ちょうど Windows Azure Active Directory（WAAD）の中身を調査していたところだったので、色々と試してみました。

やろうとしたことは、WAAD の Access Control Service（ACS）を経由して Facebook や Google アカウントを使った Office365 へのシングルサインオンです。
結果、失敗するのですが、その過程で色々と仕組みが想像できたのでメモとして上げて起きます。

■まずは情報収集
現在、サードパーティ IdP での WAAD / Office365 へのフェデレーションの例としては、以下のような設定ドキュメントが公開されています。

・Ping Federate　 http://documentation.pingidentity.com/display/PFS/Set+up+Active+Directory+and+Directory+Synchronization#SetupActiveDirectoryandDirectorySynchronization-9000025
・Shibboleth
　http://technet.microsoft.com/ja-jp/library/jj205463.aspx

後は、AD FS2.0 でシングルサインオンを構成した WAAD / Office365 のドメイン設定がどうなっているのか、を直接調べるとことも参考になりそうです。

また、Offce365 のシングルサインオンに関するドキュメントを見ると Office365 側の前提事項なども見えてきます。
　https://portal.microsoftonline.com/IdentityFederation/IdentityFederation.aspx


調査の結果、WAAD / Office365 が外部 IdP とフェデレーションを行うには、以下が必要なことがわかります。

◆WAAD / Office365 側の状態
　- ディレクトリ同期が行われている状態であること
　　こんな記載があります。
　　シングル サインオン (ID フェデレーション) をセットアップすると、ユーザーは会社の資格情報でサインインして、Microsoft Office 365 for enterprises のサービスにアクセスできます。シングル サインオンのセットアップの一部として、ディレクトリ同期をセットアップする必要もあります。また、これらの機能をお使いの社内のディレクトリおよびクラウドのディレクトリに統合する必要があります。

　- シングルサインオンを有効にしたドメインを利用すること
　　まぁ当たり前ですが、ログイン画面（https://login.microsoftonline.com/login.srf）でログイン ID のドメインパート（@以下）を判別して、ログイン先の IdP を判別する以上、WAAD / Office365 がシングルサインオンドメインとして認識しているドメインが必要です。

　　ドメインの設定は Set-MsolDomainAuthentication コマンドレットを使うのですが、必要なパラメータは以下の通りです。
　　- DomainName : ドメイン名
　　- FederationBrandName : ブランド名（表示名）
　　- ActiveLogOnUri : Active Logon をする場合のエンドポイント
　　- IssuerUri : IdP の EntityID
　　- PassiveLogOnUri : Passive Logon をする場合のエンドポイント
　　- LogOffUri : ログオフする際のエンドポイント
　　- MetadataExchangeUri : Metadata Exchange のエンドポイント
　　- PreferredAuthenticationProtocol : 利用するフェデレーション・プロトコル
　　- SigningCertificate : 署名に利用する証明書

　　ちなみに AD FS2.0 と連携している WAAD / Office365 のドメインの情報を Get-MsolDomainFederationSettings コマンドレットで取得すると以下のような状態になっています。
パラメータ設定値
DomainNameドメイン名（コマンドレットの引数として指定）
FederationBrandNameFQDN
ActiveLogOnUrihttps://FQDN/adfs/services/trust/2005/usernamemixed
IssuerUrihttp://FQDN/adfs/services/trust
PassiveLogOnUrihttps://FQDN/adfs/ls/
LogOffUrihttps://FQDN/adfs/ls/
MetadataExchangeUrihttps://FQDN/adfs/services/trust/mex
PreferredAuthenticationProtocolWSFed（コマンドレットでは出ない）
SigningCertificatexxxxxx



◆外部 IdP の設定
　当然、外部 IdP 側には RP として WAAD / Office365 を設定する必要があリます。
　WAAD / Office365 の Federation Metadata が
　　https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml
　で公開されているので、中身を見てみます。
　必要なのは、IdP から見ると Audience に該当する EntityID 部分とトークンを POST するアサーション・コンシューマ・サービスのエンドポイントアドレスです。
　Federation Metadata を見ていくと、
　- entityID="urn:federation:MicrosoftOnline"
　- AssertionConsumerService ～中略～ Location="https://login.microsoftonline.com/login.srf"
　とあります。

　あとは、使用するプロトコルですが、Set-MsolDomainAuthentication コマンドレットなどフェデレーションドメインの設定用ツールのオプションである PreferredAuthenticationProtocol がとりうる値を見ると、WSFed / SAMLP とあるので、WS-Federation もしくは SAML-P が可能なことがわかります。
　今回は ACS を使ったので、自動的に WSFed を選ぶことになりますが、その場合に SAML トークンのバージョンが気になります。FireFox の SAML Tracer などを使って AD FS2.0 と WS-Federation で連携している WAAD / Office365 との間を飛んでいる SAML トークンを見ると、
　　saml:Assertion+MajorVersion="1"+MinorVersion="1"+AssertionID=xxx
　という記述が見えるので、 SAML トークンは 1.1 を使うことがわかります。

◆アサーション（クレーム）
　- AD FS2.0 の要求規則を見ると、以下のアサーション（クレーム）が発行されることが必要です。

AttributeTypeValue
nameidentifierhttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifierAD上のオブジェクトのGUIDの値をbase64エンコードしたもの
UPNhttp://schemas.xmlsoap.org/claims/UPNAD上のオブジェクトのUserPrincipalName（xx@xx.com）
ImmutableIDhttp://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableIDAD上のオブジェクトのGUIDの値をbase64エンコードしたもの


　　ちなみに、AD FS2.0 が実際にどのようなアサーションを出しているのかを確認する場合は、ClaimGrabber（http://www.theidentityguy.com/articles/2011/6/5/introducing-claimgrabber.html）を使うと便利です。


　　当然、このアサーションの中のそれぞれの値が WAAD / Office365 上に同期されたユーザの属性と一致している必要があります。（特に NameIdentityfier として使われる ImmutableID の値が重要）
　　ユーザの属性を調べるには Get-MsolUser コマンドレットを使います。
　　こんな感じで、ImmutableID の値を取得します。
　　＞ Get-MsolUser -UserPrincipalName xxx@xxx.com | fl ImmutableID
　　すると、
　　ImmutableId : VNzO5OVz+Emv66IULItTCg==
　　という形で値が取得できます。



まとめると、以下が外部 IdP と WAAD / Office365 のフェデレーションの条件になりそうです。
対象条件
WAAD / Office365ディレクトリ同期構成済みであること
ドメインシングルサインオンドメインが構成されていること
外部 IdPRP の 識別子（EntityID）urn:federation:MicrosoftOnline
RP の エンドポイントhttps://login.microsoftonline.com/login.srf
プロトコルWS-Federation
SAML トークン形式SAML 1.1
アサーションNameIdentifierADのGUIDをBase64エンコードした値（Get-MsolUserで取得した値と一致していること）
ImmutableID同上
UPNADのUserPrincipalNameの値



■実際にやってみる
では、早速 ACS を使って上記を構成してみます。

◆WAAD / Office365
　ディレクトリ同期は普通に DirSync を使って構成します。
　具体的なやり方は、手前味噌ですが、
　　@IT / Office 365とのアイデンティティ基盤連携を実現する（前）
　　http://www.atmarkit.co.jp/ait/articles/1211/14/news069.html
　を参考にしてください。

　ドメインの設定ですが、ACS の Federation Metadata から取得した値を設定します。
　ACS の Federation Metadata は
　　https://テナント名.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml
　なので、必要な値はここから取得します。
　といっても使うのは IssuerUri と PassiveLogOnUri と MetadataExchangeUri だけです。
　- IssuerUri : https://テナント名.accesscontrol.windows.net
　- PassiveLogOnUri : https://テナント名.accesscontrol.windows.net/v2/wsfederation
　- MetadataExchangeUri : https://waadnew1.accesscontrol.windows.net/v2/wstrust/mex

　これらの値を使って WAAD / Office365 上にドメインを構成します。
　まずは、ドメイン自体の作成です。
　＞ Connect-MsolService
　で WAAD / Office365 へ接続し、
　＞ New-MsolDomain -Name 作成するドメイン名 -Authentication Federated
　と打ってフェデレーションドメインを作成します。

　次に、ドメイン所有権の確認のための CNAME レコードの出力と作成です。
　＞　Get-MsolDomainVerificationDns -DomainName 作成したドメイン名
　ここで出てくる Label の値を DNS 上に登録します。

　登録が完了したら、確認と同時に IdP の設定もしてしまいます。

　＞ $domainName = "ドメイン名"
　＞ $brandName = "ラベル名"
　＞ $issuerUri = "https://テナント名.accesscontrol.windows.net"
　＞ $passiveLogOnUri = "https://テナント名.accesscontrol.windows.net/v2/wsfederation"
　＞ $logOffUri = "https://テナント名.accesscontrol.windows.net/v2/wsfederation"
　＞ $activeLogOnUri = "https://テナント名.accesscontrol.windows.net/v2/wsfederation"
　＞ $metadataExchangeUri = "https://テナント名.accesscontrol.windows.net/v2/wstrust/mex"
　＞ $signingCertificate = "xxxxxxxxxx"

　として引数を設定し、Confirm-MsolDomain コマンドレットを実行します。
　＞ Confirm-MsolDomain -DomainName $domainName -FederationBrandName $brandName -ActiveLogOnUri $activeLogOnUri -IssuerUri $issuerUri -PassiveLogOnUri $passiveLogOnUri -LogOffUri $logOffUri -MetadataExchangeUri $metadataExchangeUri -PreferredAuthenticationProtocol WSFed -SigningCertificate $signingCertificate


◆ACS の設定
　次は ACS の設定です。
　ACS の IdP の設定として Facebook や Google などを設定するのですが、ここでは詳細は省略します。Facebook の場合、Facebook 上にアプリを構成して Consumer Key と Consumer Secret を取得するのと、Callback URL に ACS を設定するだけです。

　ここでは RP 設定（証明書利用者アプリケーション）とクレーム・ルール（規則グループ）の設定を行います。
　まずは RP 設定は以下の通りです。
　- 領域 : urn:federation:MicrosoftOnline
　- 戻り先 URL : https://login.microsoftonline.com/login.srf
　- トークン形式 : SAML 1.1


　次にクレーム・ルールですが、どうやって Facebook などから AD の GUID を Base64 エンコードした NameIdentifier / ImmutableID を取得しようか、、という話になります。
　やり方としては実は ImmutableID は必ずしも AD の GUID を Base64 エンコードした値そのものでなくても良い、という点を利用します。ユーザを WAAD / Office365 に作っているのはディレクトリ同期ツール（つまり FIM2010）なので、ImmutableID（ディレクトリ同期ツール上では SourceAnchor）に Facebook から取得できる他の値に設定してあげればよいわけです。
　ACS が Facebook から取得するクレームとしては Facebook 上のユーザID（数字の羅列）があるので、それを ImmutableID として設定してしまいます。
　簡単なアプリケーションを作って ACS が Facebook から取得する nameidentifier の値を取得し、それを AD 上のどこか適当な属性の値に設定し、ディレクトリ同期ツールの属性マッピングの設定を変えてしまいましょう。

　と、正攻法？は上記なのですが、面倒なので、逆のアプローチもあります。
　AD と同期したユーザの ImmutableID の値を ACS が nameidentifier や ImmutableID として出力できればよいわけなので、ACS の出力要求の値に直接取得した ImmutableID の値を入れてしまいます。当然一人しか使えなくなりますが、実験なので良しとします。


ここまでで一通りの設定は終わりです。さっそく実験します。

■いざ、試す
結果、失敗します。



ここまでは順調。
そして失敗。。。


■原因を考えてみる。。
　正常に使える AD FS2.0 でのログオンの場合と、失敗する Facebook のパターンを比較してみます。
　Firefox の SAML Tracer を使って https://login.microsoftonline.com/login.srf に POST されるアサーションの中身を比較してみます。
　saml:AttributeStatement の中身はほぼ同じです。AD FS2.0 側は NameIdentifierに Format プロパティで urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified が設定されていますが、AD FS2.0 のクレーム・ルールのオプションを付ける部分を削除してもちゃんとログオンはできたのでここは原因ではなさそうです。

　しかし、そのままアサーションを見ていくと、、ありました、圧倒的な違いが。
AD FS2.0 の出力したアサーションには AuthenticationStatement が存在しますが、ACS の出力したアサーションには AuthenticationStatement がありません。
　確かに ACS 自体は認証をしている訳ではないので AuthenticationStatement が出力されるわけがありません。ちなみに ACS の IdP を Google にしても結果は同じなので、ACS の先の IdP がどうやって認証したのか？という情報は ACS からの出力クレームには含まれません。

　ということで、おそらく原因はこれです。
　尚、私はここであきらめたのですが、どなたかその先を深堀して出来れば解決してみて頂きたいなぁ、、と。


■実験を通しての感想
　ACS は非常に便利なのですが、クレーム・ルールの編集でできることが非常に少ないです。せめて AD FS2.0 の要求規則の編集程度のカスタマイズが出来れば色々と可能性が広がると思います。

↧
Viewing all 771 articles
Browse latest View live
Search