問題タブ [federation]

WCF Data Servicesを使用して、SQL Azureフェデレーションのフェデレーションメンバーに格納されているエンティティへのCRUDアクセスを提供することはできますか？

フェデレーションキーがセキュリティプリンシパルに格納されており、アプリケーションコンテキストですぐに利用できると仮定すると、サービス操作をインターセプトして適切なUSE FEDERATIONコマンドを発行し、明示的に行う場合と同様に、適切なタイミングで接続を開く方法があります。ADO.NET Entity Framework用に開発していますか？

現在、Azureの連合データベースに移動するように自動移行を設定する作業を行っています。ようやくテーブルのデプロイが機能するようになりましたが、将来的に懸念されることの1つは、ストアドプロシージャのデプロイです。

ストアドプロシージャを追加すると、それはフェデレーションのどの部分にも存在するように見えます。したがって、データを2つのデータベースに分割し、ストアドプロシージャをデータベースの1つにデプロイすると、それはそこにいる。既にAzureに組み込まれているフェデレーション内のすべてのデータベースにストアドプロシージャをデプロイする方法はありますか？

複数のデータベースからのクエリに関するmsdnブログの投稿を見つけました。これを変更してプロシージャをデプロイできると思いますが、面倒になると思うので、現在の移行設定では実装しません。

フェデレーションを使用して SQL Azure データベースで SQL Azure Reporting Services を使用し、テーブルをテナント ID でフェデレーションし、データベースへのすべてのアクセスがフェデレーション キーでフィルター処理された接続 (テナントでフィルター処理) を介して行われるという要件を満たすことはできますか?

このフォーラムの投稿で提案されているように、特定のフェデレーション メンバー データベースに接続するだけでは十分ではありません。1 つのテナントが別のテナントのデータを表示できてはならないからです。"FILTERING=ON" 条件を使用して、SQL Azure フェデレーションによって接続をフィルター処理する必要があります。

SQL Azure Reporting Services で必要な USE FEDERATION コマンドを実行して、接続をフェデレーション キーでフィルター処理する方法はありますか?

または、Reporting Services が他の方法 (OData Web サービスなど) でフィルター処理されたデータにアクセスできるようにするにはどうすればよいでしょうか?

望ましい結果は、各テナントがレポートを実行し、自分のデータのみを表示できることです。

数か月以内に、アプリケーションを水平に分割する必要があります。アプリケーション内に CPU とメモリの負荷を必要とする特定のサービスがあり、スケーラビリティのために、複数の JVM 間でサービスを分割したいと考えています。

パーティション化する必要があるサービスをカプセル化する EAR があります。これを行う場合、サービス (UI など) のクライアントは、サービスの特定のインスタンスに対処できる必要があります。たとえば、Account という名前のサービスがあるとしますが、実際にはそのサービスの 3 つのインスタンスが 3 つの異なる JVM で実行されています (ただし、すべて同じ Java EE ドメインにあります)。アカウント ID から特定の VM にマップできる Service Locator があると仮定すると、その特定のアカウントにサービスを提供できる EJB にどのようにアクセスすればよいでしょうか?

考えられる解決策は、アプリケーション コンテナが別のアプリケーションの EJB に与える JNDI 名を利用することです。モジュールを異なる名前で 3 回デプロイすると、JNDI ルックアップを実行してそれらにアクセスできます。

java:global/AccountServer1/AccountFacade

java:global/AccountServer2/AccountFacade

java:global/AccountServer3/AccountFacade

これを機能させるには、依存性注入を使用して AccountFacade にアクセスすることはできません。AccountID を取得して Account アプリケーションの 1 つにマッピングできる AccountLocator EJB を使用する必要があります。巧妙になりたい場合は、メソッドへの引数が使用するサーバーを識別できると仮定して、ルックアップを透過的に行う「ローカル」アカウント ファサードをおそらく実装できます...

このアプローチは実行可能ですか? より良い代替手段はありますか？

初めての Azure アプリケーションの作業を開始しましたが、多くのことを学んでいます。私が最近発見した機能の 1 つは、SQL Azure のフェデレーションでした。これは、本質的に SQL Azure シャーディングの実装であるため、水平方向にスケーリングできます。

私のプロジェクトは SQL Server の使用を開始し、すでに大部分がユーザー プロファイルによってグループ化されていたので、フェデレーションするのが最も理にかなっていると判断しました。すべての子テーブルを含むフェデレーションを作成しましたが、問題が 1 つあります。ID はサポートされていません。サポートされていない理由がわかりました。よくわからないのは、何に置き換えるのが最善かということです。これは、他の誰かが解決したに違いない大きな問題のように思えますが、あまり見つけることができませんでした。

