After the packed schedule at EIC in Munich, and the frantic beta2 launch activities at teched this week, I have few relatively quiet hours in my office in Redmond before setting sails to the IIW this Sunday. While the eye of the storm lasts, I wanted to spend few more words on detailing what we have put in the identity developer training kit.

As mentioned, in this release we focused on delivering a comprehensive set of hands-on lab that would allow you to reap tangible benefits from the beta 2 of Geneva ASAP. The idea was to cover many of the scenarios that we are often asked about in forums and customer discussions, but also to present things in the right order so that application developers can learn to use geneva framework without necessarily having to understand the entire stack. That’s the essence of externalization: the authentication and authorization logic do not disappear, it simply moves out in a place where it can be more conveniently coded & maintained; and the developer that works on the app is not necessarily the same person that will work on the auth logic, hence for the app dev it may actually look like the complexity disappears! The kit tried to be respectful of that, but also kept into account the needs of the ones that want to know what really happens in the kitchen. Let me go in more details in the HOLs and the exercises we offer there:

Web Sites and Identity

Surprise surprise, this lab aims at demonstrating how to take advantage of claims based identity in your web applications.

Exercise 1: Enabling claims based access for an ASP.NET Web Application by generating a local STS

In the very first exercise you start from an existing ASP.NET app and you start working with claims, taking advantage of the new visual studio integration which allow you to create a development STS in just few clicks.

I believe it was important to start with an existing application, so that you get the feeling that you can take advantage of this already in your exisitng asset and there’s no need to start over. For the same reason, we highlight how the traditional ASP.NET role authorization syntax works well also when the information comes from claims.

At the same time, I didn’t want you to think that claims are just another kind of syntactic sugar but in the end this is just the usual RBAC; and after having heard many discussions in this sense at EIC, I am glad we took this into account. In order to demonstrate that claims enable things that were simply not possible before with roles alone, we added a step in which we configure our website to authorize access to a page only to users older than a certain age. In so doing, we show how you can take advantage of geneva framework’s hook for injecting your own authentication logic (in this case a threshold check on an int derived from a datetime value, the dateofbirth claim). If you want to know more about this specific aspect, I suggest watching Chuck’s interview.

Exercise 2: Customizing the Credentials Accepted by a Local STS

The second exercise is for the ones that want to know more about how claims based access work: here we demonstrate how to use a very simple user repository & credential verification solution, ASP.NET membership, and show how it could be used as an identity & credentials repository for an STS. In the process, we summarize the object modle and project structure of a development STS in geneva framework. An application developer may be perfectly productive without knowing what happens inside an STS, which is why the exercise is marked as optional.

Exercise 3: Accepting Tokens from a Geneva Server STS

We believe that the most common case of use on an STS will be the one in which the application developer simply refers to an existing, already-running STS instance. The natural choice was to provide a geneva server instance for the task. Thanks to the advanced support of metadata in geneva framework, this exercise is extremely quick to do.

We wanted the training kit to be as agile as possible and give you the chance to run it directly on your machines, without the need of downloading and setting up big virtual machines for hosting the geneva server: as a result, Caleb was so kind to set up such a geneva server instance on federatedidentity.net and preprovision it with a federation relationship for the lab address. This enables you to take advantage of a geneva server without installing anything on your machine, but also implies that you need to have internet connectivity for the exercise to work.

Exercise 4: Accepting Tokens from Live ID

This is a “bonus” exercise 🙂 With its enormous popularity, Live ID is an extremely useful identity provider to use. This exercise puts in practice the skills acquired in the former tasks and demonstrate how to implement a scenario that is among the most popular questions we receive from customers: we already saw this used as a reference for implementing federated systems where Live ID is involved .

Exercise 5: Accepting Tokens from .NET Access Control Service

Another popular scenario, accepting tokens from the .NET Access Control Service on your website is a task that I really wanted to include. Besides the practical advantage sof showing how to handle the protocol requirements of the ACS, this exercise shows how to use a resource STS and the same approach can be applied also in the case the R-STS is on your own premises.

Exercise 6: Invoking a WCF Service on the Backend via Delegated Access

