Flowing WCF Role-Based Security through to UI

Question

I am looking for some best practices on how to handle the following scenario - flowing permissions from WCF service layer through to UI:

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

A basic example of this could be checking whether a user can perform a specific function (say submitting an order), which can then be used to enable/disable a button within the UI.

Possible options are to add "chatty" operations like bool CanSubmitOrder() to the service, or instead have a single method OrderServicePermissions GetPermissions() which returns a message with a property CanSubmitOrder? I can then set the enabled state of a "Submit Order" button to the result.

So does anybody know of a better approach, or even a best practice?

Thanks in advance!

Answer 1

Well, if you are able to evolve your applications to use Windows Identity Foundation (WIF) to secure your services you could achieve this using the DisplayToken property of the RequestSecurityTokenResponse.

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

Assuming your security token service supported it, the display token could contain a claim set that would allow you to flow your permissions into the UI, say to disable controls that are bound to services the user cannot call. The display token is an extension to WS-Trust that was implemented for CardSpace so it it not likely to be very widely supported outside of the Windows world.

Be aware though, that some people think the display token is bad news and violates the 1st law of identity:

http://www.francisshanahan.com

While other people think it is a reasonable and pragmatic solution to a common problem:

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

Answer 2

There are two general type to implement checking logic:

1. Share library. Example is "RIA Services + Silverlight".

   Pluses: simple to implement.

   Minuses: no interoperability (only .NET); required client update for every library changing.

2. Implement common method validation in service part. Pluses: interoperability, no need for client update if checking logic changed

   Minuses: may be to complex because it is only on you

If we use SOA it is better to use second choice, if only you are not using applications only in your company where .NET is everywhere.

Example

Let us consider common example. We have a windows/wpf form. And there are two fields: "surname" of type string, "age" of type int; and a button "Save". We need to implement some check on client side

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

2) surname cannot be empty and max length is 256;

3) age cannot be less than 0;

Invoking method to save is

void Save(string surname, int age);

Create second method in the service, which return object type of PermissonAnswerDTO with validation information;

PermissonAnswerDTO SaveValidate(string surname, int age);

and main validation 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.

Invoke Validate("SaveValidate", null) on window loading. If exception of type CustomNotEnoughPermission is throwed then we block "Save" button.

If user can save then invoke user's data Validate("SaveValidate", object[2]{"Surname", "-60"};. -60 is not valid so we get answer object of type PermissonAnswerDTO with information:

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

And we can gracefully show this information to user.

---

My thought on this is that some day Microsoft will implement this and call as new technology as it always does. Mostly Microsoft's technologies really are not so revolutionary as it is advertised. Examples are 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
    }
}

Answer 3

The whole point of having PrincipalPermission attributes on your service calls is that you don't have to check ahead of time whether or not the caller has the rights to call - if he doesn't, the WCF runtime will throw an exception.

Why not just rely on this built-in mechanism? Why not just put your service calls in a try..catch block and handle the exceptions if they do actually occur? It should be the "exceptional" case anyway, right?

I don't see any other "magic" way besides what you described. But the generally accepted practice would be to call and handle any exceptions if they occur.

Marc