このページは役に立ちましたか。
このページのコンテンツについての ご意見をお待ちしております
その他にご意見はありますか。
残り 1500 文字
エクスポート (0) 印刷
すべて展開

リリース ノート

発行: 2011年4月

更新日: 2015年6月

適用対象: Azure

このトピックでは、Microsoft Azure Active Directory アクセス制御 (アクセス制御サービスまたは ACS) の各リリースの新機能および各リリースにおける前リリースとの相違を説明し、さらに以前のリリースで記述したコードに影響する可能性のある最新の変更について取り上げます。

ACS では、ACS 名前空間の所有者が Google ID プロバイダーの構成を OpenID 2.0 から OpenID Connect へ移行するときに利用できる機能が実装されました。顧客は、2015 年 6 月 1 日までに ACS 名前空間を OpenID Connect へ移行し、OpenID Connect の識別子を使用するために、2017 年 1 月 1 日までにバックエンド コードを移行する必要があります。 それぞれの期限までに適切なアクションを実行できなければ、アプリケーションが中断されることになります。詳しい説明については、「ACS 名前空間の Google OpenID Connect への移行」を参照してください。

2014 年 5 月 19 日現在、新しい ACS 名前空間では ID プロバイダーとして Google を使用することはできません。2014 年 5 月 19 日より前に Google を使用していた登録済みの ACS 名前空間には影響はありません。この新しい制限が課せられるのは、Google が ACS の基礎となる OpenID 2.0 のサポートをしだいに減らし、新しいアプリケーションの登録を終了したためです。Google を使用した既存の ACS 名前空間は、2015 年 4 月 20 日まで引き続き動作します。アプリケーションが Google アカウントをサポートする必要がある場合には、アプリケーションをそれらに直接登録することをお勧めします。

ユーザーが Google アカウントを使用して新しい ACS 名前空間にサインインしようとすると、HTTP 400 エラー ページにリダイレクトされます。

新しい ACS 名前空間と Google のエラー

すべてのユーザーに対して可用性とパフォーマンスを高めるために、ACS は名前空間ごとに 1 秒あたり 30 トークン要求の制限を実装しました。名前空間が長期にわたりこの制限を越えた場合、ACS は一定期間その名前空間からのトークン要求を拒否し、HTTP 429 / ACS90055 "Too many requests" エラーを返します。詳細については、「ACS サービスの制限事項」および「ACS エラー コード」を参照してください。

新機能

ACS の 2012 年 12 月の更新プログラムには、次の新機能が含まれています。

WS-Federation プロトコルを使用したフェデレーション シングル サインアウトのサポート

ACS を使用して、WS-Federation プロトコルを使用する ID プロバイダーへのシングル サインオン (SSO) を有効にする Web アプリケーションは、シングル サインアウト機能を活用できます。ユーザーが Web アプリケーションをサインアウトすると、ACS は自動的にユーザーを ID プロバイダーと、同じ ID プロバイダーを使用する他の証明書利用者アプリケーションからサインアウトします。

この機能は、Active Directory フェデレーション サービス 2.0 および Windows Live ID (Microsoft アカウント) を含む WS-Federation ID プロバイダーの場合に有効です。シングル サインアウトを有効にするため、ACS は WS-Federation プロトコル エンドポイントで次のタスクを実行します。

  • ACS は ID プロバイダーからの wsignoutcleanup1.0 メッセージを認識し、証明書利用者アプリケーションに wsignoutcleanup1.0 メッセージを送信することで応答します。

  • ACS は、証明書利用者アプリケーションからの wsignout1.0 および wreply メッセージを認識し、wsignout1.0 メッセージを ID プロバイダーに送信して、wsignoutcleanup1.0 メッセージを証明書利用者アプリケーションに送信することで応答します。

詳細については、「コード サンプル:ASP.NET MVC 4 でのフェデレーション サインアウト」および「Passive Authentication for ASP.NET in WIF (WIF での ASP.NET のパッシブ認証)」を参照してください。

ACS 1.0 のサポート停止

