WCF and Silverlight 4.0 in N-Tier App : authenticate calls to the service

Question

I have an N-Tier app which built as follows:
On the server side in IIS7 is sitting an ASP.Net Application that exposes methods on a WCF Service. Those methods talk to the DB using EF4. Clients written in Silverlight 4.0 are calling the methods on the WCF service.

The WCF Service exposes this method :

[OperationContract]
void DeleteItem(int i_ItemId);

I am new to seuring WCF services, but I think these next observations are true (correct me if I am wrong):

1) If I leave this method/service as is, anyone that knows that my service is sitting at http://www.mysite.com/myservice.svc could just open up VisualStudio, open "Add Service Reference" and start making calls to DeleteItem().

2) If I try to solve the above by remove the MEX endpoint, Calls to the service can still be made using some manual coding.

So trying to solve those two problems I started learning about some built-in security features in WCF. After a quick look I figured i can use the following binding Configuration so that a username and password are needed for making calls to the service :

  <wsHttpBinding>
    <binding name="RequestUserName" >
      <security mode="Message">
        <message clientCredentialType="UserName"/>
      </security>
    </binding>

Trying to adopt this solution, the first thing that came to my mind was: When a user logs in the client, the client uses the user's name and password as the credentials for the WCF call. At the server-side, those credentials are validated against the DB.

The problem now, is that those credentials (userName and password) are , of course, known to the user, so he can just use them to call DeleteItem() in the ways I already mentioned.

From here I came up with two solutions :

1) Instead using userName and password as credentials, I will use a hard-coded key in the client. Scrambling the Dll's inside the XAP could prevent someone from obtaining this key.

2)When a user logs in the client, the server sends some kind of a temporary token (GUID or something), which the client can use to authenticate it's calls during this session of communication (Let's say, until the user closes the client).

My question are :

What the security level that the first solution provides and how hard you need to work in order to crack it?

If the first solution is very trivial to crack, Is there a built-in way in WCF to manage the tokens system I mention in the second solution ?

Other solutions that can feet the scope are welcomed.

Answer 1

I'm not sure about security level you are asking about, but I wouldn't feel confident storing username and password in XAP file, obfuscated or not.

I can describe a solution that I've implemented in production.

Basically, I secure the application with standard Forms Authentication, but I don't use the redirects like you normally would with ASP.NET, I use Authentication Web Service that ships with ASP.NET Forms Authentication. That way my login goes through Silverlight controls. My app has a user store that I authenticate the Authentication Service against.

To hook to the Authentication Service, I do this in Global.asax:

protected void Application_Start(object sender, EventArgs e)
{
    AuthenticationService.Authenticating += new EventHandler<AuthenticatingEventArgs>(AuthenticationService_Authenticating);
}

void AuthenticationService_Authenticating(object sender, AuthenticatingEventArgs e)
{
    try
    {
        bool authenticated = //Call your user store here.

        e.Authenticated = authenticated;
    }
    catch (Exception ex)
    {
        e.Authenticated = false;
    }
    e.AuthenticationIsComplete = true;
}

You would secure the parts of the website like you would normally with forms using <authorization> element with <deny users="?">. The browser will handle all of the cookies for you. If you wanted to secure services, under Service/ folder you would deny not authenticated users to it.

This MSDN Post talks about the solution in more detail.