Application Authentication on a Peer Network using WCF

When figuring out how I was going to do authentication for Ulysses Agenda, I had a couple of design issues. The first is that the user needs to be persisted somewhere other than the game client itself - can't have players modifying their own data like the good old days of Nethack and Trek for Unix (yes, I am THAT old.. now get off my yard you whippersnappers!!).

So, I really had two competing alternatives as far as patterns go:

1. Client/Server or "Traditional" service-based approach - In this approach, the Universe Server would self-host an authentication service. The game clients could then be built by using automated tools to suck the metadata out of the service, build proxy clients, and finally allow them to connect at runtime and invoke the remote methods like Authenticate or some such.
   Pros: None that I can think of :)
   Cons: Not very scalable (client needs to know exactly where the US resides, including its IP and port), Requires me to suck metadata out of the service in order to build the client, which means anytime I change the service I have to bend over backwards to rebuild the client, and its difficult to decouple the auth service from the US in case I want to handle authentication elsewhere.
2. The Bus Approach - Using this model, clients drop a set of credentials onto the bus at the mesh net.p2p://ulyssesagenda/auth. Any application listening on the bus at that particular mesh address can pick up the credentials, validate them, and drop an authentication ack (acknowledgement) message back onto the bus. The clients are, of course, listening for authentication acks. If they get one for the user that is using that particular client, features become unlocked and the player is "logged in".
   Pros: Unbelievably scalable, pluggable, and maintainable. Loosely coupled and can be detached, re-attached, and swapped out. Authenticators can even be created by third parties and hosted in separate applications that happen to be listening on the auth mesh of the bus. Also, this approach is freaking cool.
   Cons: Admittedly it is hard for some programmers to wrap their heads around this style of programming (however, anybody who has done any middleware programming is extremely familiar with this approach as it wreaks of ESB), takes a little more know-how and a few more lines of code to implement.

So I opted for approach #2. The use case is like this:

User fires up their Ulysses Agenda client and is prompted for their credentials. They hit OK after submitting their credentials. The credentials go out on the wire and the client has no idea about the location or physical configuration of the authenticator. All it knows is that some service, sitting somewhere on the wire, conforms to the IAuthenticator interface. The client application then greys out the GUI and says something like "Waiting for Network Authentication...". What should hopefully only be a few milliseconds later, a message comes into the client that invokes the AuthenticatorAck method on the client. This method is invoked when an authenticator validates a set of credentials on the net.p2p://ulyssesagenda/auth mesh.

So how does it all work. First, we start with the contract for the IAuthenticator service and for the channel it resides on, IAuthenticatorChannel:

using System;
using System.Collections.Generic;
using System.Text;
using System.ServiceModel;
using System.Runtime.Serialization;
 




namespace UlyssesAgenda.NetworkLibrary
{
    [ServiceContract(CallbackContract=typeof(IAuthenticator))]
    public interface IAuthenticator
    {
        [OperationContract(IsOneWay=true)]
        void Authenticate(string userName, string password);

        
        [OperationContract(IsOneWay = true)]
        void AuthenticateAck(string userName, Guid authToken);
    }

    
    public interface IAuthenticatorChannel : IAuthenticator, IClientChannel
    {  
    }
}

What's interesting is that the game clients will have an implementation for the AuthenticateAck method while the authentication server will have an implementation for the Authenticate method, which actually calls the AuthenticateAck method on the mesh (remember that calling a method on a mesh is essentially equivalent to invoking a remote method on every client in a peer network.. though WCF optimizes the call paths immensely).

So, here's the server-side implementation that can be found inside the Universe Server application:

using System;
using System.Collections.Generic;
using System.Text;
using System.ServiceModel;
using System.Runtime.Serialization;
 
using UlyssesAgenda.NetworkLibrary;

 
namespace UlyssesAgenda.UniverseServer.NetLibImplementations
{
    public class Authenticator : IAuthenticator
    {
        #region IAuthenticator Members
        // When this receives an authenticate message, send out the ack
        // note that the authenticator has no implementation for the ack, that
        // should be in the clients.
        public void Authenticate(string userName, string password)
        {
            Console.WriteLine("Received auth request for {0}, sending Ack Back.", userName);
            CommCentral.Authenticator.AuthenticateAck(userName, Guid.NewGuid());
        }

        
        public void AuthenticateAck(string userName, Guid authToken)
        {
            // ignore messages of this type.
        }

        #endregion        
    }
}

And here's the game client implementation:

using System;
using System.Collections.Generic;
using System.Text;

 
using UlyssesAgenda.NetworkLibrary;
 
namespace AuthTest.NetLibImplementations
{
    public class Authenticator : IAuthenticator
    {
        #region IAuthenticator Members

        
        public void Authenticate(string userName, string password)
        {
            // no implementation on clients
        }

        
        public void AuthenticateAck(string userName, Guid authToken)
        {
            Console.WriteLine("An auth server somewhere just authenticated {0} with Guid {1}", 
                   userName, authToken.ToString());
        }
        #endregion
    }
}

I personally think that I'm OK here keeping the authentication client and authentication server halves of the same coin in the same interface because, well, they're two halves of the same coin. The other alternative would be to split things into an IAuthenticatorClient and IAuthenticatorServer interface, each with a single method. To me, a single-method interface screams of over-re-factoring and probably won't buy me much. With this, I can look at the authentication contract (IAuthenticator) and quickly see that I can have applications that either perform authentications, or respond to authentications, or both - its totally flexible.

On the client, it becomes pretty simple to instantiate the service and drop credentials on the wire:

_auth = new NetLibImplementations.Authenticator();
_authSite = new InstanceContext(_auth);
_authChannelFactory = new DuplexChannelFactory<IAuthenticatorChannel>(_authSite, "AuthEndPoint");
_authProxy = (IAuthenticatorChannel)_authChannelFactory.CreateChannel();

 
_authProxy.Authenticate("Kevin", "Password");

Calling Authenticate actually calls Authenticate on all applications that are listening on the net.p2p://ulyssesagenda/auth mesh. Some clients will ignore that message (such as other game clients), while other applications will take the information and send out a message in response, such as the Universe Server's built-in authenticator.

Thoughts? Opinions? Hate mail? (well you can leave the hate mail off.. I'd just censor you anyway)

tags: ulysses  wpf  wcf  networking  programming  gaming  esb  soa  

links: digg this    del.icio.us    technorati    reddit