Recently a Customer asked me if an application using RIA Services could use WIF. I’m fairly new to RIA Services so I didn’t know the answer right away, however I suspected the integration should not be too hard, so I spend a couple of days spiking a solution.

The good news: it just works!     

What I did:

I took one of the samples available from the RIA Services website (HRApp, you can download it here: http://code.msdn.microsoft.com/RiaServices, more specifically: http://code.msdn.microsoft.com/RiaServices/Release/ProjectReleases.aspx?ReleaseId=2387 )

After installing and verifying everything worked, I “claims enabled” it by running “FedUtil.exe”. I configured it to point to Adatum Issuer (exactly the same you can download from the Guide CodePlex site: http://claimsid.codeplex.com).

As expected, FedUtil changed a few setting in the app config file to enable claims: WIF modules were registered and the relationship with Adatum Issuer was established:

clip_image001

clip_image002

I then ran the application again and I was gladly surprised to be first redirected to the Issuer for authentication:

clip_image003

If you have installed the Guide samples, you are probably familiar with this screen and you know that it will issue a set of claims for a user “Mary” that includes 2 roles “Orders approvers”, “Employees”. When I click on “continue button”, claims are issued and sent to the RIA application where now I’m authenticated and recognized:

clip_image004

If you break into the application (server side) and inspect the User object from the HttpContext you’ll notice there’s a “ClaimsIdentity” and you have access of course to the claims collection, etc. That is part of the “magic” performed by WIF modules:

clip_image005

On the Silverlight side, you can see that now the User object in the RiaContext also reflects the content obtained in the server side. This is thanks to some of the magic wiring RIA Services does for us:

clip_image006

RIA Services out of the box implementations rely on ASP.NET infrastructure. I didn’t want to change the sample app too much, so I created a very simple RoleProvider that would simply resolve GetRolesForUser through the ClaimsIdentity. Here’s the (only) method that I implemented from the RoleProvider base class:

public override string[] GetRolesForUser(string username)
{
    var id = HttpContext.Current.User.Identity as IClaimsIdentity;
    return (from c in id.Claims
            where c.ClaimType == ClaimTypes.Role
            select c.Value).ToArray();
}

 

Roles are enabled in the web.config:

<roleManager enabled="true" defaultProvider="GenevaRoles">
  <
providers>
    <
add name="GenevaRoles" type="HRApp.Web.GenevaRolesProvider, HRApp.Web"/>
  </
providers>
</
roleManager>

 

Of course, Roles are Claims, but not all Claims are roles. You could extend the RIA User object to hold whatever other information you want. So you could end up having any other profile data in the user object that comes from a Claim (e.g. the “Cost Center” claim that our Issuer gives us).

Many thanks to Erwin for his help.