ラベル WAAD の投稿を表示しています。 すべての投稿を表示
ラベル WAAD の投稿を表示しています。 すべての投稿を表示

2015年1月20日火曜日

[AzureAD]管理者アカウントの権限の絞り込み

注)現在Public Previewとして提供されている機能について紹介しているため、正式版がリリースされるタイミングで機能が変更になる可能性がありますのでご承知おきください。

ここしばらくAzure Active Directory(AzureAD)の管理アカウントの権限の絞り込みについて試行錯誤をしてきましたが、今回は現在Public Previewとして提供されている「Administrative Units(管理単位)」の機能について紹介します。
今のところ、やりたいことに一番近い機能はこれかも知れません。

まず、おさらいですが、やりたいことは以下の通りでした。

  • シングルテナントのAzureADに複数のドメインを作成する
  • 複数の企業や組織が各ドメインを使用、各組織のオンプレADからユーザを同期する
  • 各組織の管理者は自ドメインのユーザのみを管理したい


これまでのポストでは多要素認証やFederationを使って各ドメインの管理者アカウント(AADSyncに設定するユーザ)の権限を制限しようとしましたが、うまい方法はありませんでした。
 [AADSync/DirSync]同期に使うAzureAD管理者アカウントの管理
 [AADSync/DirSync]同期に使うAzureAD管理者アカウントの管理(続)
 [AzureAD]管理者アカウントでAzureにサインアップする


今回は昨年12月にPublic Preview公開されたAdministrative Units(管理単位)を使ってみます。
この機能はAzureADのディレクトリを論理的な単位に分割し、それぞれの管理権限をユーザへ委譲するための仕組みです。(オンプレActive DirectoryでOU単位で管理権限を委譲するのと同様の考え方です)

想定ケースの例として地域ごとに管理者をアサインするようなケースがあげられています。


Active Directoryチームのblog
 Wrapping up the year with a boat load of Azure AD news!

MSDNドキュメント
 管理単位の管理 - パブリック プレビュー


では、簡単に試してみます。

現状はPowerShellコマンドレットでしか操作が出来ませんので、PowerShellを使います。
必要なWindows Azure Active Directory管理PowerShellモジュールのバージョンは1.0.8070.2以上です。

以下のコマンドで使っているバージョンがわかります。
> (get-item C:\Windows\System32\WindowsPowerShell\v1.0\Modules\MSOnline\Microsoft.Online.Administration.Automation.PSModule.dll).VersionInfo.FileVersion

⇒現状の最新版だと「1.0.8262.2」が出てきます。


以下の順に操作をします。(特定のAU以下のユーザしか管理出来ないように管理者の権限を制限します)
①グローバル管理者でAzureADに接続する
②管理単位(AU)を作成する
③管理単位(AU)に管理対象ユーザを追加する
④管理者ユーザにスコープ付管理ロールを付与する

結果的に言いますと、管理者は③で管理対象ユーザについてだけ「更新」が出来るようになります。
つまり、
・管理対象外ユーザの参照は出来てしまう
・新規にユーザを作成したり、削除することは出来ない
ということなので、やはり元々やりたかったことは実現出来ません。(当然AADSyncに管理者アカウントとして設定してもユーザの作成などが出来ないので実質使えません)


とりあえず現状出来ることを見てみます。

AU名TestAU
AUメンバkenshinu@example.com
AU管理者auadmin@example.com


◆設定
①グローバル管理者でAzureADに接続する
> Connect-MsolService

②管理単位(AU)を作成する
> New-MsolAdministrativeUnit -DisplayName "TestAU" -Description "Test AU"

ExtensionData       Description         DisplayName         ObjectId
-------------       -----------         -----------         --------
System.Runtime.S... Test AU             Test AU             edfd9c4a-e529-46...

③管理単位(AU)に管理対象ユーザを追加する
> $au = Get-MsolAdministrativeUnit -SearchString "TestAU"
> $user = Get-MsolUser -UserPrincipalName "kenshinu@example.com"
> Add-MsolAdministrativeUnitMember -AdministrativeUnitObjectId $au.ObjectId -AdministrativeUnitMemberObjectId $user.ObjectId

④管理者ユーザにスコープ付管理ロールを付与する
> $role = Get-MsolRole -RoleName "User Account Administrator"
> $admin = Get-MsolUser -UserPrincipalName "auadmin@example.com"
> Add-MsolScopedRoleMember -RoleObjectId $role.ObjectId -AdministrativeUnitObjectId $au.ObjectId -RoleMemberObjectId $admin.ObjectId

◆確認
①管理者ユーザでAzureADに接続する
> Connect-MsolService

②ユーザ一覧を参照する
> Get-MsolUser

UserPrincipalName          DisplayName                isLicensed
-----------------          -----------                ----------
mitsuhidea@example.net     Mitsuhide Akechi           True
nfujie@hoge.onmicrosof...  富士榮尚寛                 True
auadmin@example.com        AU Admin                   False
kenshinu@example.com       Kenshin Uesugi             True
⇒残念ながら全員見えてしまいます。

②管理対象ユーザを更新する
> Set-MsolUser -UserPrincipalName kenshinu@example.com -UsageLocation CA
⇒問題なく更新できます

③管理対象外ユーザを更新する
> Set-MsolUser -UserPrincipalName mitsuhidea@example.net -UsageLocation CA
Set-MsolUser : Access Denied. You do not have permissions to call this cmdlet.
発生場所 行:1 文字:1
+ Set-MsolUser -UserPrincipalName mitsuhidea@example.net -UsageLocatio ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
    + CategoryInfo          : OperationStopped: (:) [Set-MsolUser], MicrosoftO
   nlineException
    + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.Acces
   sDeniedException,Microsoft.Online.Administration.Automation.SetUser
⇒権限がないって言われます

④ユーザを作成する
> New-MsolUser -UserPrincipalName hoge@example.com
New-MsolUser : Access Denied. You do not have permissions to call this cmdlet.
発生場所 行:1 文字:1
+ New-MsolUser -UserPrincipalName hoge@example.com
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [New-MsolUser], MicrosoftO
   nlineException
    + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.Acces
   sDeniedException,Microsoft.Online.Administration.Automation.NewUser
⇒権限がないって言われます

⑤ユーザを削除する
> Remove-MsolUser -UserPrincipalName kenshinu@example.com