UniqueIdentifier を使用することもできますが、分割するのが面倒になる可能性があることを読みました。また、連合テーブルの主キーとして GUID を使用すると、他にどのようなパフォーマンスの問題が発生する可能性があるかについてもよくわかりません。

私はこれを Entity Framework で使用していますが、そのフェデレーションを使いやすくするまでには至っていません。私が知る限り、LINQ クエリを作成する前にコードを実行してフェデレーションを選択するよりもそれほど複雑ではありませんが、到達したらその橋を渡ります。

今のところ、 ID を生成するための適切な解決策がないため、実際にフェデレーションにアイテムを追加する最善の方法がわかりません。

アドバイスをいただければ幸いです。

Windows Azure ACS を利用するアプリケーションがあります。ACS を使用して、Facebook、LiveID、Yahoo、および Google の認証を実装しました。

開発マシンでは問題なく動作しています。

私のアプリケーションは、開発中はhttp://127.0.0.1:81で実行されますが、本番環境ではドメイン xxxxx.com で実行されます。

実稼働デプロイメントの FederationMetadata.xml および Web.config 設定をオンザフライで変更するにはどうすればよいですか? 手動で行う必要がありますか、それとも自動化された方法がありますか?

公開 Web サイトのグループ間でフェデレーションを実装する手法について疑問に思っています。簡単な答えは「フェデレーション」または「saml」です。ただし、実際には、多くの技術的な問題が見られます。アカウント リンクの作成 (サイト 1 のユーザー「SteveRoy」がサイト 2 の「SRoy」にリンクされるようにするため)、ログオン ページを変更して中央の IdP を参照すること、そうでないユーザーを処理することなどです。要するに、「saml」ははるかに複雑な問題を単純化しすぎているようです。この分野で成功した人たちから詳細を聞きたい...

Google には、すべてのサイトで SSO を配信するための奇抜なソリューションがあります。複数のアカウントを非常にうまく管理しているようで、アカウントのリンクが可能で、サービスにアクセスしようとするときにユーザーが複数のアカウントから選択できるようにします。

この SSO ソリューションを提供するための Google の取り組みに関する情報はありますか?

また、私は彼らのログオン ページを見て、ログオン画面の URL で使用されるさまざまなパラメータの目的を誰かが知っているかどうか疑問に思っていました。

SQL Azure フェデレーションが IDENTITY プロパティまたは SEQUENCE をサポートしていないことを考えると、レコードを挿入するときに連番を生成する効率的な方法は何でしょうか?

たとえば、次の列を持つテーブルがあるとします。

特定のテナントに挿入された注文ごとに、OrderId をインクリメントする必要があります。たとえば、テナント A の OrderId は 1、2、3... となり、テナント B の OrderId も 1、2、3... と独立したシーケンスになります。隙間がないのが理想です。

TenantId と OrderId は主キーのコンポーネントです。それらの値はアプリケーションによって設定され、シーケンスの生成の問題とは関係ありません。OrderId だけがビジネス上の意味を持つ連番を持ちます。また、TenantId はフェデレーションの配布キーです。

この MSDN ブログの記事では、オプション 1 で、シーケンスを保持するテーブルを用意し、分離されたトランザクションでストアド プロシージャを使用してシーケンスをインクリメントする方法について説明しています。各テナントは、シーケンスの最後に使用された値を保持するこのテーブルにレコードを持ちます。

スケーラビリティ、競合、リソースのロックを考慮すると、これが最適なアプローチでしょうか? SQL Azure フェデレーションの制限を考慮して、他に役立つトリックはありますか?

How can I specify the service identity principal name in the WCF client config for the issuer STS when binding using WS-Federation?

I have an application pool running under a domain account on a front end server trying to authenticate using federation to backend services on an app server (running under domain accnts) using an STS also running on the app server and under a domain account.

In order to use Kerberos correctly I need to set the userprincipal name of the STS on the frontend client. I can't see how to do that.

I am experiencing a connected problem, which is that fallback to NTLM does not work when the issuer is specified using FQDN, and Kerberos fails (SSPI negotiation failed) I think because I have no issuer principal name in the config. If I set the issuer using IP address instead, then authentication to STS succeeds using NTLM, I think, so I have a workaround.

The STS is issuing tokens on the basis of Windows auth on that endpoint. It has other endpoints for forms-type auth and so on.

Possibly a related problem on our network is that silverlight clients that call back to web services are not working without the servers being manually added to Local Intranet zone in IE. Seems as though for some reason the app servers are not considered as being on same domain. Any clues much appreciated!