Authenticating + Authroizing Silverlight Client to WCF Web-service

Question

I have a situation where I have a web-service, serving data (images, media etc) which needs to be secured so that it can only be accessed by the appropriate Silverlight client. There may be many, with some having access to some media and some having access to others.

The web-service exists and it's current a .asmx, but we are going to upgrade this to WFC.

So far, after reading lots of blogs on WCF and authorisation, I've come to this idea:

1. Each silverlight client has a client key somewhere in its config.
2. Web-service server is secured by SSL so the client ID is encrypted as a web-service parameter.
3. Authentication is done via the client key.
4. Authorization is done via the client key.

As far as I can see, I think this should be secure, but please feel free to poke holes!

The only thing that bugs me is from my research there is so much favour towards using WCF for authentication and authorisation, but to me it just feels too complicated for what I need! Let alone understanding how the complicated client config files would work for a Silverlight application accessing the WCF service.

Either way, from my understanding, using WCF authentication requires at least a user name and password or certificate, both of which feel really clumsy, over just giving out a nice client key instead.

Do my idea seem secure and sensible, or should I persist with my WFC learning as the framework is a better solution?

If the WCF framework for security is prefered, is there any high level advice you can give me as to what sort of flow I would need to secure my web service?

Look forward to hearing peoples advice and experience! :)

Thanks a lot!

Andy

Answer 1

This way isn't secure, because silverlight is client side technology, so both SL control and their config stores at user computer. So any user can freely access/change key.
Custom sessions is most secured way to handle your task.
For example:
Authentication/Authorization may be implemented using standard (or custom, you should feel free to implement some specific provider) roles/membership providers. After client was authenticated it receives server generated session token (for example guid). Same guid stores in server side database (for example in database which store all roles, users, etc.).
Each session token have expiration (use DB agents/tasks/shedulers to remove expired keys from database).
So each time client requests for some resource it send to server its session token as well as other request parameters. After receiving request server search for same session token in DB and in case if token exists, provide access to requested resource. Otherwise authentication fails.

Custom sessions is pretty complicated but in same time most secured way to handle auth operations. Feel free to ask me if you have some questions about it.