問題タブ [principal]

単純なアプリケーションを 3 つのアセンブリに分割しています。1 つは、ユーザーがレジストリからキーを読み取れるようにするクライアント フォームです。2 つ目は、ユーザーがログインする認証フォームです。3 つ目は、実際の作業を行うすべてのメソッドを含む .dll ライブラリです。

ここにある Declarative Security Checks の実行に関する MSDN チュートリアルに従いましたhttp://msdn.microsoft.com/en-us/library/dswfd229.aspxしかし、何かがまだ機能しません。

次のような GenericPrincipal オブジェクトを作成します。

これは、.dll アセンブリの CustomPrincipal クラスにあります。

同じアセンブリに、次のメソッドを持つ RegistryOperations クラスがあります。

派手なものはありません。私の「承認」アセンブリには、承認のために .dll メソッドを呼び出す GUI があります。

最後に、3 番目の「クライアント」アセンブリで、.dll メソッドを呼び出してレジストリ キーを読み取ります。

これはうまくいきません。認証アセンブリを介してログインし、レジストリを読み取ろうとすると、プリンシパル アクセス許可の要求が失敗しました。Visual Studio は、アセンブリを神秘的な完全信頼リストに追加することを提案していますが、VS2010 にはそれがありません。お知らせ下さい。

私の現在のアプリケーションは、このクラスを使用して、LDAP（より正確にはActive Directory）に対してPrincipalContextデフォルトユーザー（Web.config専用セクションに入力）を認証します。

この認証により、（を介して）他のユーザーを検索できますUserPrincipal.FindByIdentity(ldapContext, username)。ただし、 Web.configでユーザーを明確にすることはクライアントには受け入れられないため、これを変更する必要があります。OK、私はそれを理解することができます:-)）

だから私はいくつかの解決策を持っています：

• Web.configの対応する部分（membership部分、withprovidersなど）の暗号化を管理する

• アプリケーションが展開されているIIS7のアプリケーションプールのアカウントを使用します。これは、IISからプリンシパルを取得し（この点はそれほど難しくないはずです）、ADに対する認証に使用することを意味します。しかし、私はそのためのメソッドを見つけることができません。クラス経由でも、PrincipalContextクラス経由でもありませんActiveDirectoryMembershipProvider。

これら2つのソリューションのいずれかを管理する方法を知っていますか、それとも他のソリューションについて考えていますか？

どうもありがとう ！！

フォーム認証と汎用プリンシパルの違いは何ですか? ASP.NET でフォーム認証を使用する場合、ジェネリック プリンシパルとジェネリック ID を実装すると、これらを実装しない場合よりもどのような利点がありますか? これは、それらが同じものに対する2つの異なるアプローチであると想定しています。

ただし、それらが同じものに対する 2 つの異なるアプローチではない場合、フォーム認証だけでは提供されず、ジェネリック プリンシパルが提供するものは何なのでしょうか?

従来のASP.NETアプリケーション内にカスタム承認を実装するさまざまな手法をすべて理解しようとしています。推奨されるアプローチは、カスタムプロバイダーモデルを作成してMembershipAPIを使用することです。

ロールと個々のパーミッションの組み合わせに基づくカスタムロール承認モデルの実装に興味があります（ロールはパーミッションで構成され、ユーザーは複数のロールまたはロールが持つ可能性のあるパーミッションをオーバーライドする特定のパーミッションを持つことができます）

本格的なロールプロバイダーを作成することと、カスタムプリンシパルオブジェクトを実装してすべての承認ロジックをIsInRoleメソッドのオーバーロードに実装することの長所と短所は何ですか？カスタムプリンシパルは、1.1に戻った非推奨の手法ですか？一般的に、いつカスタムプリンシパルを実装することになっていますか？

