問題タブ [claims-based-identity]

私は自分のオフィスで最初のプロジェクトに取り組んでおり、クレームベースの承認で "Windows Identity Foundation" を使用する予定です。この目的のために、Microsoft .net は ClaimsAuthorizationManager 抽象クラスを提供します。このクラスを使用するには、コンストラクターとCheckAccess(context as ClaimsAuthorizationContext).

コンストラクターはすべてをセットアップします。次に、ユーザーが Web ページなどの何かにアクセスすると、CheckAccessユーザー、アクセスするリソース、およびリソースに対して実行するアクションを示すパラメーターを使用して呼び出されます。たとえば、アクションを実行するためにリソースへのアクセス権をCheckAccessユーザーに付与する必要があるかどうかを確認するために呼び出すことができます。 またはを返すだけです。Windows Identity Foundation は、考えられるほぼすべての方法を柔軟に実装できるようにします。Bobhttp://www.mysite.com/SecretPage.aspxGETCheckAccesstruefalseCheckAccess

Microsoft が提供するコード サンプルではCheckAccess、​​ユーザーが 21 歳以上であることを示す誕生日クレームを持っている場合にのみアクセスを許可するように構成されています。このポリシーは、web.config でプレーンテキストで指定され、ClaimsAuthorizationManagerコンストラクターで読み取られます。

私のオフィスでは、SQL を使用してほぼすべてのデータを追跡しています。ClaimsAuthorizationManagerユーザーがリソースにアクセスできるかどうかを判断するために、SQL からデータを読み取るように をプログラムすることは理にかなっていると思います。ただし、考えられるポリシーは無数にあります。ClaimsAuthorizationManager現在のプロジェクトに役立ち、現在作成しているプロジェクトをリッピングして置き換えることなく、将来的に構築および改善できるを作成したいと考えています。

このプロジェクトを進めていく上で、最も重要なことは何ですか?

更新: 私は、必須請求ポリシーを文字列として表すシステムに取り組んできました。ポリシーをグループ化するために二分木ロジックを使用しています。「リソース」と「アクション」に関連するクレームのデータベースを維持しています。

ここで他の誰かが ClaimsAuthorizationManager クラスを作成しましたか?

次の利用可能な適切な例はありますか？

WIF SDKを見ると、ユーザーが認証に使用するセキュリティトークンサービス（STS）上でASP.NETサイトのシンスキンにリダイレクトするためにASP.NETと組み合わせてWIFを使用する例があります（ユーザー名を指定WSFederationAuthenticationModule (FAM)することにより）およびパスワード）。

WIFとクレームベースのアクセスを正しく理解している場合は、ユーザーがユーザー名とパスワードを入力し、認証のためにこのデリゲートをSTSに送信して、セキュリティ標準を介してエンドポイントにログインの詳細を送信する独自​​のログイン画面をアプリケーションに提供してほしいと思います。 （WS- *）、およびSAMLトークンが返されることを期待しています。理想的には、を組み合わせて SessionAuthenticationModule使用​​する例のように機能します。つまり、セッションセキュリティチャンクCookieからを再構築し、セキュリティセッションの有効期限が切れたときにアプリケーションのログインページにリダイレクトします。FAMSessionAuthenticationModuleIClaimsPrincipal

FAM適切なweb.config設定を使用して、私が説明することは可能ですかSessionAuthenticationModule、それともこれを処理するために自分で書くことを考える必要がありますHttpModuleか？または、パッシブリクエスターシナリオでユーザーが事実上のアプローチでログインするシンWebサイトSTSにリダイレクトしていますか？

SharePoint 2010 のクレーム ベース認証のサポートについて読んでいます。ただし、この時点で、私のショップにはしばらくアップグレードしない可能性のあるクライアントが何人かいます。他のサービスのクレームに互換性を持たせるにあたり、2007 のインストールで既存のコードを大幅に変更しなくても、クレーム ベースの認証が現実的かどうか疑問に思っています。

WindowsXPでWindowsIdentityFoundation SDKを使用するにはどうすればよいですか？

