Updated RIA and WIF samples – Part I

Some time ago, I put together a simple demo integrating WIF in RIA Services. Now RIA is a Beta and there’s a lot of cool stuff in there. The good news from an identity perspective is that it just works :-).

I’ve been playing a little bit with a couple of new samples and with the previous (updated) HRApp. The first one is the “CyclingClassifieds” you can download from here.

The identity  architecture of the application is simple enough for a first exploration. Out of the box, it is configured for Windows integrated security, so if you run the sample it will simply recognize the user you are logged in as in your network. The app has an “auto-provisioning” feature that automatically registers external users into the application. There’s a stored procedure that will try to locate the user name in the database (Users table), and if it is not found, it will simply add a new record:

 

 

“Claims-enabling” this app is simple, because authentication has already been factored out. The app as it is designed today is not responsible for identifying its users. Something else does it for the application (Windows).

Steps:

1- First you need to install WIF and WIF SDK. We want the SDK to use the Visual Studio integrated tools.

2- Make sure the app runs before any changes. One line of code you will need to change is in the GetUserId method of the CyclingClassifiedsService:

It is well explained in the comments in there.

3- Next step is to change the configuration and “claims enable” the app. Right click on the web site and select “Add STS Reference”:

4- This will start FedUtil wizard:

Because this app is very simple and only requires authentication really (there are no roles or any other claims that will be used here), simply select all defaults.

On the second screen, you have multiple options on which Issuer to use. The Issuer is the system that will return Security Tokens (with all claims) to the application. The application will be configured to trust this Issuer. I selected “Create a new STS project in the current solution”, because I wanted the sample to remain self-contained. Of course you could have chosen a real issuer somewhere else (e.g. your ADFS, an existing development Issuer, etc).

5- After all this is done, the solution will have an additional project. There’s some boilerplate code, but the heart of the issuer is the class CustomSecurityTokenService:

Fedutil will create a template with some default claims (search for GetOutputClaimsIdentity method). This is one place :

The web.config file will also be updated with new configuration settings. Very similar to what I explained in the previous post. (e.g. WIF modules, etc)

 

6- Compile and run the app. The first screen you will see is the Issuer login page:

 

No password is really verified because this is a “fake” Issuer. Clicking submit, will initiate the process of issuing a token (essentially all under the GetOutputClaimsIdentity method) and redirection to the original site where the normal RIA app life cycle starts. A breakpoint in the AuthorizationService file will reveal “WIF magic” happening:

Notice that the type of the user identity is “ClaimsIdentity”.

Finally:

 

 

if you browse the contents of the User table you should now find a record for “Adam Carter” in it.

I will now do the same for the HRApp and post my findings.