確認
この操作を続行しますか?
[Y] はい(Y)  [N] いいえ(N)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"):
Remove-MsolUser : Access Denied. You do not have permissions to call this cmdle
t.
発生場所 行:1 文字:1
+ Remove-MsolUser -UserPrincipalName kenshinu@example.com
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [Remove-MsolUser], Microso
   ftOnlineException
    + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.Acces
   sDeniedException,Microsoft.Online.Administration.Automation.RemoveUser
⇒権限がないって言われます

⑥管理者ユーザでAzureサブスクリプションにサインアップし管理ポータルからディレクトリを操作する
 ⇒ユーザ一覧が見えません。PowerShellだと見えるんですが、管理ポータルからだと管理対象AUのメンバユーザすら見れません。


現状はこんな感じです。
今後はグループオブジェクトなんかもAUメンバに追加できるようになったりするようなので、今後の進化に期待です。

2014年12月14日日曜日

[Office365/AzureAD]OpenAMとのID連携②

前回のポストの続きです。
今回は予告した通りID連携を、カスタムドメインの作成~SSO設定、OpenAMのIdP/SP/CoT(Circle of Trust)定義の順に実際に設定していきます。

◆OpenAM/IdP(Identity Provider)設定

今回の構成はOpenAM上のユーザでOffice365へログオンしたいので、OpenAMをIdentity Provider(IdP)として設定する必要があります。

尚、実際にはOffice365とOpenAMの間にAzureADが挟まっており、Office365/portal.office.com⇒(ws-federation)⇒AzureAD/login.microsoftonline.com⇒(SAML2.0)⇒OpenAMという流れになります。

前回も掲載した図を厳密に書くと以下のようになります。


早速設定を始めます。
OpenAMのインストールを終了し、管理コンソールの[共通タスク]より[ホストアイデンティティープロバイダの作成]をクリックし、IdP定義を作成します。


ここでの設定項目は署名に使う鍵とトラストサークルの2点だけです。
以下を設定します。
・署名鍵:test(実験なので。実際はちゃんとした証明書を使ってください)
・トラストサークル:新しいトラストサークルに追加、トラストサークル名「例)MSO365」



◆OpenAM/RP(Relying Party)設定

次はOffice365をOpenAMにRPとして設定します。
Office365はSAML2.0のメタデータを公開しているので、それをベースにRP設定をします。

まずは以下のURLにアクセスし、メタデータをダウンロードします。
https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml
※私はいつもIEで上記URLを開き、ファイルメニューの名前を付けて保存よりXMLファイルを保存しています。

早速ダウンロードしたメタデータをOpenAMにインポートと行きたいのですが、インポート前にXMLファイル内の最初のが余分なので削除しておきます。

以下を削除します。


メタデータの用意が出来たら、OpenAMの管理コンソールの[共通タスク]より[リモートサービスプロバイダを登録]をクリックし、先ほどのメタデータをベースにRP設定を行います。
以下を設定します。
・メタデータ:ファイル⇒先ほどのメタデータファイル(federationmetadata.xml)
・トラストサークル:先ほどIdP作成時に作ったCoT(MSO365)
・属性マッピング:表明内の名前⇒IDPEmail、ローカル属性名⇒mail



これでOpenAM側の設定は完了なので、OpenAMのIdP設定(IdPメタデータ)を出力しておきます。
以下のURLよりメタデータが取得できます。
http://:8080/OpenAM-11.0.0/saml2/jsp/exportmetadata.jsp?realm=/&entityid=http://:8080/OpenAM-11.0.0
※realmやポートなどは環境によって異なります。


次はこのIdPメタデータを使ってOffice365/AzureAD側の設定を行います。


◆Office365/AzureADのカスタムドメインの認証設定を行う

ここではOffice365で使うカスタムドメインの認証をOpenAMとのFederationで行う様に設定を行います。
※ドメインの追加はOffice365の管理ポータルからでもAzureの管理ポータルからでも構いません。
※カスタムドメインを追加する手順は省略します。

具体的には、PowerShellの「Set-MsolDomainAuthentication」コマンドレットに以下のパラメータを付けて設定をします。
※当然ですがコマンドレット実行前に「Connect-MsolService」でAzureADへ接続しておいてください。

パラメータ設定する値設定例
DomainNameカスタムドメイン名example.com
FederationBrandNameブランド名(任意の値)eIdentity
AuthenticationFederated固定Federated
PassiveLogOnUriIdPメタデータ内のタグ内のLocation属性の値
※Binding属性の値が「urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST」のもの
http://openam.example.com:8080/OpenAM-11.0.0/SSOPOST/metaAlias/idp
SigningCertificateIdPメタデータ内のタグの中身MIICQDCCAakCBEeNB0swDQYJ….
IssuerUriIdPメタデータ内のタグ内のentityID属性の値http://openam.example.com:8080/OpenAM-11.0.0
ActiveLogOnUriIdPメタデータ内のタグ内のLocation属性の値
※Binding属性の値が「urn:oasis:names:tc:SAML:2.0:bindings:SOAP」のもの
※httpsでないと設定できないのでhttpsで設定(ブラウザを使ったアクセスではこの設定は使わないので、ダミーのURLでもよいのでとにかくhttpsのURLを設定すればOK)
https://openam.example.com:8080/OpenAM-11.0.0/SSOSoap/metaAlias/idp
LogOffUriIdPメタデータ内のタグ内のLocation属性の値
※Binding属性の値が「urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect」のもの
http://openam.example.com:8080/OpenAM-11.0.0/IDPSloRedirect/metaAlias/idp
PreferredAuthenticationProtocol利用するID連携プロトコル(SAMLP)SAMLP


実際のコマンドは以下のように実行します。
$dom = "example.com"
$url = "http://openam.example.com:8080/OpenAM-11.0.0/SSOPOST/metaAlias/idp"
$cert = "MIICQDCCAakCBEeNB0swDQYJKoZIhvcNAQEEBQAwZzELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMQwwCgYDVQQKEwNTdW4xEDAOBgNVBAsTB09wZW5TU08xDTALBgNVBAMTBHRlc3QwHhcNMDgwMTE1MTkxOTM5WhcNMTgwMTEyMTkxOTM5WjBnMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExDDAKBgNVB.............Fcfu2/PeYoAdiDAcGy/F2Zuj8XJJpuQRSE6PtQqBuDEHjjmOQJ0rV/r8mO1ZCtHRhpZ5zYRjhRC9eCbjx9VrFax0JDC/FfwWigmrW0Y0Q=="
$entity = "http://openam.example.com:8080/OpenAM-11.0.0"
$ecp="https://openam.example.com:8080/OpenAM-11.0.0/SSOSoap/metaAlias/idp"
$logout = "http://openam.example.com:8080/OpenAM-11.0.0/IDPSloRedirect/metaAlias/idp"

