25

ユーザー資格情報が Active Directory に存在する、安全な (SSL) パブリック サービスを作成しています。ServiceStack の認証を利用したいので、wiki の記事を読みました。AD でユーザー資格情報を検証するためのコードを既に作成しています。いくつかの質問を聞きたいんです。

  1. どの認証プロバイダーを使用すればよいですか? 資格情報、基本認証またはカスタム? このサービスは SSL を必要とするため、基本認証は安全ですが、パスワードは安全性を高めるために暗号化されます。
  2. UserAuth を保存して AuthUserSession をキャッシュする必要はありますか?
  3. monotouch クライアントは認証をサポートしますか?

更新 2: CredentialsAuthProvider を使用して、AD と統合されたテスト SS サービスを作成しました。しかし、私の最終的な目標は、クライアントから呼び出されたときに API となるサイトを 1 つ持つことです。つまり、基本的には SS MVC サイトです。

アップデート：

SS が将来的に Windows 認証をサポートする可能性のある商用製品を作成することを検討していることは、さらに調査を行った後の私の理解です。これは、SS Google グループの mythz からのコメントで読みました。私がこの SO の質問をした理由は、私の会社が IWA を使用して社内アプリケーションを構築しており、IWA なしでは SS MVC を採用するのが難しいためです。IWA を使用する ASP.NET サイトから SS MVC サイトをホストできると読んだと思いますが、まだ試していません。

4

2 に答える 2

5

これはデミス・ベロットがツイッターで言ったことです。おそらく可能ですが、さらに研究が必要です。

私が調査したものではありません。Win/Active Directory ではもう動作しません。問題を見つけて解決するには、ある程度の研究開発が必要です

最終的に、AD で動作するプロトタイプ サービスを取得しました。CredentialsAuthProvider を実装しました。現在、これは ASP.NET IWA にまったく関連付けられていませんが、ユーザーが AD にいるかどうかを簡単に確認できます。うまくいけば、これは誰かを助けるかもしれません。

public class LDAPAuthProvider : CredentialsAuthProvider
{
    public override bool TryAuthenticate(IServiceBase authService, string userName, string password)
                    {
                        //Check to see if the username/password combo is valid, an exception will be thrown if the username or password is wrong
                        try
                        {
                            DirectoryEntry entry = new DirectoryEntry(ConfigurationManager.AppSettings["TargetOU"], userName, password);
                            object nativeObject = entry.NativeObject;
                        }
                        catch (Exception)
                        {
                            //This means the username/password combo failed
                            return false;
                        }

                        return true;
                    }
}
于 2013-04-26T21:33:00.893 に答える
5

また、(企業アプリケーション用に) 統合 Windows 認証を使用して ServiceStack を接続しました。重要なのは、ServiceStack の AuthProviders と完全に統合しようとするのをスキップすることでした。IWA の一般的なアプローチは、アプリケーション コード内の資格情報を処理しないためです。 - Web サーバーによって処理されます。私がしたことは：

  1. Windows 認証が唯一の有効なオプションになるように、IIS でサイト/アプリケーションを構成します。(匿名アクセスは許可されません。) これは、IIS 自体が認証されていないユーザーとのチャレンジ/レスポンス (HTTP 401/200) シーケンスを処理し、プロセスの認証部分を処理することを意味します。

  2. ServiceStack のIHasRequestFilter(HTTP プレリクエスト フィルター) を属性 ([AdminOnly] など) として実装します。このフィルターの RequestFilter メソッドは、HttpContext ( HttpContext.User.Identity.Name) から現在のユーザー名をフェッチし、リポジトリ (SQL データベース、フラット ファイルなど) からそれを検索し、ServiceStack ICacheClient(メモリ キャッシュ、Redis など) を使用して結果をキャッシュし、スローします。無許可の場合は 403 HttpError。

これが完了したら、必要なのは、必要に応じてクラスまたはメソッドに属性を追加し (必要に応じて、この認証/承認をサービス パイプラインに取得します)、AppHost 実装に目的のキャッシュ プロバイダーを登録することだけでした。

 container.Register<ICacheClient>(new MemoryCacheClient() { FlushOnDispose = false });

美しく機能します。

于 2013-05-14T19:26:39.577 に答える