I was reading a post by Tim Greenfield today regarding RIA and security. He also followed this up with a nice post on how to implement one of his techniques using sessions. Taking this from the Silverlight RIA perspective this has some interesting turns. His scenarios are compelling as any information from Silverlight to the server can be sniffed out using a tool like Fiddler. So repeatedly sending credentials is not a good idea. Also, storing credentials in the hard drive of the client can have its own issues. So what to do?
One option Tim throws out there is a token technique. The user logs in and is handed back a token (or session ID). This can be done by assigning tokens server side with some sort of expiration on them. The token is then sent from the client to the server with each call. This can be a pain in some senses since it literally has to be sent in each call as a parameter or wrapped inside of some HTTP header, but it works.
Another option with Silverlight is to use Forms Authentication. The user logs into the client application and it passes their username and password to the server via some HTTP web service. The service uses Forms Authentication to check with its provider to make sure this is a valid user. If so the user is registered as a authenticated user and e s/he may proceed. One subsequent calls the server side services first check to make sure the user is authenticated (and possibly in a specific role) before allowing any call to continue. This interception of the call acts as a bouncer at the door to refuse entry from anyone not authenticated.
As Silverlight continues to grow, this topic is going to become more critical for many developers. I plan on producing a few materials at my site to help explain some of the options over the next few months. But for now, I recommend Tim Heuer’s nice post on security that shows how to do this on www.silverlight.net in the learning section.