Set-MsolDomainAuthentication -DomainName $dom -FederationBrandName eIdentity -Authentication Federated -PassiveLogOnUri $url -SigningCertificate $cert -IssuerUri $entity -ActiveLogOnUri $ecp -LogOffUri $logout -PreferredAuthenticationProtocol SAMLP



ちなみに設定結果は「Get-MsolDomainFederationSettings」コマンドレットで確認できます。




今回はここまでです。
次回はAzureAD上のユーザとOpenAM上のユーザの紐づけを行うためのプロビジョニング時の工夫について解説します。(単純に初期状態のディレクトリ同期だとImmutableIdでの紐づけがうまく行かないのでカスタマイズが一部必要になります)



2014年11月18日火曜日

[AADSync]フルパスワード同期を強制的に実行する

先日Azure Active Directory Synchronization Services(AADSync)にもパスワード同期機能が実装された、という話を書きました。
 http://idmlab.eidentity.jp/2014/11/aadsync.html

しかし、ディレクトリ同期ツール(DirSync)にあって、AADSyncにない機能があり、その一つがパスワードの強制同期機能です。

DirSyncではフォーラムのFAQに書かれているように'Set-FullPasswordSync'コマンドレットを実行してサービスを再起動すればパスワードの強制同期が出来ました。

 フォーラムURL:
  http://social.technet.microsoft.com/wiki/contents/articles/18096.dirsync-password-sync-frequently-asked-questions.aspx

 パスワードの強制同期方法(PowerShell)
Import-Module DirSync
Set-FullPasswordSync
Restart-Service FIMSynchronizationService



一方でAADSyncには先にポストしたPowerShellコマンドレット一覧を見ても'Set-FullPasswordSync'が見当たりません。

MSDNフォーラムで色々と情報を探していたんところ、MirosoftのMarkus VilcinskasがTechnet Wikiに書いてくれました。かなり強引な方法ですので、いずれちゃんとしたコマンドレットが用意される気がしますが。

 Technet Wiki - How to Use PowerShell to Trigger a Full Password Sync in Azure AD Sync
  http://social.technet.microsoft.com/wiki/contents/articles/28433.how-to-use-powershell-to-trigger-a-full-password-sync-in-azure-ad-sync.aspx

$adConnector  = "mydomain.local"
$aadConnector = "mytenant.onmicrosoft.com - AAD"

Import-Module ADSync
$c = Get-ADSyncConnector -Name $adConnector
$p = New-Object Microsoft.IdentityManagement.PowerShell.ObjectModel.ConfigurationParameter "MicrosoftSynchronize.ForceFullPasswordSync", String, ConnectorGlobal, $null, $null, $null
$p.Value = 1
$c.GlobalParameters.Remove($p.Name)
$c.GlobalParameters.Add($p)
$c = Add-ADSyncConnector -Connector $c
 
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $aadConnector -Enable $false
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $aadConnector -Enable $true



ちなみに各コネクタの名称はSynchronization Service Managerで確認できます。(TypeがActive Directory Domain ServicesとなっているものがオンプレミスADコネクタ、Windows Azure Active Directory (Microsoft)となっているの*.onmicrosoft.com -ADという名前のものがAzureADコネクタです)
さっそく実行してみると、イベントログにパスワード同期が実行されたことが記録されます。


基本的に2分に一回パスワードは同期されますし、ネットワーク障害などで更新が出来なかったときはリトライがされるので大きな問題になることは少ないとは思いますが、メンテナンス時など強制的に全同期をしておきたい時もあると思いますので、そのような際はこのコマンドを使えば良いですね。


2014年9月7日日曜日

続Azure ADのSAML対応(IdP編)~SP Initiatedに対応

前回のPOSTで現状Azure Active DirectoryのSAML IdP対応はIdP Initiatedだけ、という話をしましたが、直近(9/3)のアップデートでSP Initiatedに対応しました。

 TechnetのActive Directory Teamのブログ
 - 50+ SaaS Apps and growing now support federation with Azure AD!
  http://blogs.technet.com/b/ad/archive/2014/09/03/50-saas-apps-now-support-federation-with-azure-ad.aspx

ブログ本文の本筋はたくさんのSaaSアプリケーションがAzure ADとのフェデレーションに対応したよ、ということなんですが下の方にちょろっとSP Initiated対応!と書いてあります。
これでようやくアプリケーションポータルを経由しなくてもSaaSアプリを使うことが出来ます。

と、言うことで試してみます。
と言っても設定はこれまでと何ら変わりません。今回もGoogle Appsを使います。

①Azure ADの管理コンソールからGoogle Appsを追加し、構成を行います。

 まずはGoogle Appsのドメインを指定します。

 Google Appsに設定する情報が出てくるので、証明書のダウンロードします。


②Google Appsのセキュリティ設定からシングルサインオン設定を行います。
 先ほどダウンロードした証明書のアップロード、各種URLの設定を行います。
 この時、「ドメイン固有の発行元を使用」にチェックを入れておくことを忘れないようにしてください。(前回はこれを入れていなかったからダメだっただけかも知れません。。)

③Azure ADのコンソールでGoogle Appsを使うユーザを追加、選択します。
 ※アプリケーションの構成でプロビジョニングを有効にしておく必要があります。
 Google Appsと同じドメインをAzure ADにも追加し、対象のドメインにユーザを作り、割り当てを行います。


④Google AppsへアクセスするとAzure ADのサインイン画面へリダイレクトされるので、先ほど追加したユーザでサインインします。


すると、無事にGoogle Apps(今回はGmail)が利用できます。




同じようなやり方でカスタムアプリや他のサービスも使えると思いますので、エンタープライズにおける利活用の選択肢がだいぶ拡がったと思います。


2014年8月1日金曜日

Azure ADのSAML対応(IdP編)

## 本POST時点ではIdP-Initiated SSOしか対応していなかったAzure ADですが、現在はSP-Initiated SSOにも対応しています。詳細は続編で解説しています。

Azure Active DirectoryのIdentity Providerとしての機能について、先日の.NETラボ勉強会で話をしましたが、そういえば説明してなかったなぁ、、と思うのがSAMLの対応状況です。

