Authentication is the third in a series of posts covering the key concepts of RIA Services using the Book Club application to digger deeper and go beyond the basics. Links to the first two posts on validation and authorization as well as an overview of the application/source code are at the end of this post.
Authentication Overview
Like authorization, RIA Services provides a higher level programming model, and out-of-the-box, but extensible solution. Authentication answers the question:
"Do these credentials represent a valid user?"
Credentials might be user name and password, or any other piece of data that can be used to verify that the user is who he/she says they are. Generally, a side-effect of authentication is to produce a representation of the user, usually represented as an IPrincipal, as well as establishing an authenticated session for the client to use in making subsequent requests.
RIA Service defines an authentication service as a domain service that implements IAuthetication<TUser> where TUser is application's notion of a user that brings together identity, roles and settings that span across client and server.
RIA Services also provides an out-of-box implementation based on the standard asp.net membership, roles and profile infrastructure services. If you use the business application template, this is all setup for you by default. However RIA Services also lets you implement your own authentication service when you want to use your own custom credential store, or a different authentication mechanism such as OpenID.
This post covers using authentication and the User object on client and server, as well as building a custom forms authentication service that works against the application's data model.
Using Authentication on the Client
I created an inplace-LoginControl with a number of visual states (Unauthenticated, CredentialInput, Authenticating and Authenticated) as shown here.
Authentication functionality is accessed through a class called WebContext on the client. WebContext represents the functionality provided by the home web server to the client application. This is how WebContext is initialized in the application:
public partial class WebContext {
partial void OnCreated() {
Authentication = new FormsAuthentication() {
DomainContext = new AuthenticationContext()
};
}
}
The FormsAuthentication implementation uses a DomainContext to work against the corresponding DomainService implementing IAuthentication on the server. We'll see this service implementation below.
Looking at LoginControl implementation, the authentication-related functionality is invoked when the Submit and Logout buttons are clicked:
private void OnSubmitButtonClick(object sender, RoutedEventArgs e) {
LoginParameters loginParameters =
new LoginParameters(userNameTextBox.Text, passwordBox.Password);
WebContextBase.Current.Authentication.Login(loginParameters,
delegate(LoginOperation operation) {
if (operation.HasError || (operation.LoginSuccess == false)) {
MessageBox.Show(...);
operation.MarkErrorAsHandled();
return;
}
// Use the resulting User object
userLabel.Text = "Welcome " + WebContext.Current.User.DisplayName;
}, null);
}
private void OnLogoutButtonClick(object sender, RoutedEventArgs e) {
WebContextBase.Current.Authentication.Logout(/* throwOnError */ false);
}
The resulting User object can be used imperatively as shown in the code above, or declaratively via data-bindings.
Using Authentication on the Server
The User object can also be used on the server, for example by other domain services. Here is a snippet of code from the BookShelfService:
[RequiresAuthentication]
public class BookShelfService : LinqToEntitiesDomainServiceEx<BookClubEntities> {
private User _user;
public BookShelfService(User user) {
_user = user;
}
public IQueryable<Book> GetBooks() {
return ObjectContext.Books.Where(b => b.MemberID == _user.MemberID).
OrderByDescending(b => b.AddedDate);
}
public override void Initialize(DomainServiceContext context) {
base.Initialize(context);
// This allows authorization rules to get access to the current user
AuthorizationContext customAuthContext =
new AuthorizationContext(context);
customAuthContext.Items[typeof(User)] = _user;
AuthorizationContext = customAuthContext;
}
}
The domain service has been marked with the authorization rule stating the service requires authentication. Consequently, RIA Services will ensure that there is a valid IPrincipal whenever this service is invoked. However, the service also requires a User object to be passed in into constructor, so it can use it when retrieving shared by the current user, or when initializing an AuthorizationContext to pass along the User in into authorization rules.
In order to pass in custom values through the constructor, one needs to implement a custom DomainServiceFactory. The default one only works for domain services with default parameterless constructors. In the application, I have implemented a simple domain service factory, that uses hardcoded logic, but in a larger application, the general idea is to use an IoC container and call into that from the custom DomainServiceFactory.
internal sealed class DomainServiceFactory : IDomainServiceFactory {
private IDomainServiceFactory _defaultFactory;
public DomainServiceFactory(IDomainServiceFactory defaultFactory) {
_defaultFactory = defaultFactory;
}
public DomainService CreateDomainService(Type domainServiceType, DomainServiceContext context) {
if ((domainServiceType == typeof(BookShelfService)) ||
(domainServiceType == typeof(BookClubService))) {
User currentUser =
Authentication.GetUser<User, AuthenticationService>(context);
DomainService domainService =
(DomainService)Activator.CreateInstance(domainServiceType,
currentUser);
domainService.Initialize(context);
return domainService;
}
return _defaultFactory.CreateDomainService(domainServiceType, context);
}
public void ReleaseDomainService(DomainService domainService) {
if ((domainService is BookShelfService) ||
(domainService is BookClubService)) {
domainService.Dispose();
}
else {
_defaultFactory.ReleaseDomainService(domainService);
}
}
public static void Setup() {
// Call this from Global.asax.cs in the Application's Start event handler
if (!(DomainService.Factory is DomainServiceFactory)) {
DomainService.Factory =
new DomainServiceFactory(DomainService.Factory);
}
}
}
Notice the use of the helper class, Authentication, that allows you to correctly instantiate the authentication service on the server, invoke it and retrieve the User object corresponding to the current authenticated principal. This helper class is in the RIAEssentials framework (link below). The resulting User object is passed in when constructing BookShelfService.
Book Club Data Model
Before we see the actual Authentication service implementation It is worth taking a quick look at the data model behind the Book Club application:
As you see, one of the tables is the Member table. It is intrinsically tied to various other tables by virtue of multiple associations. It also contains information about the user, such as display name, last login date, joined date etc. As such, I'd like my authentication implementation to use this Member table from my data model directly.
The User Object
One of the key things to think about in your application is what constitutes the User object than spans across client and server. What is the state you want to expose to the client for visualization purposes, and what is the state you want to have quick access to within the context of an authenticated session? These are the questions to ask.
The UserBase object provides the ability to track Name and Roles. The User object in the application is defined as follows to add additional properties:
public class User : UserBase {
public string DisplayName { get; set; }
public int MemberID { get; set; }
}
I added DisplayName, so it can be used on the client in the UI. I also added the MemberID, so this information can be used on the server on subsequent requests (for example, when doing authorization to ensure a user can only update a book they own - see the authorization post for that example). The User object will be populated from the Member entity from the data model.
Implementing Authentication
Authentication builds on the same domain services infrastructure you use to define your operations/tasks in your application. There are two approaches to implementing authentication:
1. Derive from the out-of-box AuthenticationService base class. This provides a default implementation that leverages the asp.net membership, roles and profile infrastructure.
2. Implement IAuthentication on your domain service and do whatever you like based on your unique scenarios when implementing Login, Logout and other methods of the interface. This is especially useful if you're not using the asp.net infrastructure services or want to use some custom auth mechanism.
In my case, I want to use my own DAL and its notion of members, so I am going to build my own custom authentication service. However, I don't really want to implement the intricacies of forms authentication, which aren't specific to my application, such as setting up HTTP cookies. I only want to write the parts that interact with my data model (very much in spirit with the rest of RIA Services - focus on your application logic, and not the on-wire or service plumbing).
I am going to use a base class called FormsAuthenticationService which implements the guts of forms authentication, and is provided as part of the RIAEssentials framework, that you can easily reuse in your own applications. With that handy base class, here is all I have to do is implement ValidateCredentials, and produce a valid User object using my data model:
[EnableClientAccess]
public class AuthenticationService : FormsAuthenticationService<User> {
protected override User ValidateCredentials(string name, string password, string customData) {
User user = null;
using (BookClubEntities bookClubObjectContext = new BookClubEntities()) {
Member member =
bookClubObjectContext.Members.Where(m => m.MemberAlias == name).
FirstOrDefault();
if ((member != null) &&
Authentication.ValidatePassword(password, member.PasswordHash)) {
user = new User() {
Name = name,
MemberID = member.MemberID,
DisplayName = member.MemberName
};
if (member.LoginDate != DateTime.UtcNow.Date) {
member.LoginDate = DateTime.UtcNow.Date;
bookClubObjectContext.SaveChanges();
}
}
}
return user;
}
}
Also note how the validation method tracks the last login date, which is something that is captured within the data model.
In the initial version of the Book Club app, the code was [incorrectly] storing passwords in the database. In reality it was a detail that I had yet to get to. Since I am now writing about authentication, I have fixed this. The database stores password hashes, rather than passwords in clear text. This required a small schema update, so you'll need to recreate the database and run the BookClub.sql SQL script before you run the code.
Any application code that uses the authentication service only depends on the contract defined by IAuthentication (whether it is the server, or the client), giving you freedom to implement what it means to authenticate and produce a User object as you desire.
Authentication over HTTPS
If you use forms authentication or even basic authentication (i.e. anything that transfers a user name/password as clear text from client to server), you would be advised to use HTTPS.
This takes a little bit of setup, i.e. setting up an HTTPS site binding, that goes beyond the scope of this post. However RIA Services makes it easy to declaratively indicate that a particular domain service should only be exposed to the world using a secure endpoint, once you've handled the server configuration.
[EnableClientAccess(RequiresSecureEndpoint = true)]
public class AuthenticationService : FormsAuthenticationService<User> {
}