Geek Answers Handbook

WCF Role Based Security Flow Through Interface

I am looking for some guidance on managing the following scenario: current permissions from the WCF service level to the interface:

I have WCF services with methods that have been decorated with the PrincipalPermission attribute. I would like to allow the client to check if they have the necessary permissions before calling the method.

The main example of this can be checking whether a user can perform a certain function (for example, send an order), which can then be used to enable / disable a button in the user interface.

Possible parameters can be added chatty operations, such as bool CanSubmitOrder() , or instead of one OrderServicePermissions GetPermissions() method, which returns a message with the CanSubmitOrder property? Then I can set the “Send order” button state to on.

Does anyone know a better approach or even best practice?

Thanks in advance!

+4
source share
3 answers

The whole point of having PrincipalPermission attributes in your service calls is that you do not need to check in advance if the caller has the right to call - if he does not, the WCF runtime will throw an exception.

Why not just rely on this built-in mechanism? Why not just put your utility calls in a try..catch block and handle exceptions if they really happen? In any case, this should be an “exceptional” case, right?

I do not see any other “magical” way besides what you described. But common practice would be to raise and handle any exceptions if they occur.

Mark

0
source

Well, if you can use your applications to use the Windows Identity Foundation (WIF) to protect your services, you can achieve this by using the DisplayToken RequestSecurityTokenResponse property.

http://msdn.microsoft.com/en-us/library/microsoft.identitymodel.protocols.wstrust.requestsecuritytokenresponse.requesteddisplaytoken.aspx

Assuming that your security token service supports it, the display token may contain a set of requirements that will allow you to transfer your permissions to the user interface, say disable controls that are bound to services that the user cannot invoke. The display token is an extension for WS-Trust that was implemented for CardSpace, so it is unlikely to be widely supported outside the Windows world.

Remember that some people think that the display token is bad news and violates the 1st law of identity:

http://www.francisshanahan.com

While other people consider this a reasonable and pragmatic solution to a common problem:

http://blogs.msdn.com/b/vbertocci/archive/2007/10/31/on-displaytoken.aspx

0
source

There are two general types for implementing validation logic:

  • Share the library. Example: "RIA Services + Silverlight".

    Advantages: easy to implement.

    Disadvantages: no compatibility (only .NET); the required client update for each library replacement.

  • Implementation of a general method check in the service part. Pros: interoperability, no need to update the client when changing the verification logic

    Minuses: it can be difficult because it is only for you

If we use SOA, it’s better to use the second option, unless you only use applications in your company, where .NET is everywhere.

Example

Consider a general example. We have a windows / wpf form. And there are two fields: "last name" of type string, "age" of type int; and the "Save" button. We need to do some client side validation

1) for some users the "Save" button is disabled;

2) the surname cannot be empty, and the maximum length is 256;

3) age cannot be less than 0;

Call save method -

 void Save(string surname, int age);

Create a second method in the service that returns a PermissonAnswerDTO object type with validation information;

 PermissonAnswerDTO SaveValidate(string surname, int age);

and the main verification method

 // If arguments are wrong [FaultContract(typeof(NotSupportedException))] // If the user have permisson to invoke this method [FaultContract(typeof(CustomNotEnoughPermission))] PermissonAnswerDTO Validate(string methodName, object[] methodParams);

Validation

Call Validate("SaveValidate", null) when the window loads. If an exception of type CustomNotEnoughPermission is selected, we block the "Save" button.

If the user can save, then call Validate("SaveValidate", object[2]{"Surname", "-60"}; user data Validate("SaveValidate", object[2]{"Surname", "-60"}; ;. -60 is invalid, so we get a response object of type PermissonAnswerDTO with the information:

 ParameterName: "age", ExceptionMessage: "age cannot be less then null".

And we can gracefully show this information to the user.

My thought about this is that one day Microsoft will do it and offer a new technology, as it always does. Basically, Microsoft technologies are really not as revolutionary as they are advertised. Examples are the Windows Identity Foundation and Reactive Extensions.

Full example

 [DataContract] public class ParameterExceptionExplanaitonDTO { [DataMember] public string ParameterName; [DataMember] public string ExceptionMessage; } [DataContract] public class PermissonAnswerDTO { [DataMember] public bool IsValid; [DataMember] public ParameterExceptionExplanaitonDTO[] ParameterExceptions; } public class Service1 : WcfContracts.IService1 { // If arguments are wrong [FaultContract(typeof(NotSupportedException))] // If the user have permisson to invoke this method [FaultContract(typeof(CustomNotEnoughPermission))] public PermissonAnswerDTO Validate(string methodName, object[] methodParams) { //1) Using Reflection find the method with name = <methodName + Validate> //2) Using Reflection cast each object in "object[] methodParams" to the required type //3) Invoke method } private PermissonAnswerDTO GetUserNameValidate(int id) { //logic to check param } public string GetUserName(int id) { // if the user calls method we need validate parameter GetUserNameValidate(id); //some logic to retreive name } }
0
source

More articles:


All Articles