当日の勉強会資料はこちら
 


実は、現状ではAzure ADをSAML IdPとして使う際はIdP起動(IdP Initiated)のユースケースしか対応していません。

つまり、例えばGoogle AppsのようなサービスとのID連携が出来るようになったと言っても、これまで@ITなどで紹介してきた様に、
①サービス(SP)へアクセス
②AzureAD(IdP)へリダイレクト
③認証後、サービスへ戻って利用開始
という流れではサービス利用が出来ない、ということです。

参考)クラウド・サービスと社内システムとのID連携
  第4回 Google AppsとのID基盤連携を実現する
  http://www.atmarkit.co.jp/ait/articles/1301/16/news122.html



実際にGoogle AppsをAzure ADで認証するように構成して、https://mail.google.com/a/<テナントドメイン>へアクセスすると以下のようなエラーが発生します。


Azure ADのアプリケーションアクセス権限はもちろん割り当てているのですが、何とも分かりにくいエラーが出ます。




通信をトレースしてみると、以下のような流れになっています。


①サービスへアクセス
 GET https://mail.google.com/a/<テナントドメイン>/ HTTP/1.1
 ⇒HTTP 302
  Azure ADへリダイレクト

②Azure ADへの認証要求
 GET https://login.windows.net/25461215-0c1f-4dc2-bffc-63e6e6f3f759/saml2?SAMLRequest=xxx&RelayState: https://www.google.com/a/<テナントドメイン>/ServiceLogin?service=mail&passive=true&rm=false&continue=https%3A%2F%2Fmail.google.com%2Fa%2F<テナントドメイン>%2F&ss=1&ltmpl=default&ltmplcache=2&emr=1 HTTP/1.1

 実際のSAML Requestは以下の通り
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                    ID="eafkldjajjdlncljdmnihogjokolljjfdooaboee"
                    Version="2.0"
                    IssueInstant="2014-07-31T14:34:01Z"
                    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                    ProviderName="google.com"
                    IsPassive="false"
                    AssertionConsumerServiceURL="https://www.google.com/a/domain/acs"
                    >
    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">google.com</saml:Issuer>
    <samlp:NameIDPolicy AllowCreate="true"
                        Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
                        />
</samlp:AuthnRequest>


 ⇒HTTP 302
  Azure ADの認証サービスへリダイレクト(ws-federationでID連携)

③login.microsoftonline.comへ認証要求
 GET https://login.microsoftonline.com/login.srf?wa=wsignin1.0&wreply=https%3a%2f%2flogin.windows.net%2f<テナントID>%2fwsfedisvacs&wp=MBI_FED_SSL&wctx=xxx HTTP/1.1

 ⇒ログイン画面表示

④ID/パスワードでログイン
 POST https://login.microsoftonline.com/ppsecure/post.srf?wa=wsignin1.0&wreply=https%3a%2f%2flogin.windows.net%2f<テナントID>%2fwsfedisvacs&wp=MBI_FED_SSL&wctx=xxx HTTP/1.1

⑤SAMLトークンを受け取り、Azure ADへPOST(ws-federationプロトコル)
 POST https://login.windows.net/<テナントID>/wsfedisvacs HTTP/1.1

 ⇒HTTP 400 Bad Request
  エラー!!先ほどの画面が表示される。



