WCF REST 4.0 Authorization with Form Based authentication (SetAuthCookie)

Introduction

Windows Communication Foundation provides tons of methods to authenticate users' check for authorization based on service type that it's quite confusing to implement simple form based authentication and role based authorization for WCF REST 4.0.

Note: This article assumes that WCF REST service is hosted with ASP.NET application and shares the same web.config. Make sure that Form Authentication is enabled in web.config file.

Background

There are many ways to authenticate and authorize user in WCF Service, but in this example, authentication cookie will already be created by login page and that will be used by subsequent requests made to REST service for authorization.

Using the Code

A typical way to authorize user for specific role is to use Principal Permission attribute. Something like this:

WebGet(UriTemplate = "")]
[PrincipalPermission(SecurityAction.Demand, Role="Admin")]
public List<SampleItem> GetCollection(){} 

But even though after user is authenticated using Membership provider and HTTPContext.Current.User.Identity and the context is available at service level, the principal permission attribute always throws a security exception.

The reason for that is because principal permission attribute checks for System.Threading.Thread.CurrentPrincipal.Identity and not for HTTPContext Identity.

To solve this problem, we have to create a Custom Principal and Authorization Policy for WCF Service. Then this Policy will be hooked with WCF REST Service using ServiceBehaviour.

Custom Principal

Here is the code for custom principal:

 public class CustomPrincipal: IPrincipal
    {
        private IIdentity _identity;
        public IIdentity Identity
        {
            get
            {
                return _identity;
            }
        }

        public CustomPrincipal(IIdentity identity)
        {
            _identity = identity;           
        }

        public bool IsInRole(string role)
        {
            return Roles.IsUserInRole(role);
        } 
} 

Here AspNet Membership Role provider is used to verify if the user is in a particular role for not. We can have our custom implementation that does not user Membership provider.

Authorization Policy

Now create Authorization policy that sets the Custom Principal to the evaluation context:

public class AuthorizationPolicy : IAuthorizationPolicy
    {
        string id = Guid.NewGuid().ToString();

        public string Id
        {
            get { return this.id; }
        }

        public System.IdentityModel.Claims.ClaimSet Issuer
        {
            get { return System.IdentityModel.Claims.ClaimSet.System; }
        }

        // this method gets called after the authentication stage
        public bool Evaluate(EvaluationContext evaluationContext, ref object state)
        {
            // get the authenticated client identity
            IIdentity client = HttpContext.Current.User.Identity; 
            
            // set the custom principal
            evaluationContext.Properties["Principal"] = new CustomPrincipal(client);

            return true;
        }              
    }  

If you look closely, the custom principal is created using HTTPContext Identity that was created after user is authenticated using membership provider and authentication cookie is set after validating the user. Something like this:

FormsAuthentication.SetAuthCookie(username, false);

Attach Authorization Policy to the WCF

This can be done by creating service behavior in web.config file. But here, I have created custom service behavior by implementing IServiceBehavior and attach the authorization policy to it.

[AttributeUsage(AttributeTargets.Class)]
public class SecurityBehaviorAttribute : Attribute, IServiceBehavior
{
    public void ApplyDispatchBehavior(ServiceDescription serviceDescription, 
    	System.ServiceModel.ServiceHostBase serviceHostBase)
    {
        List<IAuthorizationPolicy> policies = new List<IAuthorizationPolicy>();
        policies.Add(new AuthorizationPolicy());
        serviceHostBase.Authorization.ExternalAuthorizationPolicies = 
						policies.AsReadOnly();

        ServiceAuthorizationBehavior bh =
            serviceDescription.Behaviors.Find<ServiceAuthorizationBehavior>();
        if (bh != null)
        {
            bh.PrincipalPermissionMode = PrincipalPermissionMode.Custom;
        }
        else
            throw new NotSupportedException();
    }

    public void AddBindingParameters(ServiceDescription serviceDescription, 
    	System.ServiceModel.ServiceHostBase serviceHostBase, 
    	System.Collections.ObjectModel.Collection<ServiceEndpoint> endpoints, 
    	System.ServiceModel.Channels.BindingParameterCollection bindingParameters) { }

    public void Validate(ServiceDescription serviceDescription, 
    	System.ServiceModel.ServiceHostBase serviceHostBase) { }
}

Here, ServiceAuthorizationBehavior PrincipalPermissionMode is set to Custom and Authorization policy is added to the servicehost.

Service Code

Make sure that service behavior is added as attribute to the service class.

    [ServiceContract]
    [AspNetCompatibilityRequirements(RequirementsMode = 
		AspNetCompatibilityRequirementsMode.Allowed)]
    [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
    [SecurityBehavior]    
    public class Service1  {
        [WebGet(UriTemplate = "")]
        [PrincipalPermission(SecurityAction.Demand, Role="Admin")]
        public List<SampleItem> GetCollection()
        {
            var value =  System.Web.HttpContext.Current.User.Identity.IsAuthenticated;
            return new List<SampleItem>() { new SampleItem() 
				{ Id = 1, StringValue = "Hello" } };
        }
} 

That's all. Now we can add PrincipalPermission attribute to any web method and authorize user for specific role. We can also implement custom PrincipalPermission attribute to control the granularity of authorization.

Note: We can also create Authentication service to validate user name password and create authentication cookie after validation. Here, the assumption is that WCF REST is hosted with Web application and therefore shares the context.

Let me know if there is any better way to achieve the same thing without providing user name and password at each request.