ユーザーストアとしてActiveDirectoryを使用しています。サードパーティのコンサルティング会社は、XMLファイルに含まれ、各ユーザーのSessionオブジェクトで渡される承認ロジックとルールを含み、承認のためにASP.NETインフラストラクチャとは一切関係しない、ひどいカスタムロールベースの承認モジュールを実装しました。 。

このためのベストプラクティスを知りたいのですが

「クライアント認証が必要」で構成されたSslFilterでMinaを使用しています。

接続が確立され、ハンドシェイクが完了したら、サーバー上の IoHandler のサブクラスから接続の反対側にあるピアの証明書 (またはプリンシパル) を取得する方法は?

編集:つまり、ハンドシェイクが完了して IoHandler.sessionOpened() が呼び出されたときに、IoSession とプリンシパルの間の関係を取得する方法。

jsp を使用すると、次を使用してログインしたプリンシパルを簡単に印刷できます。<%= request.getUserPrincipal() %>今度は、JSF 2.0 + Facelets を使用して同じことを行いたいと思います。どうやってするか？私はしばらくの間試みてきましたが、これまでのところ成功していません。

事前に送信します。

1 つのログインを使用すると機能する WCF サービスがありますが、他のログインでログインしようとすると次のエラーがスローされます。奇妙なことに、パスワードを有効なログインに変更すると、新しいパスワードは機能しませんが、古いパスワードは引き続き機能します。何かをキャッシュしているようなものです。

私が得るエラーはこれです：

複数のユーザー名を使用して、同じユーザーがサーバーまたは共有リソースに複数接続することは許可されていません。サーバーまたは共有リソースへの以前の接続をすべて切断し、再試行してください

エラーの原因となるコードは次のとおりです。

ここに関連する質問が表示されます。これは、問題が にあることを示唆していますPrincipalContextが、回答はありません

アップデート

うまくいきました.....次の1時間以内に重要な人のためにこれを機能させる必要があったため、本番サーバーを再起動しました.再起動して、今のところ機能させるために必要なログインでログインします。再起動後、すべてが完全に機能します。私は昨日のほとんどを遅くまで過ごし、今朝はずっとこれを理解しようとしていました。Webサーバーを再起動することは想定されていませんが、これを機能させることが重要だったので、とにかく再起動しました.今ではすべてが正常に機能しています.

それでも、その問題が何であったかを知りたいです。私の最善の推測は、何かが原因で がPrincipalContext正しく破棄されなかったため、他の資格情報セットでログインできなくなったということです。

CheckAccessをオーバーライドし、URLの一部であるカスタム認証トークンを検証するカスタムServiceAuthorizationManagerがあります。検証した後、GenericPrincipalを使用してThread.CurrentPrincipalを設定します。しかし、リクエストが最終的に私のサービスメソッドに到達すると、Thread.CurrentPrincipalがなくなり、認証マネージャーで設定したものではなくなります。何が問題なのですか？

Active Directory サーバーにログインするには、どの「プリンシパル」を指定すればよいか考えています。プリンシパルは、ログインしようとしている AD 内のユーザーである必要がありますか? または、ユーザーが AD にアクセスする権限を持っている限り、指定したドメイン内のユーザーにすることができますか?

資格情報エラー 49 で両方を試しました。しかし、AD がインストールされているサーバーの管理者アカウントを使用して、ldp.exe で AD にログインできます。

これが私のコードです。迅速なヘルプに感謝します。

VB.NET で My.Settings.Default にアクセスすると、スレッドの CurrentPrincipal が変更されるようです。次のコードを検討してください。

このコードの出力は

管理者

MyDomain\MyUserName

これは期待されていますか？それはどこかに文書化されていますか？私はそれへの参照を見つけることができませんでした。

また、これは My.MySettings.Default が初めてアクセスされたときにのみ行われるようです。つまり、回避策として、スレッドの CurrentPrincipal を設定する前に、プロパティに触れて初期化することをお勧めします。それを行うことで望ましくない副作用はありますか？