なかなか一筋縄ではいきません。
現状の解としてはアプリケーション・パネル(https://myapps.microsoft.com)からアプリケーションを立ち上げてIdP-InitiatedでID連携をすることとなります。

アプリケーション・パネル




ここからアプリケーション(Google Apps)を選択すると同じくSAMLを使ったID連携が行われて、サービスへログインできます。



このパターンの連携の流れは以下の通りです。

①アプリケーション・アイコンをクリック
 GET https://account.activedirectory.windowsazure.com/applications/redirecttofederatedapplication.aspx?Operation=SignIn&applicationId=<アプリケーションID>&ApplicationConstName=googleapps&SingleSignOnType=Federated&ApplicationDisplayName=Google+Apps HTTP/1.1

②SAML認証要求を発行
 GET https://login.windows.net/<テナントID>/saml2?SAMLRequest=xxxx&RelayState=https%3a%2f%2fwww.google.com%2fa%2facs%2fServiceLogin%3fservice%3dmail%26passive%3dtrue%26rm%3dfalse%26continue%3dhttps%253A%252F%252Fmail.google.com%252Fa%252Facs%252F%26ss%3d1%26ltmpl%3ddefault%26ltmplcache%3d2 HTTP/1.1

 この時のSAMLリクエストは以下の通り
<samlp:AuthnRequest xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
                    ID="ide478f3cb10e54fd2882a3c68d24cd34a"
                    Version="2.0"
                    IssueInstant="2014-07-31T15:07:18.210Z"
                    IsPassive="false"
                    AssertionConsumerServiceURL="https://www.google.com/a/domain/acs"
                    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                    >
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://google.com</Issuer>
    <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
</samlp:AuthnRequest>


③login.microsoftonline.comへ認証要求(シングルサインオン)
 GET https://login.microsoftonline.com/login.srf?wa=wsignin1.0&wreply=https%3a%2f%2flogin.windows.net%2f<テナントID>>%2fwsfedisvacs&wp=MBI_FED_SSL&wctx=xxx HTTP/1.1


④SAMLトークンをAzure ADへPOST(ws-federationプロトコル)
 POST https://login.windows.net/<テナントID>/wsfedisvacs HTTP/1.1


⑤SAMLトークンを発行し、Google AppsのACS(SP)へPOST
 POST https://www.google.com/a/<ドメイン>/acs HTTP/1.1

 POSTするSAML Responseは以下の通り
<samlp:Response ID="_cfa4d9a3-07f2-43b3-8721-ec009a314a42"
                Version="2.0"
                IssueInstant="2014-07-31T15:20:21.298Z"
                Destination="https://www.google.com/a/domain/acs"
                InResponseTo="ide478f3cb10e54fd2882a3c68d24cd34a"
                xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                >
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://sts.windows.net/tenant/</Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
            <ds:Reference URI="#_cfa4d9a3-07f2-43b3-8721-ec009a314a42">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                <ds:DigestValue>vldBy5BDCPN1SosH0pbBECXLspqjexOKf/CzGfvwhhA=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>SlEnVqcu--snip--cPDdkxuJMmg==</ds:SignatureValue>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
            <ds:X509Data>
                <ds:X509Certificate>MIIDPjC--snip--Lg4rOBcXWLAIarZ</ds:X509Certificate>
            </ds:X509Data>
        </KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </samlp:Status>
    <Assertion ID="_28c961d7-b93e-4c21-88d9-62977d2ce849"
               IssueInstant="2014-07-31T15:20:21.298Z"
               Version="2.0"
               xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
               >
        <Issuer>https://sts.windows.net/tenant/</Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
                <ds:Reference URI="#_28c961d7-b93e-4c21-88d9-62977d2ce849">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                    <ds:DigestValue>swSVM5OvOHWnGp105KYZbMer4xuiJ0O9knGGBP4g/Us=</ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>V2Sbe7Ww--snip--okg==</ds:SignatureValue>
            <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                <ds:X509Data>
                    <ds:X509Certificate>MIID--snip--arZ</ds:X509Certificate>
                </ds:X509Data>
            </KeyInfo>
        </ds:Signature>
        <Subject>
            <NameID>ieyasut@domain</NameID>
            <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <SubjectConfirmationData InResponseTo="ide478f3cb10e54fd2882a3c68d24cd34a"
NotOnOrAfter="2014-07-31T15:25:21.298Z"
Recipient="https://www.google.com/a/domain/acs"
/>
            </SubjectConfirmation>
        </Subject>
        <Conditions NotBefore="2014-07-31T15:20:21.005Z"
                    NotOnOrAfter="2014-07-31T16:30:21.005Z"
                    >
            <AudienceRestriction>
                <Audience>http://google.com</Audience>
            </AudienceRestriction>
        </Conditions>
        <AttributeStatement>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
                <AttributeValue>ieyasu</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
                <AttributeValue>tokugawa</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
                <AttributeValue>ieyasut@domain</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid">
                <AttributeValue>tenant</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
                <AttributeValue>4ce14587-d409-420e-82a2-7957867c6d20</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider">
                <AttributeValue>https://sts.windows.net/tenant/</AttributeValue>
            </Attribute>
        </AttributeStatement>
        <AuthnStatement AuthnInstant="2014-07-31T15:15:13.000Z"
                        SessionIndex="_28c961d7-b93e-4c21-88d9-62977d2ce849"
                        >
            <AuthnContext>
                <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
            </AuthnContext>
        </AuthnStatement>
    </Assertion>
</samlp:Response>



⑥Google Appsへのログイン処理(シングルサインオン)
 GET https://www.google.com/accounts/ContinueSignIn?sarp=1&continue=https%3A%2F%2Fmail.google.com%2Fa%2Facs%2F&plt=xxx&scc=0&service=mail HTTP/1.1

 ⇒Gmail画面の表示



いかがでしょうか?
単純にSAMLプロトコルに対応した、と言ってもどこまで対応しているかを知っておかないと利用イメージが違う、、という話になりかねないので、しっかりと押さえておかないといけませんね。

2014年5月21日水曜日

[AAD/ASP.NET] (続)OpenID Connectを使ってAADでログオンする~response_mode=fragment編

先日のポストの続きです。

前回はOWIN Security MiddlewareのOpenID Connectを使ってAzure Active Directory(AAD)でのログオンを行いました。
今回も基本的にやることは同じなのですが、OWINのOpenID Connectのresponse_modeの初期値がform_postなので、一般的なOpenID ConnectをサポートしたIdentity Providerへの流用の可能性を考えるために、Implicitフローで使われるfragmentを使ってid_tokenを受け渡す場合の工夫について試してみます。
※尚、現状AADではImplicitフローをサポートしているという表明があるわけではないので、今回紹介するのはあくまでImplicitもどきです。


■処理の流れとAADの場合
まず、OpenID ConnectにおけるImplicit Clientではどのような流れでid_tokenが発行されるのか?、AADではどうなるのか?についてみておきたいと思います。
 参考)OpenID Connect Implicit Client Implementer's Guide 1.0 - draft 15の日本語訳
    http://openid-foundation-japan.github.io/openid-connect-implicit-1_0.ja.html

大まかな流れは、以下のようになっています。

①Client は必要なリクエストパラメータを含んだ Authentication Request を構築する.
②Client は Authorization Server にリクエストを送信する.
③Authorization Server は End-User を認証する.
④Authorization Server は End-User の Consent/Authorization を取得する.
⑤Authorization Server は End-User を ID Token, およびもし要求されていれば Access Token とともに, Client に戻す.
⑥Client はそれらのトークンを検証し, End-User の Subject Identifier を取得する.


具体的には以下のような通信が行われます。

①~②クライアントからのAuthorizationリクエスト
https://server.example.com/authorize?
    response_type=id_token%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj


response_typeにid_tokenおよびtokenを付けて要求を投げる必要がある(REQUIRED)、というのが仕様です。
しかし、現状でAADはresponse_typeにtokenをサポートしていないので、id_tokenだけを要求することにします。また、前述の通り、AADではresponse_modeの初期値がform_postなので、Implicit(もどき)の場合はresponse_mode=fragmentをつける必要があります。

結果、以下のようなリクエストになります。
https://login.windows.net/{tenantid}/oauth2/authorize?
    response_type=id_token
    &response_mode=fragment
    &client_id=xxxxx
    &redirect_uri=https%3a%2f%2flocalhost%3a44307%2fAccount%2fFragment%2f
    &scope=openid+profile
    &state=yyyyy
    &nonce=zzzzz



③~④End-Userの認証、同意取得
この部分は仕様のスコープ外なので手段は問いません。
AADではws-federationを使ってhttps://login.microsoftonline.comへ認証要求を投げ、ユーザ認証を行います。
https://login.microsoftonline.com/login.srf?
    wa=wsignin1.0
    &wtrealm=https%3a%2f%2flogin.windows.net%2f
    &wreply=https%3a%2f%2flogin.windows.net%2f{tenantid}%2fwsfederation
    &wctx=xxxx
    &wp=MBI_FED_SSL
    &id=


認証が成功するとhttps://login.windows.net/{tenantid}/wsfederationに対してSAMLトークンがPOSTされ、認証結果およびユーザ情報が渡されます。


