When we write Windows apps everything happens on one computer (unless you're getting data from the network. You click the mouse, your event handler gets called, you can change what's displayed.
Then, with the internet, you've got a stateless environment where (Javascript aside for a moment) all the code gets executed on the server. Using ASP.Net static HTML gets generated, and pushed to the client. In return the user can take an action, the server will get another request, and so on.
With Silverlight everything's happening on the client - the Xap is downloaded, decompressed, and run. The problem is, not everything can be done in the Silverlight app - it's not like a Windows app, which can ope/save files from the hard disk - it's more like a Asp.Net app. Problem is, the data's over on the server, the Silverlight app is on the client. So developers need to write asyncronous code (so that the UI doesn't freeze). This is more complex than the syncronous event handling Windows developers are used to. Furthermore, every time you need to get data, such as authenticating the user, it's back to the server to check. So while Silverlight looks like "WPF in the browser" it's really a very different style of programming. A web developer will be familiar with this, but the standard business dev who wants to start using Silverlight will find this a lot of overhead.
So .Net RIA services tries to bring the convenience of Windows development to Silverlight. It does this by providing a framework for doing things like providing the ability to share .net types between clientserver, which can act in a stateful fashion on the client and transfer data back to the server using rest xml/json services.
One example service is provided for user authentication/authorisation/settings.
I would recommend you look at this article by Nikhil Kothari and also this (PDF) walkthrough. Also look at some of the provided samples and try running/modifying them.