WCF RIA Services - Authentication/Authorization

In this blog, I continue to research on the Authentication/Authorization piece of WCF RIA Services. If you haven't read the overview, I encourage you to do so in my previous blog post titled "WCF RIA Services Overview". For Authentication/Authorization read on...

  • AuthenticationDomainService
    • The framework provides an AuthenticationDomainService on the server side. AuthenticationDomainService derives from AuthenticationBase which derives from DomainService. It provides mechanisms for authentication, authorization and user profiles.
    • AuthenticationBase provides default implementations for Login, Logout, GetUser, UpdateUser functions.
  • User
    • A User class is also generated on the server side.
    • It derives from UserBase which has Name and collection of Roles.
    • UserBase also implements IPrincipal and IIdentity.
    • The architecture is designed in this way so that we can easily add our custom properties to this user class. This way both the authentication needs and our biz needs are met. Once built, these properties also propagate to the client side.
    • A corresponding User proxy is also created on the client side which also implements the IPrincipal and IIdentity.
    • On server side you can access the user by accessing ServiceContext.User property.
    • On client side you can do so by accessing WebContext.User property.
  • AuthenticationDomainContext
    • After building the solution, a corresponding AuthenticationDomainContext gets created.
    • It derives from AuthenticationDomainContextBase which derives from DomainContext.
  • AuthenticationService
    • We can use the functions provided by AuthenticationDomainContext but RIA provides one more level of abstraction in the form of AuthenticationService on the client side.
    • This class provides methods such as Login, Logout, LoadUser, SaveUser etc. It also provides properties to access the User and its properties such as IsBusy, IsLoggingIn etc.
    • WebAuthenticationService inherits from AuthenticationService.
    • Two more classes, FormsAuthentication and WindowsAuthentication inherit from WebAuthenticationService. These classes are concrete.
    • The WindowsAuthentication class does nothing more but to prohibit the Login and Logout methods due to the nature of authentication.
  • WebContext
    • The client also generates a WebContext class when built. This class can also pretty much do everything that the FormsAuthentication and WindowsAuthentication can do but it provides a better abstraction level. What this means is that it is a more generic way to do authentication.
    • The WebContext class can also be added to the application level storage namely ApplicationLifetimeObjects (in app.xaml), making it easy to be accessible from anywhere in the client app.
    • It also provides the access to the current user from anywhere in the client app.
    • Once the WebContext is setup, we can use its properties to bind in our XAMLs to effectively enable/disable functionalities based on authentication.
  • Transport Security
    • To expose a service over HTTPS, you just need to apply the RequiresSecureEndpoint=true inside the EnableClientAccess attribute on top of the domain service.
    • The generated domain context will now call a different constructor to use HTTPS.
    • If your website is HTTP and you are making service calls through HTTPS, you will need to update the clientaccesspolicy to allow for cross domain/scheme calls.
  • Authorization
    • You can use RequiresAuthentication and RequiresRole attributes on top of services or operation scopes to make them secure.
    • Once the solution is built, these attributes propagate to the client side as well.
    • We can also do custom authorization by creating custom authorization classes.
  • Custom Authentication
    • Most of the times in business application, the membership framework provided by ASP.NET would not be enough.
    • Moreover, the framework provided user, roles entities might not tie up with our business requirements. In that case, we need to use custom authentication.
    • To implement custom authentication, we need to override a few methods in the AuthenticationDomainService.
    • The methods to override are:
      • ValidateUser
      • GetAuthenticatedUser
      • UpdateUserCore
    • Once these methods are implemented, we are actually bypassing the system provided by ASP.NET membership and are using our own system.
In this blog, we examined the authentication/authorization framework provided by WCF RIA services. It can be used out-of-box and it can be customized as well. One of the great advantages of WCF RIA services is that client generation is taken care of by the RIA architecture. This means that validation, attributes, authentication, authorization and other things are all in sync with each other.
at
Labels: , ,