⑤id_tokenをクライアントへ返す
HTTP302でredirect_uriへ戻します。その際、フラグメント(#)にid_tokenなど要求されたトークンを付加します。
HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    access_token=SlAV32hkKG
    &token_type=bearer
    &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    &expires_in=3600
    &state=af0ifjsldkj


AADの場合は、先ほどのリクエストでtokenを要求できませんでしたので、id_tokenのみが返ってきます。
HTTP/1.1 302 Found
  Location: https://localhost:44307/Account/Fragment/#
    id_token=eyJ0....
    &state=yyyyy
    &session_state=zzzzz



⑥返ってきたid_tokenを検証する
id_tokenがフラグメントで返ってきますので、UserAgent(ブラウザ等)上でパラメータを解析してクライアントへ送ってあげる必要があります。通常はJavaScriptでlocation.hashを解析してクライアントへid_tokenなどをPOSTしてあげます。
今回もredirect_uriに指定したページ(https://localhost:44307/Account/Fragment/)へのGETリクエストすると以下のようなJavaScriptを含むHTMLを返すようにしています。(テストなのでベタ書きしています)
<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title></title>
</head>
<body>
    <form method="post" name="autopost" action="https://localhost:44307/">
        <script type="text/javascript">
            var params = location.hash.substring(1).split('&');
            var id_token = params[0].substring(9);
            var state = params[1].substring(6);
            var session_state = params[2].substring(14);

            document.write("<input type=hidden name=id_token value=");
            document.write(id_token);
            document.write(" />");
            document.write("<input type=hidden name=state value=");
            document.write(state);
            document.write(" />");
            document.write("<input type=hidden name=session_state value=");
            document.write(session_state);
            document.write(" />");
        </script>
        <input type="submit" value="Submit" />
    </form>
    <script language="javascript">window.setTimeout('document.forms[0].submit()', 0);</script>
</body>
</html>




結果、フラグメントでわたってきたid_tokenがOWINのOpenID Connect Middlewareが動いているASP.NETアプリケーション(https://localhost:44307)へPOSTされ、自動的にトークン検証~ユーザ情報の取り出しを行ってくれます。


ここまでのフローをざっとシーケンスにしたものが以下の図です。



■ASP.NET/OWINでの実装
デフォルトのASP.NET/OWIN Middlewareではフラグメントでわたってきたid_tokenをUserAgent側で解析してPOSTする部分が用意されていないので、その部分だけは作ってあげる必要があります。
具体的にはViewを一つ用意して、そのエンドポイントに対するGETがあった場合に先のJavaScriptを含むHTMLを返すようにします。

以下の手順で実装しました。

ソリューション・エクスプローラからAccount Controllerへ新規MVC5 Viewを追加します。先のシーケンスの中にも出てきたように、今回はエンドポイントの名前を「Fragment」としています。



新規作成されたfragment.chtmlに先のJavaScriptを含むHTMLを記載します。



次に、Account Controllerにアクションを定義します。AccountController.csに以下のコードを追記します。
[AllowAnonymous]
public ActionResult Fragment()
{
    return View();
}



また、OWINの認証設定部分(Startup.Auth.cs)に以下の設定を入れます。
・response_type:id_token
・response_mode:fragmentを指定
・redirect_uri:先に追加したView(Fragment)のエンドポイントを指定

app.UseOpenIdConnectAuthentication(
    new OpenIdConnectAuthenticationOptions()
    {
        Client_Id = "xxxxx",
        Authority = "https://login.windows.net/{tenant}.onmicrosoft.com",
        Response_Type = "id_token",
        Response_Mode = "fragment",
        Redirect_Uri = "https://localhost:44307/Account/Fragment/",
        Description = new Microsoft.Owin.Security.AuthenticationDescription()
        {
            Caption = "Azure Active Directory",
            AuthenticationType = OpenIdConnectAuthenticationDefaults.AuthenticationType
        }
    });



これで実行すると前回と同じような動きに見えますが、裏側ではImplicit(もどき)でid_tokenが受け渡されます。

2014年5月7日水曜日

[AAD/ASP.NET] OpenID Connectを使ってAADでログオンする

先日の#idcon vol.18でAzure Active Directory(AAD)のOpenID Connect対応について話をしました。
遅ればせながらフォローアップをしていきたいと思います。

当日の資料はこちらです。



概要としては、OpenID Connectに対応(Preview)したAADに対して、こちらもPreview公開されたOWINのOpenID Connectセキュリティ・ミドルウェアを使ってASP.NETのMVC5のWebアプリケーションで接続(ログイン)してみる、ということをやってみます。
また、その過程でAADのOpenID Connect対応の特異点となっているresponse_modeパラメータの動きについても解説していきます。

少々長くなりそうなので、

  • 今回)素直にOWIN/OpenID ConnectでAADを使ってログオンする方法
  • 次回)一般的なOpenID Connect OPが対応しているresponse_mode="fragment"の場合に必要な工夫

という2回でお伝えしていきます。
また、その後になると思いますが、AAD以外のOpenID Connect OPへOWIN/OpenID Connectを使って接続する例についても解説していければと思います。


■設定方法と基本的な動作
一旦、基本的な設定と動作について確認していきます。中身のプロトコルの解説を細かくする前にまずは動きをつかんでもらうことが目的です。

◇Webアプリケーションの作成(ASP.NET MVC5)
・Visual Studioを起動し、ASP.NET/MVC5のWebアプリケーションを新規に作成します。

・NuGetを使いMicrosoft.Owin.Security.OpenIdConnectをインストールします。
 現状プレビュー版のパッケージなのでリリース前のパッケージを含めて、「openidconnect」で検索すると出てきます。


・SSLを有効にします。
 これはAADに設定するアプリケーションにはHTTPSが必須なため必要な設定です。
 ソリューションエクスプローラでプロジェクトのプロパティを開き、[SSL有効]をTrueに設定します。結果、自動的にSSLのURLが生成されます。


 次に、メニューより[プロジェクト]を選び[プロパティ]を開き、WebメニューからプロジェクトのURLを先ほど割り当てられたSSLのURLを設定し、保存します。



◇AADにアプリケーションの登録
・AADの管理画面へアクセスしアプリケーションの新規作成を行います。
 以下の設定を行います。
 ・実行する作業:組織で開発中のアプリケーションを追加


 ・アプリケーション情報  名前:任意
  種類:WEBアプリケーションやWEB API


 ・アプリケーションのプロパティ  サインオンURL:先ほどVisual Studioで作成したアプリケーションのURL(HTTPS)
  アプリケーションID/URI:任意(テナント内で一意)


 作成が完了したら構成メニューより割り当てられたクライアントIDをコピーしておきます。



◇Webアプリケーションの実装
・コードを書きます。
 ソリューションエクスプローラから、App_Start\Startup.Auth.csを開き、以下を追記します。
 usingディレクティブ
using Microsoft.Owin.Security.OpenIdConnect;

 Startupクラス
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions()
{
   Client_Id = "AADに登録したアプリケーションのクライアントID",
   Authority = "https://login.windows.net/テナント名.onmicrosoft.com",
   Description = new Microsoft.Owin.Security.AuthenticationDescription()
   {
      Caption = "Azure Active Directory",
      AuthenticationType = OpenIdConnectAuthenticationDefaults.AuthenticationType
   }
});



 以上で準備は完了です。

