3

.NET の認証、メンバーシップ、および/またはプロファイル プロバイダー機能を利用して、.NET Web アプリを会社のエンタープライズ ポータルに統合できるかどうか疑問に思っています。簡単に言うと、ポータルは、ユーザー名、ユーザー プロファイル データ、一部のアクセス権などのフィールドについて、ポータルの「背後」にある任意のアプリケーションにカスタム ヘッダー値を送信します。ポータルに関する問題の 1 つは、Web で利用可能な .NET アプリの多くを活用できないことです。これは、主にユーザーが既に認証されていることを信頼するために、「ポータル対応」になるように設計されていないためです。

カスタム認証プロバイダーを作成して (または何らかの方法でフォーム認証を利用して)、ヘッダー (および IP) を見て、そのユーザーとして自動的に「認証」することは可能でしょうか? 私の考えでは、プロファイル プロバイダー、おそらくメンバーシップ プロバイダーを作成し、何らかの方法で認証を追加することで、Oxite ブログ (私が見つけた .net mvc デモ) のようなクールなコンポーネントをダウンロードし、プロバイダーをカスタム プロバイダーに切り替えて、活用できるようになると考えています。最小限のコード変更で会社のポータルの背後にある。

これは意味がありますか？これらのコンポーネントがパズルにどのように適合するかを理解していない可能性があると感じています.

4

3 に答える 3

3

.Net アプリをまったく変更せずにこれを実行できるとは思いませんが、最小限の変更で実行できる可能性があると思います。ポータルが .Net Web アプリケーションに送られるすべてのものをゲートウェイ化すると仮定していることに注意してください。つまり、ポータルはブラウザーからすべての HTTP 要求を取得し、独自のヘッダーを追加し、要求を .Net アプリに送信し、.Net アプリから応答を取得し、さらに書き直してから、ブラウザーに情報を返します。 .

今何が起こっているのか (この質問を書いた理由) は、この .Net アプリをポータルのポートレットに埋め込んでいると推測していますが、誰かがそれを参照しようとすると、ポータルにログインしているにもかかわらず、ポートレット ボックス内の外部 .Net ログイン画面。とても素敵ではありません。

ここでは、次の 2 つの手順を実行する必要があります。

  1. .Net アプリのログイン ページをやり直して、ポートレット ユーザーを自動ログインさせます。
  2. #1 と連携するカスタム メンバーシップ プロバイダーを作成する

1. .Net アプリのログイン ページをやり直して、ポートレット ユーザーを自動ログインさせます。

.Net アプリのログイン ページを見つけます。おそらく login.aspx のようなものになります。それ (および関連するコードビハインド ファイル) を portallogin.aspx と portallogin.cs にコピーします。portallogin.aspx および portallogin.cs ファイルを開きます。そこにあるすべてのコントロールとコードを取り除きます。以下に示すようなものに置き換えます。PORTAL_SomeFunctionName が表示されている場合は、適切な関数呼び出しを行うポータルの SDK のコードに置き換える必要があることに注意してください。

const string specialpassword = "ThisPasswordTellsTheBackendSystemThisUserIsOK";

Page_Load()
{
  if (PORTAL_IsLoggedInToPortal())
  {
    string username = PORTAL_GetCurrentUserName();
    // Authenticate the user behind the scenes
    System.Web.Security.FormsAuthentication.SetAuthCookie(username, false);
    System.Web.Security.FormsAuthentication.Authenticate(username, specialpassword);
  }
  else
  {
    throw new Exception ("User isn't coming from the Portal");
  }
}

次に、.Net アプリケーションの web.config を編集し、ログイン ページが login.aspx ではなく portallogin.aspx であることを伝えます。

これにより、ユーザーのログインが自動的に試行されます。

2. #1 と連動するカスタム メンバーシップ プロバイダーを作成する

ここで、カスタム メンバーシップ プロバイダーを作成する必要があります。これを機能させるには、使用している .Net アプリケーションでメンバーシップ プロバイダーを使用し、カスタム メンバーシップ プロバイダーを使用できるようにする必要があります。

