ASP .Net MVC and WCF Identity (Claims) Integration

Question

We're building a platform where the client is an ASP .Net MVC one, using ASP Net Identity 2.0 for authentication and authorization (using Claims), which works great on the web side.

We also have a WCF service which allows CRUD operations on the database (for multiple client applications), which gets requests from this ASP .Net MVC client. As we want to validate (authenticate & authorize) the user before making specific CRUD actions in the WCF side, we need to get the claims of the user from the client, and perform the validations (preferably in a very clean manner using headers or any binding that WCF will be able to support for this matter).

I've been searching the different forums but with no simple answer\tutorial to this specific scenario. Can anyone assist on this matter?

Thanks, Nir.

Maidenhair

Nir, your issue seems to be passing the claims to your WCF Service. You can pass the actual claims you get from Identity, or you can pass an array or DTO the values that represent the authorizations and Id's you want to pass on to your service... – Rodrick

@nirpi, what do you want your service to consume: credentials or security token? – Autophyte

@DaveAlperovich, I'd like to get the claims from the header, if possible, so I would not need to "dirty" all my public methods with additional parameters for authentication. – Maidenhair

@LeonidVasilyev, I'd like my service to get the authenticated user with its claims, if possible. Another option will be to get a token, and then somehow get the user + claims from somewhere (preferably via cache), but not sure if this can be done. – Maidenhair

You can do that with WCF's. I would use a Web API. Easier to incorporate Identity. I have no doubt Identity can be used in WCF's, but it's not already configured this way. – Rodrick

Answer 1

I love this:

in your IEndpointBehavior implementation do this on the client end:

public object BeforeSendRequest(ref Message request, IClientChannel channel)
    {
        request.Headers.Add(MessageHeader.CreateHeader("token", "http://myurl.com/service/token", _theToken));
        return null;
    }

then on the service end add this to your ServiceAuthenticationManager

public override ReadOnlyCollection<IAuthorizationPolicy> Authenticate(
        ReadOnlyCollection<IAuthorizationPolicy> authPolicy, Uri listenUri, ref Message message)
    {
        IPrincipal user = new MyUserPrincipal(null);

        if(_currentServiceContractType.GetInterfaces()
                                        .Any(x => x == typeof(IMySecuredService)))
        {
            var tokenPosition = message.Headers.FindHeader("token", "http://myurl.com/service/token");

            if (tokenPosition >= 0 && tokenPosition <= 5)
            {
                var encryptedToken = message.Headers.GetHeader<string>(tokenPosition);

                if (!string.IsNullOrWhiteSpace(encryptedToken))
                {
                    var serializedToken = new MyEncryptionUtility().Decrypt(encryptedToken);
                    var token = MyTokenSerializer.Deserialize(serializedToken);
                    var expire = new DateTime(token.ValidToTicks);
                    if (expire > DateTime.Now)
                    {
                        user = new MyUserPrincipal(token);
                    }
                }
            }   
        }
        message.Properties["Principal"] = user;
        Thread.CurrentPrincipal = user;
        return authPolicy;
    }

This gives you then the ability to use the built in claims or WIF claims authentication. Eitherway, this is very simple. The token is created by the service and sent to the client (web) and stored in the cookie. then when there are any requests, the token is grabbed from a cookie and then sent along to the service, where, inevitably you can start adding permissions service side, versus doing them on the web/mvc side, making a much cleaner code base using everyone's favorite friend, SOA >= :)

Pavis