◇Webアプリケーションの実行
・F5を押してアプリケーションを実行するとASP.NET MVC5のアプリケーションが起動しますので、右上のログインをクリックします。


・ログイン画面に遷移するので、右側に表示される[OpenIdConnect]をクリックします。


・AADのログイン画面に遷移するので組織のアカウントでログインします。


・ASP.NETアプリケーションにアカウントが存在しないので関連付けを行います。


 ちなみにこのアカウントはAspNetUsersテーブルに格納されますので、サーバエクスプローラから確認・編集ができます。

・ログインが完了し、ユーザ名が表示されます。



以上がとりあえず動くところまで、の手順です。
少ないコード量で実現できることがわかります。



■内部での通信シーケンスの解説
では、内部の動作について確認してみます。
細かく解説すると非常に面倒なフローなので、ざっくり解説すると以下の様になっています。

  1. AADの認可エンドポイントがws-federationのRPになっている
  2. 認証に関してはws-federationのSTSになっているhttps://login.microsoftonline.comで行われる(Federationされている)
  3. 認証が完了するとcodeとid_tokenが払い出される
  4. codeとid_tokenはUserAgent(ブラウザ)を経由し、HTTP POSTでclient(Webアプリケーション)へ渡される


この4番目のcodeやid_tokenのクライアントへの渡し方がOpenID Connectのresponse_modeというパラメータで決まってくるのですが、この流れを見るとAAD/OWINではform_postというタイプを使っていることがわかります。この部分がAADの特徴的な部分となっているので後ほど解説します。

以下が通信シーケンスの全体像です。




■response_modeとは
OpenID Connectの仕様を見ると本パラメータは以下の様に定義されています。

OPTIONAL. Authorization Endpoint からパラメータを返すために Authorization Server が使用する方法を通知する. 要求されるレスポンスモードがレスポンスタイプで指定されるデフォルトモードである場合, このパラメータの使用は推奨されない (NOT RECOMMENDED).
参考)http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html


