This post digs deeper into the Book Club application from the perspective of the authorization feature of RIA Services. You can check out more information about the application via its associated table of contents post.
The post covers how the out-of-box authorization rules can be applied, how custom rules that can be implemented, how custom rules can use additional bits of information in their implementation, and how client-side UI can be customized to account for authorization.
The sample application has been updated, so you might want to download the latest release of the code from the RIA Services Essentials project on CodePlex or browse the checkin history.
Authorization and validation share a lot of common concepts and patterns, so the deep dive into validation with RIA Services might be particularly interesting.
Authorization Overview
Authorization allows you to secure operations and data in your application based on the authenticated user. It essentially answers the question:
"Can X do Y [with Z]?"
where X is the user (the subject), Y is the operation (the verb), and optionally, Z is the entity being operated upon (the object). In RIA Services, each authorization rule encapsulates a specific question that you can associate your services and its operations with. These rules help create a more complete picture of the domain or application semantics that are being encapsulated within a domain service. Rules are associated with operations as metadata attributes that derive from AuthorizationAttribute.
While the most common source for attributes is from IL, i.e. attributes compiled into an assembly, the general RIA Services metadata story is extensible and allows metadata to be loaded from external sources such as databases, xml files, etc. That will be a topic for the future. Attributes are also extensible.
RIA Services ships with a couple of built-in authorization rules for common scenarios, but the attribute-based model is extensible. The application demonstrates building a custom attribute, and you can use the same technique to call into a rules engine that you might already have that encapsulates the business rules you want to leverage.
The RIA Services infrastructure ensures that all operations, queries, inserts, updates and deletes submitted by a client to the server are being performed under the context of a user or principal who meets the specified authorization rules.
Authorization is separate from authentication (a topic for another day). Authentication deals with validating credentials, associating a session with the user, and creating an IPrincipal instance representing the user associated with requests within that session. Authorization consumes that principal.
Basic Declarative Rules
As mentioned above, RIA Services provides authorization rules out-of-the-box that apply to a large number of scenarios. The two attributes are:
- RequiresAuthentication - ensures that the current principal represents a valid authenticated user, i.e. it prevents anonymous users from accessing a service to perform an operation.
- RequiresRole - ensures that the current principal belongs to at least one of the specified roles.
For example, in the Book Club application, the BookShelfService, represents the virtual book shelf of a book club member. As such it requires an authenticated book club member.
[RequiresAuthentication]
public class BookShelfService : LinqToEntitiesDomainService<BookClubEntities> {
}
Since the rule is specified at the class level, all operations automatically inherit this requirement.
On the other hand, the BookClubService supports anonymous browsing of books, but requires requests and likes to be performed by book club members only. So in this case, the rule is specified on individual operations.
public class BookClubService : LinqToEntitiesDomainService<BookClubEntities> {
[RequiresAuthentication]
public void RequestBook(BookInfo book) { ... }
[RequiresAuthentication]
public void LikeBook(BookInfo book) { ... }
}
Custom Rules, AuthorizationAttribute and AuthorizationContext
The out-of-box rules are broadly applicable. However in many applications, there are additional more specific rules you will want to apply.
We wanted to implement CustomAuthorization (ala CustomValidation), but couldn't include it for v1. So I have implemented a very basic implementation of CustomAuthorizationAttribute that derives from AuthorizationAttribute and included it in the sample application for you to check out/copy/use. It allows pointing at a method in the application that performs authorization. The method receives the IPrincipal representing the user, and an AuthorizationContext which contains additional data.
In the Book Club application, I want to ensure that a book can only be updated by the specific book club member who owns the book. As such here is my domain service code.
[RequiresAuthentication]
public class BookShelfService : LinqToEntitiesDomainService<BookClubEntities> {
[CustomAuthorization(typeof(BookRules), "IsBookOwner")]
public void UpdateBook(Book book) { ... }
}
}
Declaring this as an attribute rather than mixed up in the body of the method is advantageous as it declares intent that could in the future be repurposed, or analyzed statically. It also lets the same rule be reused, for example, for the UnshareBook delete operation. Here is my implementation of the rule:
public static AuthorizationResult IsBookOwner(IPrincipal user, AuthorizationContext authorizationContext) {
Book book = (Book)authorizationContext.Instance;
User userInfo = (User)authorizationContext.Items[typeof(User)];
if (user != null) {
Book dbBook = null;
using (BookClubEntities bookClubEntities = new BookClubEntities()) {
dbBook = bookClubEntities.Books.Where(b => b.BookID == book.BookID).FirstOrDefault();
}
if ((dbBook != null) && (dbBook.MemberID == userInfo.MemberID)) {
return AuthorizationResult.Allowed;
}
}
return new AuthorizationResult("You must be the owner of the book to make a change.");
}
As you can see, the rule needs the Book upon which the update is being performed. RIA Services passes in the entity being operated upon via the AuthorizationContext.
My rule also requires the current User object, i.e. it needs more information than just the IPrincipal (which only contains the name/roles of the user). It needs the MemberID. A domain service can customize the AuthorizationContext to pass in additional bits of information. Here is what BookShelfService does, to initialize the authorization context.
public class BookShelfService : LinqToEntitiesDomainService<BookClubEntities> {
private User _user;
public BookShelfService(User user) {
_user = user;
}
protected override void Initialize(DomainServiceContext context) {
base.Initialize(context);
AuthorizationContext customAuthContext = new AuthorizationContext(context);
customAuthContext.Items[typeof(User)] = _user;
AuthorizationContext = customAuthContext;
}
}
The user is passed in into the BookShelfService when it is created. In order to pass in additional data at construction time, the application uses a custom DomainServiceFactory, which is yet another topic for another day, but something you can look up in the sample code in the meantime.
Finally, notice the rule implementation validates that the current authenticated user is the book's owner by looking up the database for the current book information. When implementing security rules, it is important to determine what if any of the information supplied by the client can be trusted. In this case, the Book instance passed in into the authorization rule is only used to lookup the Book from the back-end by its ID. The MemberID field of the Book submitted by the client is not used, as it may contain a made up value by a malicious client. Instead book ownership is determined solely on the basis of information that the server trusts, i.e. the back-end database.
The extensibility mechanism around AuthorizationAttribute allows you to implement all sorts of rules. While I haven't needed them in the sample, the key is to remember AuthorizationAttribute is a base class, and you get to implement the IsAuthorized method as you please. I'll just throw out a couple of examples, as motivation.
For example, if you want to restrict user's by IP address:
[RequireIPAddress("207.46.197.*")]
Or you could have a rule that permits an entity to be updated at most once per hour.
[RestrictEditFrequency(AllowedEdits = 1, TimeSpan = "01:00:00")]
It really is up to you, and the needs of your application.
Client-side Use of Authorization
Authorization is an interesting feature. If your client user interface is designed correctly, you should never hit an authorization failure. This is because your user interface should ideally hide or disable features/tasks that the current user is not authorized to perform.
For example, I have a link to navigate to the Book Shelf page, which only makes sense once the user is logged in. This becomes fairly straightforward with the RIA Services infrastructure (the WebContext class) which manages the current user over the lifetime of the application.
<HyperlinkButton
Content="My Book Shelf"
TargetName="mainFrame" NavigateUri="/BookShelf"
Visibility="{Binding Source={StaticResource webContext}, Path=Current.User,
Converter={StaticResource requiresAuthConverter}}"/>
I've written a converter as part of the sample application that converts from an IPrincipal to a Visibility value, and declare that in App.xaml as follows:
<fx:UserConverter x:Key="requiresAuthConverter"
RequiresAuthentication="true" />
So essentially, the Visibility of my Hyperlink is bound to the current user. The converter is setup to return Visibility.Visible when the current user is authenticated. When the user logs in through the UI, the current user is changed, which causes the binding to update the visibility. The same approach can be used to check for roles instead of just authentication state, and to bind other properties of controls such as IsEnabled to conditionally enable parts of the user interface.
You'll of course still want to have all the required authorization rules in place, because you are authoring a service, and the client is assumed to be untrusted, i.e. someone may always call into your service directly, rather than go through your client's user interface.
Summary
We have to do a bit more work in the authorization space (eg. supporting ability to declare what entity fields can be modified by whom, and propagating authorization metadata to the client). However, I think just like the work we did in moving validation from the UI and into the model, the interesting aspect of the RIA Services approach in the authorization space is moving it from the service endpoint/layer and into the application logic layer where it can be specified or modeled as part of the domain, where these rules rightfully belong.