Finally, this is perhaps my favorite exercise: it demonstrates how you can take advantage of an ActAs STS in your architecture for performing delegated calls to your backend, as opposed to resorting to trusted subsystems or whole-site impersonation. Expect more blog posts about this specific scenario in the future.

Note: the exercise is mainly meant for the website developer, hence it really does not go in the details of how the ActAs STS or the services are taking advantage of geneva framework for making the delegation magic happen. As a result, they are provided as part of the initial solution elements as opposed to be progressively constructed: however nothing prevents you to take a peek at the code, if you are curious 😉

Web Services and Identity

Perhaps there is a bit of observer influencing the experiment here (hello-oh? plate), however there’s a surprisingly high percentage of people that really want to use geneva framework in the context of SOA and services. Those guys are often knowledgeable about the WCF programming model, hence the information about using the geneva framework object model with web services need to be cognizant of that; that’s what we tried to do with the Web Services & Identity lab.

Exercise 1: Using Geneva Framework for Handling Authentication and Authorization in a WCF Service

The first exercise does not even have an STS in the scenario, and sues username/password directly. It is there exclusively for introducing you to the service programming model in the geneva framework and understand the differences in respect to what you were doing in WCF for handing authentication & authorization. If you went through the first lab (not a prerequisite), this exercise will also highlight the differences induced by the different hosting models in ASP.NET and WCF (again, Chuck’s explanation is your friend).

Exercise 2: Accepting Tokens from a Geneva Server STS

This is analogous to exercise 3 in the web sites lab, and just shows how to use fedutil in the active case. Again, Caleb & Federatedidentity.net came to the rescue and the result is that you can take advantage of a preprovisioned geneva server available online, without the need to setting up any VM in your local environment.

Note that the model for using ClaimsAuthorizationManager remains pretty much the same even if here we are dealing with services rather than pages.

Exercise 3: Accepting Tokens from .NET Access Control Service

I think it’s an interesting scenario to consider the use of the .NET Access Control Service for your backed, however there were not many examples of the ACS used with active profile and federation rather than the temporary credentials currently offered with .NET solutions. Also, for some reason many examples tend to use Live ID as an IP when it comes to show ACS: this scenario demonstrates how you can use your own IP-STS instead, and you can easily transport it to the case in which you use a full fledged geneva server instance for that job.

Exercise 4: Invoking a WCF Service on the Backend via Delegated Access

This is the delegated scenario again, which si similar to exercise 6 in the Web sites lab but that shows challenges of its own: for example, the fact that we use a rich client has implications in the way in which we handle the token flow.

Enhancing ASP.NET Membership Provider Website with identity provider Capabilities

Remember my recent post about adding a passive STS to an existing ASP.NET membership-based website? Well, that post was pretty much the prototype for this exercise: the key difference being that while for the blog post i had to use beta1, this lab takes full advantage of beta 2. Go ahead, compare the length of the blog post with the length of the lab: even if you factor out the silly jokes that crowd my posts (and that I had the good taste to avoid in the lab manuals), the former is still dramatically longer than the latter. Why? Mainly thanks to the outstanding support for metadata that beta2 offers. I really suggest you take a look at all the code for this one 🙂

Introduction to the .NET Access Control Service

This is the same lab we added in the Azure Services Training Kit, enhanced with the exercise 5 from the web lab and 3 from the web services lab above. I think we’ll include this in the next drop of the azure services training kit.

I think I should give credit where credit is due: the product team was absolutely invaluable for this, providing validation for the scenarios and even code fragments for making sure that the kit shows true intended usage of the product. I am sure I am forgetting somebody but Stuart, Caleb, Sesha, Jan and Chuck are the first that come to mind as the people who made this possible.

Finally, I really want to thank our partner SouthWorks who helped us with the implementation of the lab: besides their usual professionalism, Matias, Ariel and Tim had to demonstrate infinite patience as yours truly expressed his manic-depressive-controlling personality and combed *everything*, at the finest granularity, on daily basis. Thank you guys, you are outstanding, as usual.

That’s it. We are really looking forward for your feedback, and we hope that the kit will help you enter the fascinating world of identity & development 🙂