2

I am looking into using WCF built-in functionality to aid me in implementing an authorization service that sits on top of WCF. I already have tables such as:

User, Role, Permission (I also have composite entities: UserRole and RolePermission).

The Permission objects have custom properties like bool CanRead, bool CanWrite. The roles can contain many permissions.

How does this tie into WCF's existing framework for authorization? I'd like try not to reinvent the wheel as much as possible. How do I use my own permissions? I can see how the roles work from the .NET examples but not my own custom Permission entities. Any hints to get me started in the right direction?

BartoszKP
  • 34,786
  • 15
  • 102
  • 130
Torbjørn Kristoffersen
  • 808
  • 12
  • 23
  • How you do it depends on how your service is set up (is it available over the web, or just the local network?) and which bindings you are using. For example, NetTcpBinding should be able to make use of windows identities etc. if your service is just running on the local network. Can you give us more information? :) – Franchesca Jul 07 '11 at 11:31

1 Answers1

8

This article gives a basic overview of the normal way of doing this. Basically you construct a custom principal that contains the data relevant to a user's permissions in an IAuthorizationPolicy and attach the custom principal to the WCF OperationContext. This guarantees that regardless of how the threads are managed you can always access this principal via Thread.CurrentPrincipal.

If your permissions are simply based on role membership you can simply use standard mechanisms like PrincipalPermission.Demand() or wrapping your operations with PrincipalPermissionAttribute.

Alternatively if you have more sophisticated permissions (e.g. Create | Delete | Update etc.), one approach would be to create a custom permission that implements IPermission. This approach also works well for things like value based permissions (e.g. approve orders up to $500). In your code you can then construct the required permission and have it call Demand() to check whether your current custom principal is permitted. If these permissions can be made serializable it often also makes sense to create a companion attribute to support declarative security that uses each permission.

The above approaches integrate nicely with WCF and the .NET security infrastructure and once you get your head around IPermission provide an elegant and maintainable solution.

BartoszKP
  • 34,786
  • 15
  • 102
  • 130
Phil Degenhardt
  • 7,215
  • 3
  • 35
  • 46
  • Hi .I have the same problem could you please take a look at this :https://stackoverflow.com/questions/45770217/my-customauthorizationpolicy-evaluate-method-never-fires – Ehsan Akbar Aug 21 '17 at 07:27