CODEWITHSUNDEEP
c#.netwcfauthenticationauthorization
simpleusr
simpleusr

Reputation: 374

WCF - How to design service authorization per operation OperationContract

My task is to put an authorization policy to existing / legacy wcf services. Currently there is no authorization in the system. Basichttp based custom binding is being used to handle security. ( The client is sending username / pwd in encrypted form and on the server side, database check is performed upon receiving request. At this point an expirable token is generated in and put to server memory for further security checks) Moral of the story, everything is implemented in a custom way (security features of the framework like STS, certificates and etc. are not utilized) In the service layer no authentication check is done according to client identity. Theoretically, every client can perform every operation as long as he /she has a valid username / pwd pair.

As I said, my task is to implement an authorization policy on this legacy system.

I am relatively new to wcf and my feeling is that authentication and authorization is VERY TIGHTLY COUPLED in wcf.

It seems that there are various alternatives ( http://msdn.microsoft.com/en-us/library/ff648151.aspx ) like :

*Using the ASP.NET Role Manager for role authorization,

*using the SQL Server role provider for role authorization, and etc.

I feel that custom authorization policy would be the most suitable alternative for me but the custom samples http://msdn.microsoft.com/en-us/library/ms731774(v=vs.110).aspx also seem to be mixing authentication policy with authorization policy. I could not find a working good sample that implements a custom authorization without any special authentication policy. As you can guess, in the current legacy system security is handled in a custom way and I can not change that i.e I can not use any ws-* bindings.

What I am thinking as a possible solution is:

1) Create a custom attribute that implements ParameterInspector or MessageInspector

2) Decorate all the existing operationcontracts with this new custom attribute

3) In BeforeCall or AfterReceiveRequest methods, apply the custom authentication logic (This custom logic will most likely be associate users with roles and roles with allowed operations).

Rejecting the request will be by throwing an exception and showing the message appropriately in the client side.

My question is, how elegant is this approach? Considering the other restrictions of the legacy system are there more elegant alternatives? Am I missing some parts or are authentication and authorization really very tightly coupled in wcf?

Upvotes: 1

Views: 2786

Answers (2)

David Brossard
David Brossard

Reputation: 13832

I would use an external authorization framework altogether and then apply a MessageInspector. The externalized authorization architecture would be as follows:

Externalized authorization management is about decoupling your business logic from your authorization logic. It's great when building new apps efficiently and it's great when updating legacy apps - especially web services where you can easily intercept a flow. Have a look at Gartner's report on externalized authorization.

For your problem more at hand, I recommend you use XACML, the eXtensible Access Control Markup Language. It's an OASIS standard that provides you with:

  • a policy language to define policy-based access control authorization
  • a flexible architecture with the notions of:
    • a policy enforcement point or PEP which intercepts your flow and protects your WCF services. In your case you should use a PEP that implements a MessageInspector
    • a policy decision point or PDP which receives the requests from the PEP and produces decisions based on the policies it is configured with.
  • a request/response scheme which defines how the PEP and PDP talk together.

Here's a diagram that sketches out the way you would want your system:

Protecting WCF web services using the XACML architecture

If you need a .NET PDP, you can get one from Axiomatics (disclaimer: this is the company I work for).

HTH

Upvotes: 1

ZZZ
ZZZ

Reputation: 2812

In the old days, basically you could use declarative programming to decorate each operation implementation with PrincipalPermissionAttribute with role name, then in Web.config you plugin ASP.NET MembershipProvider and RoleProvider etc. And if you want more fine grained policy control, you could write a few IAuthorizationPolicy implementations, as you had already found our in those MSDN references in your question.

So you expect more elegant alternatives, even if your purposed designs might be working. Being elegant:

  1. Adequate security
  2. Least codes
  3. Least complexity in application
  4. Easy to evolve

This article "Authentication and Authorization with ASP.NET Identity 2.0 for WCF Services" might give you some light.

And there exists many articles about the reasons why using Identity 2.0.

Upvotes: 2

Related Questions