ASPNetSQLMembershipProvider を使用してフォーム ベース認証をセットアップしようとしています。2010 Beta 2 では、クラシック モードでこれを行うことができましたが、うまくいきました。RTM では、クラシック モードではサポートされなくなり、クレーム ベース認証に切り替える必要があります。そこで、新しい Web アプリケーションを作成し、sharepoint のすべてを FBA で動作するように構成しましたが、動作させることができません。

誰でもこれを行うことができましたか？

ありがとう、イタイ。

クレーム ベース認証と OAuth によって提供される認証の違いは何ですか。

技術的な違いではなく、概念的な違いを探しています。OAuth よりもクレームを選択したり、その逆を選択したりするのはいつですか。

クレーム ベース認証は Microsoft によって提案され、WS-Security の上に構築されています。しかし、OAuth はセキュリティ トークンに基づいてさまざまなポータルからリソースを取得できるようにするために提案されているオープン ソース プロトコルです。

Claims には、このトークンの概念 (SAML エンコードまたは X509 証明書) もあります。

OAuth よりもクレームを選択するタイミングと、その逆を選択するタイミングを理解しようとしています。

ありがとう

.netクレームベースのIDフレームワーク

たとえば、特定のアカウント＃123456でユーザーが操作（表示または編集）を実行することを制限したい場合（銀行口座などの事業体について話している）、クレームを作成することをお勧めします。アカウントごとに、表示または編集できますか？

セットに多くのクレームがあることの不利な点はありますか？システム管理者は、システム内のすべてのアカウントにアクセスできるため、数百のクレームが作成される可能性があります（アカウントごとに複数のクレームが作成される可能性があります）。

ADFS サーバーを使用せずに SharePoint Foundation 2010 用の非常に単純なカスタム IP-STS を作成して、ADFS を使用せずに Windows Live ID を SharePoint Foundation 2010 に簡単に統合できるようにする予定です。Windows Web Server 2008 にインストールできないため、ADFS サーバーを使用できませんまた、多くの記事で LDAP プロバイダーを使用していることがわかりましたが、SharePoint Foundation にも存在しません (Sharepoint Server Edition が必要です)。

あまりにも多くの検索を行った後、次の記事を見つけ、1 つの問題を除いてすべての手法を見つけました。

1) カスタム クレーム プロバイダーの作成: blogs.technet.com/b/speschka/archive/2010/03/13/writing-a-custom-claims-provider-for-sharepoint-2010-part-1.aspx

2) カスタム STS プロバイダーの作成: http://blogs.msdn.com/b/chunliu/archive/2010/04/02/how-to-make-use-of-a-custom-ip-sts-with-sharepoint -2010-part-1.aspx

STS サイトにユーザー名を入力して localhost/_trust/default.aspx にリダイレクトした後、次のエラーが発生しました ( EncryptingCertificateName は空のままにします)。

オブジェクトの現在の状態のため、操作は無効です

そのエラーではなく、アクセス拒否エラーが発生することを期待しています。

1.とにかくそれは可能ですか？2.ADFSサーバーなしでカスタムIP-STSを作成するための実用的な記事をどこで見つけることができますか?

ありがとう

私はしばらくの間、WindowsIdentityFoundationを使用してクレームベースの認証を使用してプログラミングしてきました。

Windows Identity Foundationでは、ユーザーがログインすると、クレームは基本的にユーザーを説明する一連の情報であるように見えます。

以前の役割ベースの認証では、ユーザーは特定のグループのメンバーであるかどうかを判断できましたが、クレームベースの認証では、ユーザーを説明する一連の情報を取得できるようになりました。「このユーザーは女性です」。このユーザーは「1975年7月6日」に生まれました。「このユーザーはUSBキーを使用してログインしました」。

フレームワークによってアプリケーションに与えられたユーザーに関する一連の情報を持っているのは、クレームベースの認証の本質ですか？

2 つの質問:

1) STS を使用してクレームを取得する場合、Web アプリケーションでセッション Cookie の有効期間を設定する方法/場所を教えてください。私が知る限り、これは ServiceConfigurationCreated イベントでプログラムによってのみ行うことができるようです。

2) 有効期限がスライドしていることをどのように/どこで確認できますか?