アクセス制御サービス 1.0 のサポートは、アクセス制御サービス 1.0 からアクセス制御サービス 2.0 の移行のサポートを含め、このリリースで終了します。

新しい Azure の管理ポータルでの アクセス制御名前空間 への移動

新しい Azure の管理ポータル (http://manage.WindowsAzure.com) には、アクセス制御名前空間を作成および管理する使い慣れた ACS 管理ツールへのルートが含まれています。

ACS 管理ポータルに移動するには、

  1. Microsoft Azure 管理ポータル (https://manage.WindowsAzure.com) に移動してサインインし、[Active Directory] をクリックします。(トラブルシューティングのヒント:"Active Directory" 項目が見つからないか、使用できません)

  2. アクセス制御名前空間、[管理] の順にクリックします。

アクセス制御名前空間を作成するには、[新規] をクリックして [App サービス] をクリックし、[アクセス制御] をクリックしてから [簡易作成] をクリックします。または、[アクセス制御名前空間][新規] を順にクリックします。

Microsoft Azure 管理ポータルでの ACS 管理タスクの詳細については、[Active Directory] をクリックし、[ヘルプ (?)] をクリックしてご覧ください。または、[Active Directory][アクセス制御名前空間][ヘルプ] を順にクリックします。

サービス バスの アクセス制御名前空間への移動

でサービス バス名前空間を作成すると、ポータルは自動的にサービス バスの アクセス制御名前空間を作成します。

サービス バスの アクセス制御名前空間を構成および管理するには、次の手順を実行します。

  1. Azure 管理ポータルにログインします。

  2. [サービス バス] をクリックし、サービス バスを選択します。

  3. [アクセス キー] をクリックし、[ACS 管理ポータルを開く] をクリックします。

アクセス制御名前空間がサービス バスに関連付けられていることを検証するには、[アクセス制御サービス] ページの上部にある "サービスの名前空間" フィールドを確認します。名前空間名は、サービス バス名とサフィックス "-sb" で構成されます。

詳細については、「方法:Service Bus の Access Control 名前空間を管理する」を参照してください。

WS-Federation ID プロバイダー キーを表示し、パスワードを非表示にする ACS 管理ポータルの拡張機能

このリリースには、ACS 2.0 管理ポータルでの証明書、キー、およびパスワードの表示と操作に関連する 1 組の拡張機能が含まれています。

  • 署名証明書を [WS-Federation ID プロバイダーの編集] セクションで表示可能 – 以前は、ID プロバイダーから発行されたトークンの書名を検証するために使用された WS-Federation メタデータからインポートされた証明書は、ACS 管理ポータルで表示できませんでした。現在、[WS-Federation ID プロバイダーの編集] セクションに、有効期限やステータスを含め、インポートされた証明書に関する情報が表示されます。これらの証明書は、今では、新しい [保存時に WS-Federation メタデータ URL からのデータを再インポートする] チェックボックスを使用して更新できます。

  • パスワードと対称署名キーが既定で非表示 – パスワードおよび対称キーが意図せず開示されるのを防ぐために、これらの値は現在、ポータル全体を通じて編集画面では既定で非表示となっています。パスワードまたは対称キーの値を意図的に表示するには (たとえば、アプリケーションへのコピーを可能にするため)、[パスワードの表示] または [キーの表示] をクリックする必要があります。

Directory テナントと アクセス制御名前空間をフェデレーションする機能

Azure Active Directory テナントは、現在、アクセス制御名前空間内で ID プロバイダーとして使用できます。これは、Web アプリケーションによる、Directory テナントからの組織 ID と、Facebook、Google、Yahoo!、Microsoft アカウント、他の任意の OpenID プロバイダーなどのソーシャル プロバイダーからのコンシューマー ID の両方の受け入れを可能にするなどのシナリオを実現します。この投稿のシナリオを実装する方法の詳細な手順については、「Provisioning an Azure Active Directory Tenant as an Identity Provider in an ACS Namespace (ACS 名前空間における ID プロバイダーとしての Azure Active Directory テナントのプロビジョニング)」を参照してください。

証明書利用者アプリケーションの SAML 2.0 プロトコル サポート (Developer Preview)

ACS は、現在、証明書利用者アプリケーションへのトークンの発行用として SAML 2.0 プロトコルをサポートしています。SAML 2.0 プロトコルのサポート機能は開発者プレビューとしてリリースされています。つまり、SAML 2.0 プロトコル実装の詳細は変更される可能性があります。詳細については、「開発者プレビュー:SAMLProtocol」を参照してください。

既知の問題

2012 年 12 月の Microsoft Azure Active Directory アクセス制御 (アクセス制御サービスまたは ACS) 更新プログラムでは、次の既知の問題が特定されています。

Azure 共同管理者は、現在、アクセス制御名前空間を管理できます。ただし、既存の共同管理者を既存の アクセス制御名前空間に反映するための操作が必要です。

2012 年 11 月の更新プログラムより前に、既定ではプライマリ Azure サービス管理者しかサブスクリプションで作成された アクセス制御名前空間を管理できないという問題は解決されました。Azure 共同管理者が アクセス制御名前空間の ACS 管理ポータルへのアクセスしようとすると、次の ACS エラー コードのいずれかが示されました。

  • ACS50000:トークン発行時にエラーが発生しました。

  • ACS60000:発行者 "uri:WindowsLiveID "を使用して証明書利用者のルールを処理中にエラーが発生しました。

  • ACS60001:ルールの処理中に出力方向の要求が生成されませんでした。

この問題は、Azure サービス管理者または共同管理者によって作成された新しい アクセス制御名前空間では解決されました。ただし、修正前から既存の名前空間を使用しているお客様は、共同管理者データをそれらの名前空間に反映するために、次の回避策を実行する必要があります。

  1. サービス管理者またはアカウント管理者の資格情報を使用して Azure ポータル (https://windows.azure.com/) にサインインします。

  2. Azure サブスクリプションへの共同管理者の追加」 (http://msdn.microsoft.com/en-us/library/windowsazure/gg456328.aspx) のガイダンスに従って、共同管理者を削除し、再度追加します。

  3. Azure ポータルをサインアウトし、共同管理者の資格情報を使用して Azure ポータルにサインインします。その後、アクセス制御名前空間を管理できます。

2012 年 9 月に、次の変更を含む Microsoft Azure Active Directory アクセス制御 (アクセス制御サービスまたは ACS) の更新プログラムが配信されました。

ACS によって作成された WS-Federation メタデータで発行されたエンティティ ID は、現在、常に小文字である

アクセス制御名前空間によって発行された WS-Federation メタデータの "entityID" 属性は、現在、常に小文字です。以前のリリースでは、Azure ポータルで名前空間が作成されたときに入力された文字が使用されていました。"entityID" 属性は証明書利用者アプリケーションに対して アクセス制御名前空間を識別します。属性の例を以下に示します。

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://lowercase-namespace.accesscontrol.windows.net/" ID="_e4a0006c-c23c-41c0-8f87-baa110afaf1d">

この変更は、ACS が発行したトークン内の アクセス制御名前空間の文字 (常に小文字) が証明書利用者によってインポートされた アクセス制御名前空間の文字と一致しないという潜在するトークン検証問題を解決するために必要でした。Windows Identity Foundation を使用している証明書利用者には、大文字小文字の区別の問題による影響はありません。

ACS にアップロードされた X.509 証明書の公開キー サイズが 4096 ビットに制限された

ACS 管理ポータルまたは管理サービスを介して アクセス制御名前空間にアップロードされた X.509 証明書はすべて、公開キー サイズを 4096 ビット以下にする必要があります。これには、トークンの署名、トークンの暗号化、トークンの暗号化解除に使用される証明書が含まれます。

Windows では、証明書の公開キーのサイズは、証明書 (.CER) ファイルを開くか、[詳細] タブをクリックして "公開キー" フィールドの値をチェックすることで確認できます。セキュリティで保護された sha256RSA 署名アルゴリズムを使用する証明書では、公開キーは 2048 ビットです。

4096 ビットを超えるキーを持つ既存の証明書は、引き続き ACS で動作しますが、これらの証明書は、準拠している証明書と置き換えるまで、ACS で再度保存することはできません。

ACS が X.509 証明書を使用してトークンに署名する際の "プライマリ キー" 選択アルゴリズムへのマイナーな変更

ACS 管理ポータルおよび管理サービスには、トークン署名証明書の "プライマリにする" フィールドがあり、これが選択されている場合、ACS はその証明書を使用してトークンに署名します。このリリースでは、"プライマリにする" フィールドが選択されたトークン署名証明書が構成されていない場合、アクセス制御名前空間はトークンに署名するための有効な開始日が最も早い既存のプライマリ以外のトークン署名証明書を使用します。プライマリ証明書が存在するが、無効であるか期限切れの場合、ACS はプライマリ以外のトークン署名証明書を使用してトークンに署名しません。

JWT ベータ版:グローバル名前空間証明書またはキーを使用して JWT トークンに署名した場合の署名動作の変更

2012 年 6 月に JSON Web Token (JWT) 形式のサポート機能のベータ版がリリースされたときに、ACS は次の優先順位で、各証明書利用者アプリケーションに発行された各 JWT トークンに署名するためにどのキーを使用する必要があるかを判別していました。

  • 証明書利用者に割り当てられた対称署名キー (使用可能な場合)

  • 証明書利用者に割り当てられた X.509 署名証明書 (使用可能な場合)

  • アクセス制御名前空間に割り当てられた対称署名キー

  • アクセス制御名前空間に割り当てられた X.509 署名証明書

このリリースの時点では、JWT トークンの署名用に名前空間全体の対称キーはサポートされません。以下に、JWT トークンに署名するための新しい優先順位を示します。

  • 証明書利用者に割り当てられた対称署名キー (使用可能な場合)

  • 証明書利用者に割り当てられた X.509 署名証明書 (使用可能な場合)

  • アクセス制御名前空間に割り当てられた X.509 署名証明書

2012 年 6 月に、次の新機能を含む ACS の更新プログラムが配信されました。

JWT 形式が証明書利用者アプリケーションに対応 (ベータ版)

この更新プログラムでは、ACS での JSON Web Token (JWT) 形式のサポート機能 (ベータ版) が導入されました。JWT は、X.509 証明書または対称キーを使用して署名できる軽量な JSON エンコード トークン形式で、ACS によって次のいずれかのプロトコルを使用して証明書利用者アプリケーションへ発行できます。

  • OAuth 2.0

  • WS-Federation

  • WS-Trust

JWT トークン形式は、現在、ACS 管理ポータルの [証明書利用者アプリケーション] セクションで選択可能なオプションであり、ACS の管理サービスを介して構成することもできます。

JWT トークン形式の詳細については、「JSON Web Token specification (JSON Web トークンの仕様)」を参照してください。JWT トークンの特長を示す ACS コード サンプルは間もなく公開予定です。

Important重要
JWT サポート機能は ACS ではベータ版です。つまり、JWT 実装の詳細はすべて変更される可能性があります。開発者は、このトークン形式を試してみることをお勧めします。ただし、動作が予告なく変更される可能性があるため、JWT は運用サービスでは使用しないでください。

2012 年 5 月初期に、次の変更を含む ACS の更新プログラムが配信されました。

管理サービスを介して公開されるエンティティ ID プロパティへの変更

ACS 管理サービスは、現在、「ACS 管理サービス API リファレンス」で説明されているとおり、サポートするエンティティの種類ごとに ID プロパティを公開しています。これらの ID プロパティは、ACS によって自動的に設定および管理されます。

このサービス更新プログラムでは、ACS は異なるデータベース スキーマに移行され、その結果、管理サービスを介して公開されるこれらの ID はすべてのエンティティの種類について変更されます。

管理サービスを介して特定のエンティティをクエリするために、これらの ID にハードコードされた依存関係を格納または取り込むことはまれで、一般にお勧めしません。代わりに、RelyingParty、ServiceIdentity、RuleGroup、Issuer のエンティティの種類では名前プロパティを使用してクエリし、他のエンティティの種類では親エンティティ ID (ルールの場合は RuleGroupId、ID プロバイダーの場合は IssuerId など) を使用してクエリすることをお勧めします。

ルール処理のためのデータベース照合順序の変更

国際語のサポートを拡張し、セキュリティを改善するために、このリリースの ACS では、入力方向の要求を比較するために使用する基本となる SQL Database 照合順序を SQL_Latin1_General_CP1_CI_AS から Latin1_General_100_BIN2 へ更新しました。この変更によって、ACS は追加の文字セットと、文字セットの組み合わせをサポートできます。複数の文字セットを使用した文字列を含む入力方向の要求に依存しているアプリケーションは、SQL_Latin1_General_CP1_CI_AS によってサポートされず、異なる要求や追加の要求をこの新しい照合順序の結果と見なす可能性があります。この新機能の利用を希望するお客様は、お使いのアプリケーションに新しい SQL 照合順序との互換性があるか検証することをお勧めします。

2012 年 1 月 25 日に、次の変更を含む ACS 2.0 の更新プログラムが配信されました。

以前のリリースでは、ACS は、存在しない発行者 (エラー コード:ACS50026) または不適切な資格情報 (エラー コード:ACS50006) でのクライアントの認証時にさまざまなエラー コードで応答しました。以前は、これらのエラー コードは、クライアントが無効なサービス ID 名、または無効な ID プロバイダーから発行された SWT または SAML トークンを使用して認証を試みたときに作成されました。

ACS は、SWT、SAML、およびユーザー名/パスワードが原因で認証が失敗した場合に、それぞれ、エラー コード ACS50008、ACS50009、ACS50012 を返します。詳細については、以下の表を参照してください。

 

認証の応答 以前 これらの手順の完了後、

存在しない発行者

ACS50026 IssuerNotFound

ACS50008 InvalidSwt、

ACS50009 InvalidSaml、または

ACS50012 AuthenticationFailed

間違った資格情報

ACS50006 InvalidSignature

以前のリリースでは、ACS は、存在しない発行者 (invalid_client) または間違った資格情報 (invalid_grant) でクライアントが認証されたときに別の OAuth 2.0 エラー コードで応答していました。この動作も更新され、ACS は、OAuth 2.0 要求の形式が正しくない場合は invalid_request を返し、クライアントが認証に失敗したか、認証に提示されたアサーションが間違った形式または無効である場合には invalid_client を返します。さらに、承認コードが間違った形式または無効な場合には invalid_grant を返します。詳細については、以下の表を参照してください。

 

認証の応答 使用例 以前 これらの手順の完了後、

存在しない発行者

invalid_client

invalid_client

間違った資格情報

SWT は間違ったキーで署名されます。クライアント ID と資格情報は、ACS に構成されたものと一致します。

invalid_grant

認証に失敗

対象ユーザー URI の検証に失敗しました。証明書の検証に失敗しました。サービス ID からのアサーションに自己署名付き要求が含まれています。

invalid_grant

間違った形式のアサーション

SWT に署名が見つかりません。SAML アサーションは有効な XML ではありません。

invalid_request

間違った形式の承認コード

invalid_grant

invalid_grant

無効な承認コード

invalid_grant

間違った形式の OAuth2 要求

invalid_request

invalid_request

2011 年 7 月の ACS 2.0 の更新プログラムのリリース ノートには、次の項目が含まれています。

すべての アクセス制御名前空間は 2011 年 7 月の更新プログラムを自動的に受信します。この更新プログラムでは、新規または既存のお客様に対して、ACS の前提条件について変更はありません。現在の ACS の前提条件の詳細については、「ACS の前提条件」を参照してください。

ACS の 2011 年 7 月の更新プログラムには、次の新機能が含まれています。

1. ルールが最大 2 つの入力方向の要求をサポートする

ACS ルール エンジンは、現在、1 つの入力方向の要求だけでなく、最大 2 つの入力方向の要求を構成できる新しい種類のルールをサポートしています。2 つの入力方向の要求を処理するルールは、複雑なユーザー承認機能を実行するために必要なルールの総数を削減するために使用できます。

ACS 管理ポータルでは、ルール エディターで [2 番目の入力方向の要求を追加] をクリックすることで、2 番目の入力方向の要求を新しいルールに指定できます。管理サービスでは、2 つの入力方向の要求を処理するルールは、ConditionalRule エンティティの種類を使用して構成できます。1 つの入力方向の要求を処理するルールは、下位互換性を維持するために、引き続き Rule エンティティの種類を使用して構成できます。

2 つの入力方向の要求を処理するルールの詳細については、「規則グループと規則」を参照してください。

2. 11 言語でのローカライズ

ACS 管理ポータルと証明書利用者アプリケーションに対応する ACS でホストされたログイン ページは、現在、英語、フランス語、ドイツ語、イタリア語、日本語、韓国語、ロシア語、スペイン語、ポルトガル語 (ブラジル)、簡体字中国語、繁体字中国語を含む 11 の記述言語でローカライズされています。キーの実効日および有効期限を設定し表示するための代替日付形式を使用する [英語 (インターナショナル)] オプションも使用できます。これらのユーザー インターフェイスに表示される記述言語は、次の 3 とおりの方法のいずれかで変更できます。

  • 言語セレクター – ACS 管理ポータルでは、ポータルの右上隅にある新しい言語セレクター メニューを使用して、表示される言語を瞬時に変更できます。

  • URL – ACS 管理ポータルで表示される言語は、要求 URL の末尾に "lang" パラメーターを追加することで変更できます。このパラメーターに指定可能な値は、サポートされる言語に対応する ISO 639-1/3166 言語コードです。値の例として、en、de、es、fr、it、ja、ko、ru、pt-br、zh-cn、zh-tw があります。以下の例は、パラメーターで表示される言語をフランス語に設定している ACS 管理ポータルの URL です。

    https://your-namespace.accesscontrol.windows.net/?lang=fr

  • Web ブラウザーの設定 – 言語の設定に "lang" URL パラメーターまたは言語セレクターが使用されていない場合は、ACS 管理ポータルと ACS でホストされたログイン ページは、Web ブラウザーに設定されている言語設定に基づいて、表示する既定の言語を決定します。

以下は、このリリースで大きく変更されたサービスの動作です。

1. すべての OAuth 2.0 応答のエンコーディングは現在 UTF-8 である

ACS の初期リリースでは、OAuth 2.0 エンドポイントからのすべての HTTP 応答の文字エンコーディング セットは US-ASCII でした。2011 年 7 月の更新プログラムにより、現在、すべての HTTP 応答の文字エンコーディング UTF-8 に設定され、拡張文字セットがサポートされています。

以下は、このリリースでの既知の問題です。

ルール エディターが、ID プロバイダーに関連付けられていないカスタム発行者を表示できない

現在、ACS 管理ポータルのルール エディターは、ID プロバイダーまたは ACS に関連付けられた要求発行者のみを表示できます。ID プロバイダーまたは ACS のいずれにも対応していない発行者を参照するルールがロードされると、次のエラーが表示されます。

  • ACS80001:このルールは、管理ポータルでサポートされていない要求発行者の種類を使用するように構成されています。管理サービスを使用して、このルールを表示および編集してください。

ACS 内で関連付けられた ID プロバイダーなしで発行者が存在できるシナリオは 2 とおりサポートされています。

  • OAuth 2.0 委任シナリオでは、発行者レコードは ACS 管理サービスを使用することによってアクセス制御名前空間内に作成され、この発行者には関連付けられた ID プロバイダーはありません。

  • ACS で認証するために同名のサービス ID を使用している状態で、発行者が WRAP プロトコルを介して要求をトークン要求にアサートする目的で作成された場合。

このリリースでは、ACS は、特定の アクセス制御名前空間に対して作成可能な ID プロバイダー、証明書利用者アプリケーション、ルール グループ、ルール、サービス ID、要求の種類、委任レコード、発行者、キー、およびアドレスの数に制限を設けていません。

サービスの制限の詳細については、「ACS サービスの制限事項」を参照してください。

コミュニティの追加

追加
表示:
© 2015 Microsoft