具有角色的 WCF PrimaryPermission，为子方法进行配置
我想让它尽可能简单，所以我不会发布任何代码，因为它可能只会让事情变得混乱。
我已经使用 WCF 基于角色的授权在我的应用程序中实现了安全性。
假设我公开的接口上有 4 个方法
- GetPerson
- DeletePerson
- UpdatePerson
- GetSurnameAndForename
我已将 附加
[PrincipalPermission(SecurityAction.Demand,Role="POWERUSER")]
到前 3 个方法，将
[PrincipalPermission(SecurityAction.Demand,Role="GENERALUSER")]
附加到最后一个方法。
这工作得很好，并且可以防止“GENERALUSER”访问前 3 个方法。
但是，方法 GetSurnameAndForename 在内部调用 GetPerson 方法，该方法失败。我明白为什么它会失败，但是有没有一种首选方法可以允许 GetSurnameAndForename 在没有 POWERUSER 角色的情况下调用 GetPerson ？
我能想到的唯一方法是在 IsInRole 方法中添加额外的检查来检查 CallStack 以查看此调用是否来自内部方法或外部调用。这个解决方案有效，但不是很优雅。
I want to keep this as simple as possible, so I'm not posting any code,as it will probably just confuse things.
I have implemented security in my application using WCF's role based authorisation.
Assume that I have 4 methods on my publicly exposed interface
- GetPerson
- DeletePerson
- UpdatePerson
- GetSurnameAndForename
I have attached the
[PrincipalPermission(SecurityAction.Demand,Role="POWERUSER")]
to the first 3, and the
[PrincipalPermission(SecurityAction.Demand,Role="GENERALUSER")]
to the final one.
This works fine, and prevents a 'GENERALUSER' from accessing the first 3 methods.
However the method GetSurnameAndForename internally calls the GetPerson method, which fails. I understand why it fails, but is there a preferred way to allow GetSurnameAndForename to call GetPerson withouth having the POWERUSER role ?
The only way I can think of doing this, is adding an extra check in the IsInRole method to check the CallStack to see if this call has come from an internal method, or an external call. This solution works, but it's not very elegant.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，有一个非常简单的解决方案。将
GetPerson提供的逻辑包装到私有方法，并从GetPerson和GetSurnameAndForename调用该新方法。Yes there is very easy solution. Wrap the logic offered by
GetPersonto private method and call that new method from bothGetPersonandGetSurnameAndForename.使用主体权限属性保护的纵横交错的边界会导致灾难。
Crisscrossing boundaries secured with Principal Permission Attributes is a recipe for disaster.