OpenID Connectにおいて、id_tokenをクライアント(Webアプリケーション)へ渡す方法は、Authorization Codeフローではcodeと引き換えにresponse bodyで、Implicitフローではフラグメント(URLの後の#以下)でというのが標準的?です。
しかし、先の通信シーケンスをみるとわかるようにAAD/OWINではid_tokenをJavaScriptで自動的にクライアントへPOSTするようなフォームを含むHTMLをUserAgentへ返すことで、id_tokenをクライアントへ渡しています。この方法(response_mode)をform_postと呼びます。
現状、AADにおけるresponse_modeはこのデフォルトのform_postおよびfragment(Implicitで使われる)およびquery(GETパラメータで渡す)の3つがサポートされます。
一般的にサーバサイドでパラメータの横取りをすることが出来ないfragmentを使ってtokenを渡すのが基本なのですがOAuthにおけるaccess_tokenのようにBearer Token(トークンを持っている人なら認可する)ではなくHok Token(トークンを持っている人が本当に持ち主なのかを確認してから認可する)であるOpenID Connectのid_tokenならそこまで気を遣わなくても大丈夫、という考え方なのかも知れません。
また、これは#idconでも話したように推測でしかないのですが、これまでASP.NETがサポートしてきたws-federationやSAML-Pなどのプロトコルと同じ動きをさせることでミドルウェアの実装を簡素化する、というのが真相なのかも知れません。(ws-federationやSAML-PではSAMLトークンをUserAgentを経由してRPへPOSTして渡すのが最近の主流なので)


ただ、現在のOWINの実装では他のOpenID Connect OP(現状あまりresponse_mode自体をサポートしているOPが少なく、かつform_postをサポートしているところはほぼない)との相互接続に問題が起きやすいので、response_mode="fragment"で構成されたOPをASP.NET/OWINで使う場合にどうすれば良いのか、について次回解説したいと思います。


2014年4月24日木曜日

[AAD/Office365]AAD Sync(次世代ディレクトリ同期)でクラウドのパスワードをオンプレミスへ

Office365を使う場合のシナリオは大きくは以下に分類されます。

パターン認証ID管理
クラウドのアイデンティティを使うAzure ADAzure AD
オンプレミス連携①Windows Server ADなどディレクトリ同期など
オンプレミス連携②Azure ADディレクトリ同期など

3番目のパターンにおいても最近のディレクトリ同期ツールではオンプレミスのActive Directory上のパスワード(のハッシュ)をAzure ADへ同期することが出来るようになっており、シングルサインオンではないもののユーザは同じパスワードでOffice365/Azure ADを使うことが出来るようになっていました。(SSO - Same Sign Onなんて言ったりします)

先日紹介した次期ディレクトリ同期ツールであるAAD Syncを使うと今度はクラウド(Azure AD)上のパスワードをオンプレミスのActive Directoryへ同期することが出来るようになります。

メリットは、Windows Server Active Directoryが標準では持っていないセルフサービス・パスワード・リセットがAzure ADでは使えるので、パスワードを忘れた人はAzure ADでパスワードをリセットすればオンプレミスのパスワードもリセットされる、という点でしょうか。

Technetに続々と情報が上がってきているので継続的にウォッチが必要そうです。
 http://social.technet.microsoft.com/wiki/contents/articles/tags/AADSync/default.aspx

2014年4月18日金曜日

[AAD/Office365]エンタープライズ環境で使う上での課題への対応が続々と

これまでOffice365をエンタープライズで展開する際に課題になっていたのは大きくは以下の点だと思います。

①ドメイン名の問題
 AD FSを使ってFederationをする際、Office365で使うドメイン名とオンプレミスのActive Directoryが使っているドメイン名を合わせる必要がありました。そのため、.localドメインなど内部専用ドメインを使っている企業ではUPN(User Principal Name)を変更する、など結構大きな対応をする必要がありました。

②社内ドメインのフォレスト・ドメイン構成の問題
 現状のディレクトリ同期ツールではマルチフォレスト環境での同期はできませんでした。これまでは同期専用のドメインを新しく作って対応したり、と同じくこちらも大手術が必要になる場合がありました。


ここ最近の対応でそれらの問題に対して少しずつ解が提供されてきています。
まず①のドメイン名の問題です。


①Windows Server 2012 R2 update 1でのAlternative Login IDのサポート

 UPNを変更する代わりに別のログインIDを使ってAD FSへログインできるようになっています。
 詳しくはこちら
  http://support.microsoft.com/kb/2927690/ja


次にフォレスト構成の問題です。

②Azure Active Directory Premium+Forefront Identity ManagerもしくはAAD Syncの利用

 先日のポストでも書いたように、Azure Active Directory Premiumが先日の//Build 2014で発表され、Premiumの特典となっているFIM(Forefront Identity Manager)を使ってインテグレーションを行えばかなり柔軟に対応できます。
 加えてディレクトリ同期ツールの後継となるAAD Sync(Azure Active Directory Sync)のCTP版が公開されています。
 技術ドキュメントを含めこちらのサイトで公開されています。(ダウンロードするにはconnectサイトへの登録が必要)
  http://www.aadsync.com/

 今回公開されたAAD Syncを使えばFIMをゼロから構築しなくても、あらかじめ設定された状態でマルチフォレスト環境であってもディレクトリ同期が出来るようになります。


他にもHybrid Identity Managementというキーワードで続々と情報が出てきそうなので継続的にウォッチが必要そうです。
 Hybrid Identity Management
  http://www.microsoft.com/en-us/server-cloud/solutions/identity-management.aspx#fbid=qWbiPt7PEDF

2014年3月30日日曜日

[AAD+FIM2010]Azure Active Directory Premiumの正式リリースとプロビジョニング界のエコシステムの崩壊?

Windows Azure Active Directory(WAAD)あらためMicrosoft Azure Active Directory(MAAD?最近はAADで通じるっぽい)のPremiumが4月に正式リリース(GA)を迎える、ということがActive Directory Teamのblogでアナウンスされました。

Cloud based Identity and Access Management for every user on every device
 http://blogs.technet.com/b/ad/archive/2014/03/25/identity-and-access-management-for-every-user-in-every-organization-using-any-service-on-any-device.aspx


来週からのBuild(4/2-4/4)で発表されるんですかね。

blogの内容を見ると、AAD PremiumにはForefront Identity Manager(FIM)のサーバライセンスとCALが含まれるそうなので、マルチフォレストシナリオでのディレクトリ同期やオンプレミスのActive Directory以外をデータソースとしたID管理などの複雑な構成がとれるようになります。



これはエンタープライズID管理(特にプロビジョニング)市場にとって非常に大きなインパクトを持つ可能性があると考えています。エンタープライズシナリオでOffice365とか使おうと思ったら今後はAAD Premium+FIMっていうのがコスト的にも非常に優位なソリューションになる可能性がありますので、これまでAAD/Office365のディレクトリ同期ツールで足りない部分はサードパーティを、というエコシステムが成り立ってきましたが、今後すこしバランスが崩れる可能性があるのでは?と思います。


最後に、改めてですが今回正式リリースとなるAAD Premiumの機能は以下の通りです。
他にもPreview中の機能が複数あり、今後も強化されていくようです。

全体的な特徴

  • 99.9%のSLA
  • ディレクトリ内のオブジェクト数に制限なし

機能
  • アプリケーションアクセス管理
    • Google AppsやsalesforceなどへのSSO/プロビジョニングを提供、アプリケーションポータル(アクセスパネル)からアプリケーションの利用
  • セルフサービス・パスワードリセット
    • ユーザ自身によるパスワードリセット
  • セルフサービス・グループ管理
    • ユーザ自身によるグループの作成やグループへの参加登録
  • 多要素認証
    • 追加のソフトウェアやハードウェアなしでの多要素認証の提供
  • ブランドのカスタマイズ
    • ログイン画面やアクセスパネルなどの画面カスタマイズ
  • レポーティング、警告と分析
    • アクセス元ネットワークの解析や利用状況のレポート


2014年3月2日日曜日

祝!OpenID Connect ローンチ

遅ればせながら。OpenID Connectが2/27にローンチされました。

米OpenID Foundationを牽引してこられた崎村さんの6年に及ぶ努力が実を結んだ瞬間だったと思います。本当におめでとうございます。
 OpenID Connect リリース~インターネットのアイデンティティ層
 http://www.sakimura.org/2014/02/2277/

 OpenID Foundationが、パーソナルデータ流通時代を支えるアイデンティティAPI標準仕様「OpenID Connect」を発表
 http://www.openid.or.jp/news/2014/02/openid-connect-standard.html

このblogでもお伝えしてきたようにMicrosoftもWindows Azure Active DirectoryでOpenID Connect / OAuth をサポートしていますし、先日のVittorio Bertocci氏へのインタビューでも触れたOWIN(Open Web Interface for .NET)でもそれらの技術を利用できる様になっています。
 [WAAD] OpenID Connect Interop 5
 http://idmlab.eidentity.jp/2013/11/waad-openid-connect-interop-5.html

 [WAAD] OAuth2.0 への対応状況まとめ&ちょこっと OpenID Connect
 http://idmlab.eidentity.jp/2013/07/waad-oauth20-openid-connect.html

 開発者にとってのWindows Azure Active Directoryの役割と今後の展開
 http://www.buildinsider.net/enterprise/interviewvittorio/01

 OWIN(Open Web Interface for .NET)
 http://owin.org/


また、OpenIDファウンデーションジャパンの公式リリースでも触れられているように翻訳/教育ワーキンググループでOpenID Connectの仕様(実装ガイド)を翻訳しています。
- Basic Client
 http://openid-foundation-japan.github.io/openid-connect-basic-1_0.ja.html
- Implicit Client
 http://openid-foundation-japan.github.io/openid-connect-implicit-1_0.ja.html

私もImplicit側で少しだけお手伝いをさせていただきましたので、仕様を見てみたい、という方はぜひご覧ください。

ちなみに。
インターネットに関するプロトコルとか技術って全部アメリカからの輸入品だと思っていませんか?
少なくともIdentityに関しては日本は先進国であり、グローバルスタンダードを牽引している存在だと堂々と言えるんじゃないかな、と思えたのが今回の発表でした。
(少なくとも関わっている人たちは既に国境にとらわれていない方ばっかりですがw)