2009-07-13 12 views
2

私は、必要なセキュリティ計画を持つことができるカスタムメンバーシッププロバイダを構築することに取り組んでいます。MembershipProviderのセキュリティパラダイムを変更するにはどうすればよいですか?

私は自分のIPrincipal、IIdentity、およびMembershipProviderを持っています。私は正常に動作している認証があります。私が今実行している問題は承認です。

私が認可スキームで持っている問題は、IPrincipalのIsInRoleビヘイビアにinherintlyです。この動作は、ASP.NET Webフォームのさまざまな機能と密接に結びついています。できるだけ使用したいので、サイトマップの承認が主な関心事です。

だから、あなたは伝統的に、サイトマップそれほど似ている可能性があります:

ここ
<siteMap xmlns="blahblah"> 
    <siteMapNode url="PersonView.aspx" 
     title="View Person" 
     description="View the details of a person" 
     roles="ViewerRole" /> 
</siteMap> 

、PersonView.aspxページに移動しようとしている誰もがViewerRoleを持っている必要があります。これが私の問題の原因です。私は自分の権限をユーザーの役割に結びつけたくない。代わりに、私が実行している動作に認証を結びつけ、背後にあるいくつかの根本的なことを認可の対象にします。

それでは、私が本当にしたいことは、代わりにこのようなものです:

<siteMap xmlns="blahblah"> 
    <siteMapNode url="PersonView.aspx" 
     title="View Person" 
     description="View the details of a person" 
     roles="Person|View" /> 
</siteMap> 

これはPersonView.aspxページに移動しようとしている誰と解釈されるべきであるビジネス・オブジェクトへビュー権利を持っている必要があります。

public static bool Authorize(Type type, Access access, IUser user) 

、例えば、Person型、ビューのアクセス(列挙型)、およびに対してそれをチェックするために、ユーザがかかります。

は、私はまだのようなシグネチャを持つオーソオブジェクトを持っています。さて、Authorizeの中にコードがありました。

私の問題は、IPrincipalのIsInRoleからどのように私の認証に到達するのですか?私は別のものを試しましたが、どれもうまくいかないようです。私は本当に魔法のストリングのアプローチが嫌いですが、私はそれに固執しているようです。強く型付けされた方法でそれを構築する方法があったなら、私は間違いなくそれを好むでしょう。私が考えていないより良い方法がありますか?

答えて

1

Anot彼女の方法私はこのようなことをやったことが、すべての権利とオブジェクトをプリンシパルの役割として保存するようにユーザーを初期化することだと考えています。あなたが持っているオブジェクトの数に応じて、別のオプションかもしれません。本質的に、あなたはAuthorizerを取り除くでしょう。コールを許可し、店舗

  • ビュー|人
  • 編集|人
  • 追加|ペロン

3として異なる役割。私はこれをフィーチャーA→フィーチャーB、CまたはDのようにフィーチャーA、フィーチャーB、フィーチャーDを持つ可能性があるフィーチャーの階層を持つシステムで使用しています。 :だからD

今、彼らはか、サブ機能をチェックする必要があるかどうかをチェックすることができた場合、あなたのコードを確認することができます| |

  • A | BまたはA | CまたはA、Bを。

    提案

    あなたがやったらどうあなたのページのロード中を独自の実装にもよりよいようにするには:

    if (Context.User.IsInRole(
         PermissionFactory.CreateToken(AuthorizationType.Person,Access.View))) 
    {   
        //I have view rights, do some stuff  
    } 
    

    今、あなたは、これがcompletly文字列であるという事実を隠されてきました。

+0

あなたの提案をありがとうJosh、私はPermissionFactoryを使って魔法のストリングの生成を隔離する考えが好きです。しかし、トークンの生成は実際にはサイトマップ内で有用ではありません。このシナリオでは、どのようにサイトマップを扱いますか?彼らは魔法の弦を保つ? – Joseph

+0

サイトマップを動的に構築する場合は、文字列を隠すことができますが、その日の終わりにはまだ文字列になります。私は役割の仕組みが決して好きではありませんでした。ロールは非常に広いので、ロールと能力が常に必要です。これがモデルに焼かれていて、うまくいけばいいと思います。 – JoshBerke

+0

@ジョッシュ私のパラダイムは根本的に異なるので、私はそれを全面的に戦わなければならない。それは本当に面倒です。 – Joseph

1

私は問題を解決するためにかなりきれいな方法を考え出しました。私がしたのは、型の代わりに列挙型を受け入れるようにAuthorizeシグネチャを変更し、それをIsInRoleで使用してパーミッションを判断することでした。

だから私は持っている:

public static bool Authorize(AuthorizationType type, Access access, IUser user) 

をして、私はそうのようにIsInRoleでそれを使用します。

public bool IsInRole(string role) 
{ 
    var typeAndAccess = role.Split('|'); 
    var authType = 
     (AuthorizationType)Enum.Parse(
      typeof(AuthorizationType), typeAndAccess[0]); 
    var access = (Access)Enum.Parse(typeof(Access), typeAndAccess[1]); 

    return Authorizer.Authorize(
     authType, access, Context.User.Identity as IUser); 
} 

これは、私は絶対のように(しなければならないとき、私は魔法の文字列のアプローチを使用することができますsitemap)を使用していますが、プログラマチックに次のようにプログラムを使用している場合は、より厳密に型指定されたアプローチが可能です。

void Page_Load(...) 
{ 
    if (Context.User.IsInRole(AuthorizationType.Person + '|' + Access.View) 
    { 
     //I have view rights, do some stuff 
    } 
} 
関連する問題