新しいメンバーシップ プロバイダーを作成します。クラスを作成し、System.Web.Security.MembershipProvider から継承する必要があります。少なくとも、GetUser および ValidateUser 関数と ApplicationName プロパティを実装する必要があると思います。以下は、それらがどのように見えるかについてのいくつかのアイデアです。オーバーライドする必要がある関数は他にもたくさんありますが、スタブ (付随する NotImplementedException(s) を含む) はおそらくそのままにしておくことができます。

    public override string ApplicationName
    {
        get
        {
            return "Portal";
        }
        set
        {
            ;
        }
    }

    private const string specialpassword = 
       "ThisPasswordTellsTheBackendSystemThisUserIsOK";

    public override bool ValidateUser(string username, string password)
    {
        // If the password being passed in is the right secret key (same  
        // for all users), then we will say that the password matches the
        // username, thus allowing the user to login 
        return (password == specialpassword);
    }

    public override MembershipUser GetUser(string username, bool userIsOnline)
    {
       string email = PORTAL_getemailfromusername(username);

       System.Web.Security.MembershipUser u = new MembershipUser(
         this.name, username, username, email, "", "", true, false, 
         DateTime.Now(), DateTime.Now(), DateTime.Now(), 
         DateTime.Now(), DateTime.Now(), DateTime.Now()
       );
       return u;
    }

.Net RoleProvider と ProfileProvider の機能がこの .Net アプリとの統合に役立つ場合は、同様の実装を行うこともできます。(Role プロバイダーはグループ メンバーシップ情報を提供し、ProfileProvider は、電子メール アドレス、郵便番号、または各ユーザーに提供するその他のプロパティなど、追加のプロファイル情報を提供します。この情報は、データベースから、またはポータルの HTTP ヘッダー情報から。

その他の考慮事項

この外部 .Net アプリケーションにサード パーティの認証プロバイダーを使用しているため、どのユーザー/グループが管理者であるかをこの .Net アプリケーションに伝える方法を理解する必要があります。私はあなたにそれを言うことはできません.サードパーティの.Netアプリケーションからそれを見つける必要があります. これは、この .Net アプリケーションでアカウントを持つ以外に何かを行うために必要なアクセス許可がある場合に必要です。

これはポータルで使用しているため、いくつかの使用方法があります。.Net Web アプリケーション全体を表示する 1 つの大きなポートレットだけを持つことができます。また、.Net Web アプリケーションの一部を表示する小さなポートレットを多数作成することもできます。いずれにせよ、ポータル ページの小さなポートレット ボックス内に完全な .Net アプリケーションを配置する場合、ポータルが適切にレンダリングする場合とレンダリングしない場合があることを考慮する必要があります。HTML の見た目や動作がおかしくなったら、それを修正するのは面倒です。元の .Net Web アプリを修正して別の HTML を吐き出すか、IIS にモジュールを追加してその場で HTML を書き換えることができます (それがモジュールであるかどうかは完全にはわかりません... IIS を掘り下げて、これを行う方法を理解する必要があります)。

うわー！

これがすべてを網羅しているわけではないことはわかっていますが、Microsoft の SQL Server Reporting Services の認証ソースとして Plumtree Portal (現在は BEA の Aqualogic User Interaction) を設定する作業を行い、IIS ベースのカスタム認証プロバイダーを実装しました。 Dynamics NAV テーブルに格納されているユーザー メンバーシップ。これらのプロジェクトでの私の経験が、この外部 .Net アプリケーションをポータルに統合する際に役立つことを願っています。

Tim
于 2009-07-06T19:20:46.403 に答える
0

他の回答が欠落している小さな点の 1 つは、asp.net のフォーム認証がクロス認証をサポートしていることです。

フォーム認証タグには、ドメインと Cookie 名のプロパティがあります。

これらを一致させ、同じマシン キーを使用すると、アプリ間の相互認証が可能になります。

ただし、各サイトのメンバーシップ プロバイダーは同じデータストアを指す必要があります。

于 2012-08-30T06:47:29.330 に答える