0

そこで、iis7でホストされるWCFサービスのセットアップに取り組んでいます。このサービスはRESTサービスです。

これまでの認証要件は、ドメインアカウントのみがサービスに接続することでした。基本認証を使用し、偽装を使用して、ビジネスレイヤーを介してDBに電話をかけています。

これはすべてうまく機能しています。

今、私たちは非ドメインアカウントが私たちのサービスを使用することを許可する必要があります。IISの問題により、これ（http://custombasicauth.codeplex.com/）と、（渡されたユーザー名に応じて）ActiveDirectoryまたはasp.netメンバーシップに対して認証を試みるカスタムメンバーシッププロバイダーを実装しました。プロバイダー。この部分は正しく機能しています。

私が今抱えている問題は、なりすましが機能していないことです（これは理解できます）。今、これは私が迷子になり、すべての霧の方向付けまたは除去の助けが必要な場所です。私がやりたいこと（そしてこれが可能かどうかはわかりません）はこれです：

ユーザーがドメインユーザーである場合は、アカウントを偽装します。ドメインユーザーでない場合は、「一般ユーザードメインアカウント」になりすます。ボーナスとして、これを「舞台裏」で実行して、これを処理するために特別なロジックを追加する必要がないようにします。

ID、ポリシープロバイダー、ロールプロバイダーについてたくさん読んだことがありますが、今では完全に混乱しています。

誰かがこれについていくつかの洞察を持っていますか？

4

1 に答える 1

-1

そのため、IISでのなりすましの動作に関する詳細をオンラインで多く調べた後、役立つ情報を見つけることができませんでした。それで、私はそれを「ハッキング」することをもっと調べ始めました。

私はこれ（http://custombasicauth.codeplex.com/）を使用して、WCFでカスタム基本認証を使用できるようにしました。

このモジュールの流れは 、接続が確立されたときにLeastPrivilege.CustomBasicAuthentication.CustomBasicAuthenticationModule.OnEnter（）が呼び出されます。
これにより、 LeastPrivilege.CustomBasicAuthentication.CustomBasicAuthenticationModule.AuthenticateUser（）が呼び出され、最終的に LeastPrivilege.CustomBasicAuthentication.CustomBasicAuthenticationModule.SetPrincipal（string username）が呼び出されます。

パスワードも受け入れるようにSetPrincipalを変更しましたprivatestaticvoid SetPrincipal（string username、string password）

ここでは、ユーザー名で単純なifを実行して（ドメインプレフィックスを確認）、ユーザーがドメインアカウントであるかどうかを判断します。ドメインアカウントの場合は、ユーザー名/パスワードを使用してWindowsIdentityを作成します（http://www.codeproject.com/KB/dotnet/UserImpersonationInNET.aspxを使用し、少しリファクタリングしてWindowsIdentityのみを取得しました）。ユーザーがドメインアカウントでない場合は、既知のハードコードされたドメインアカウントを使用します。次に、このWindowsIdentityを取得してWindowsPrincipalを作成し、それをHttpContext.Current.Userに設定します。

だからこれは私たちのために働きます。なりすましが機能しています。この副作用として、WCFメソッドを[OperationBehavior（Impersonation = ImpersonationOption.Required）]属性で装飾する必要はありません。これが「正しい」方法かどうかはわかりませんが、かなり近いと思います。IISは、現在のユーザーにWindowsPrincipalがあることを検出し、そのアカウントを自動的に偽装すると思います。

于 2011-11-16T15:54:42.590 に答える