Eugenio Pace : Claims

Claims Identity Guide–Hands On Labs

Eugenio Pace - MSFT — Mon, 13 Jun 2011 16:53:36 GMT

Training content based on our guides has been as popular as the content itself. You can now download the “Release Candidate” for labs corresponding to the new guide.

The labs are more than just a mirror of the guide. We took the opportunity of adding a few things that complement and extend what is explained in the book. A notable addition is using ADFS v2.

The guide talks a lot about “using ADFS for a production environment”, but all samples shipped use a “simulated STS” (this is of course than for convenience and to minimize the dependencies on your dev environment). Well, now you will have a chance of using experimenting and learning about ADFS v2.

But there’s more of course.

Here’s the compete “Table of Contents”. Feedback always very welcome.

Lab 1

Exercise 1: Making Applications Claims-aware. In this exercise you will modify two Adatum web applications (a-Order and a-Expense) that currently use forms-based authentication to make them claims-aware, and to provide the user with a single sign-on (SSO) experience.

Exercise 2: Enabling Single Sign-Out. In this exercise you will add code to the applications so that users logging out of one are automatically logged out of the other.

Exercise 3: Using WIF Session Mode. In this exercise you will modify the applications to change the behavior of the WIF modules so that token information is stored in the session instead of the authentication cookie.

Lab 2

Exercise 1: Federating Adatum and Litware. In this exercise, you will modify the Adatum a-Order web application to trust the Adatum federation provider, and configure the Adatum federation provider to trust both the Adatum and Litware identity providers.

Exercise 2: Home Realm Discovery. In this exercise, you will modify the a-Order web application to send a whr parameter to the federation provider. You will then modify the Adatum federation provider to use the value of the whr parameter to determine the identity provider the user should authenticate with.

Exercise 3: Federation with ADFS. In this optional exercise, you will replace the custom Adatum federation provider with ADFS.

Lab 3

Exercise 1: Adding ACS as a Trusted Issuer. In this exercise you will start with a version of the a-Order application similar to that you used in previous labs, and modify it to use Windows Azure AppFabric Access Control Service (ACS) as the trusted issuer and identity provider in addition to the Adatum federation provider and simulated issuer.

Exercise 2: Adding the Facebook Identity Provider and Home Realm Discovery. In this exercise you will add Facebook as an identity provider to your ACS namespace. This illustrates how, by taking advantage of ACS, you can easily change the options a user has for authentication when using your applications; without requiring any modification of the application or of your own local token issuer or federation provider.

Exercise 3: Adding a Custom OpenID Identity Provider. In this exercise you will use the ACS Management API to programmatically add a relying party application that uses the OpenID identity provider.

Exercise 4: Replacing the Adatum Federation Provider with ADFS. In this optional additional exercise you will replace the existing Adatum federation provider with an ADFS instance, and configure this to use ACS as a token issuer and identity provider.

Lab 4

Exercise 1: Using Claims with SOAP Web Services. In this exercise, you will modify the SOAP-based Adatum a-Order web service to use claims. You will also modify the desktop client application to work with the new version of the service.

Exercise 2: Using Claims with REST Web Services. In this exercise, you will modify the REST-based Adatum a-Order web service to use claims. You will also modify the desktop client application to work with the new version of the service.

Exercise 3: Federation with ADFS. In this optional exercise, you will replace the custom Adatum federation provider with ADFS.

Intuit Data Services + Windows Azure + Identity

Eugenio Pace - MSFT — Fri, 08 Apr 2011 05:15:22 GMT

This week, we completed a small PoC for brabant court, a customer that is building a Windows Azure application that integrates with Intuit’s Data Services (IDS).

A couple words on mabbled from brabant court.

Mabbled is a Windows Azure app (ASP.NET MVC 3, EF Code First, SQL Azure, AppFabric ACS|Caching, jQuery) that provides complementary services to users of Intuit QuickBooks desktop and QuickBooks Online application. Mabbled achieves this integration with the Windows Azure SDK for Intuit Partner Platform (IPP). An overriding design goal of mabbled is to leverage as much of Microsoft’s platform and services as possible in order to avoid infrastructure development and focus energy on developing compelling business logic. A stumbling block for mabbled’s developers has been identity management and interop between Intuit and the Windows Azure application.

In this PoC we demonstrate how to integrate WIF with an Intuit/Windows Azure ASP.NET app. Intuit uses SAML 2.0 tokens and SAMLP. SAML 2.0 tokens are supported out of the box in WIF, but not the protocol.

I used one of Intuit’s sample apps (OrderManagement) as the base which currently doesn’t use WIF at all.

The goal: to supply to the .NET Windows Azure app, identity information originated in Intuit’s Workplace, using the WIF programming model (e.g. ClaimsPrincipal) and to use and leverage as much standard infrastructure as possible (e.g. ASP.NET authorization, IPrincipal.IsInRole, etc.).

Why? The biggest advantage of this approach is the elimination of any dependency to custom code to deal with identity related concerns (e.g. querying for roles, user information, etc.).

How it works today?

If you’ve seen Intuit’s sample app, you know that they provide a handler for the app that parses a SAML 2.0 token posted back from their portal (http://workplace.intuit.com). This SAML token contains 3 claims: LoginTicket, TargetUrl and RealmId. Of these, LoginTicket is also encrypted.

The sample app includes a couple of helper classes that use the Intuit API to retrieve user information such as roles, profile info such as e-mail, last login date, etc. This API uses the LoginTicket as the handle to get this information (sort of an API key).

Some of this information is then persisted in cookies, or in session, etc. The problem with this approach is identity data is not based on .NET standard interfaces. So the app is :

where RoleHelper.UserisInRole is:

WIF provides a nice integration into standard .NET interfaces, so code like this in a web page, just works: this.User.IsInRole(role);

The app currently includes a ASP.NET Http handler (called "SamlHandler”) whose responsibility is to receive the SAML 2.0 token, parse it, validate it and decrypt the claim. Sounds familiar? if it does, it’s because WIF does the same

What changed?

I had trouble parsing the token with WIF’s FederationAuthenticationModule (probably because of the encrypted claim which I think it is not supported, but I need to double check).

Inside the original app handler, I’m taking the parsed SAML token (using the existing Intuit’s code) and extracting the claims supplied in it.

Then, I query Intuit Workplace for the user’s general data (e.g. e-mail, name, last name, etc.) and for the roles he is a member of (this requires 2 API calls using the LoginTicket). All this information also goes into the Claims collection in the ClaimsPrincipal.

After that I create a ClaimsPrincipal and I add all this information to the claim set:

The last step is to create a session for this user, and for that I’m (re)using WIF’s SessionAuthenticationModule.

This uses whatever mechanism you configured in WIF. Because this was a quick test, I left all defaults. But since this is a Windows Azure app, I suggest you should follow the specific recommendations for this.

The handler’s original structure is the same (and I think it would need some refactoring, especially with regards to error handling, but that was out of scope for this PoC )

Some highlights of this code:

Some API calls require a dbid parameter that is passed as a query string from Intuit to the app in a later call. I’m parsing the dbid from the TargetUrl claim to avoid a 2 pass claims generation process and solve everything here. This is not ideal, but not too bad. It would be simpler to get the dbid in the SAML token.
The sample app uses local mapping mechanism to translate “Workplace roles” into “Application Roles” (it uses a small XML document stored in config to do the mapping). I moved all this here so the ClaimsPrincipal contains everything the application needs right away. I didn’t attempt to optimize any of this code and I just moved the code pieces from the original location to here. This is the “RoleMappingHelper”.
I removed everything from the session. The “LoginTicket” for instance, was one of the pieces of information stored in session, but I found strange that it is sent as an encrypted claim in the SAML token, but then it is stored in a cookie. I removed all this.
The WIF SessionAuthenticationModule (SAM) is then used to serialize/encrypt/chunk ClaimsPrincipal. This is all standard WIF behavior as described before.

The web application:

In the web app, I first changed the config to add WIF module and config:

Notice that the usual FederationAutheticationModule is not there. That’s because its responsibilities are now replaced by the handler. The SAM however is there and therefore it will automatically reconstruct the ClaimsPrincipal if it finds the FedAuth cookies created inside the handler. The result is that the application now will receive the complete ClaimsPrincipal on each request.

This is the “CustomerList.aspx” page (post authentication):

The second big change was to refactor all RoleHelper methods to use the standard interfaces:

An interesting case is the IsGuest property that originally checked that the user was a member of any role (the roles a user was a member of were stored in session too, which I’m not a big fan of). This is now resolved with this single query to the Claims collection:

The structure of the app was left more or less intact, but I did delete a lot of code that was not needed anymore.

Again, a big advantage of this approach is that it allows you to plug any existing standard infrastructure into the app (like [Authorize] attribute in an MVC application) and it “just works”.

In this example, the “CustomerList.aspx” page for example has this code at the beginning of PageLoad event:

As mentioned above, the RoleHelper methods are now using the ClaimsPrincipal to resolve the “IsInRole” question (through HttpContext.User.IsInRole). But you could achieve something similar with pure ASP.NET infrastructure. Just as a quick test, I added this to the web.config:

And now when trying to browse “CustomerList.aspx” you get an “Access Denied” because the user is not supplying a claim of type role with value “SuperAdministrator”:

Final notes

A more elegant approach would probably be to use deeper WIF extensibility to implement the appropriate “protocol”, etc., but that seems to be justified only if you are really implementing a “complete” protocol/handler (SAMLP in this case). That’s much harder work.

This is a more pragmatic approach that works for this case. I think it fulfills the goal of isolating as much “plumbing” as possible from the application code. When WIF evolves to support SAMLP natively for example, you would simply replace infrastructure, leaving your app mostly unchanged.

Finally, one last observation: we are calling the Intuit API a couple times to retrieve user info. This could be completely avoided if the original SAML token sent by Intuit contained the information right away! There might be good reasons why they are not doing it today. Maybe it’s in their roadmap. Once again, with this design, changes in your app would be minimized if that happens.

This was my first experience with Intuit’s platform and I was surprised how easy it was to get going and for their excellent support.

I want to thank Daz Wilkin (brabant court Founder) for spending a whole day with us. Jarred Keneally from Intuit for all his assistance and Federico Boerr & Scott Densmore from my team for helping me polish the implementation.

Web Single Sign Out–Part II

Eugenio Pace - MSFT — Thu, 24 Feb 2011 21:01:17 GMT

Following up on previous post, there were 2 questions:

Where do these green checks images come from? There are nowhere in a-Order or in a-Expense… you would spend hours looking for the PNG, or JPG or GIF and you will never find it, because it is very well concealed. Can you guess where it comes from?

I was referring to the green checks displayed here:

The src for these is a rather cryptic src=http://localhost/a-Order/?wa=signoutcleanup1.0

And the answer is: it’s coming from within WIF (the FAM more specifically). If you explore the FAM with Reflector you will see a byte array embedded in the code. That byte array is the GIF for the green check. Exercise to the reader: is this the only behaviour? Can the FAM do something else? under which circumstances?

The second question was:

Bonus question: how does the IdP know all the applications the user accessed to?

No WIF magic here. The issuer will have to keep a list of all the RP. In our sample (that we expect to release really soon) we use exactly the technique described in Vittorio’s book. We have a small helper class “SingleSignonManager” that keeps track of RPs in cookies:

Then, when the signout request is received, we simply iterate over the list and return the right markup:

The SingleSignoutManager class is mentioned in Vittorio’s book but not available there, so we included it in the sample.

Single Sign Out–WebSSO

Eugenio Pace - MSFT — Wed, 16 Feb 2011 18:46:02 GMT

While reviewing all the existing samples we’ve noticed that our implementation of Single Sign Out was kind of….weak. It wasn’t really fully implemented and wasn’t very clear what was happening either (or what it should happen)

We’ve fixed all that now in scenario 1: WebSSO. Things get more complicated when more than 1 STS is in the picture, and even more so when the identity provider uses other protocols (for example, all our scenarios using ACS and Google or ACS and LiveID). But for WebSSO, things are more or less straight forward.

WebSSO scenario recap:

If you remember for previous posts or the book, in our first chapter we had Adatum with 2 applications: a-Order and a-Expense. We wanted that Adatum employees login to one or the other seamlessly:

John opens the browser on his desktop (that already has a been authenticated with AD)
Opens a-Order home page
Gets redirected to the IdP. He’s authenticated (e.g. Kerberos ticket)
A token is given to him. The token is posted back to a-Order. He’s in.

Sometime later, he browses a-Expense.

No session with a-Expense yet, he’s redirected to IdP
He’s already authenticated, gets a new token for a-Expense.
Voila

So far, so good. Nothing really new. What happens now if John wants to signoff. We don’t want our system to be a roach motel: once in, never out… what happens is actually pretty straight forward, but there are some subtle considerations. When John signs-off, he should sign off from all relying parties and the IdP.

This diagram illustrates the process:

John clicks on “Logout” (on any of the relying parties: a-Order in our example). This results on a wa=signout1.0 to be sent to the IdP. The Idp cleans up its own session with the user and then (here comes the tricky part)returns a page to the user with a list of image tags (HTML image tags). An image tag for each RP the IdP has issued a security token for John. The src url for these images will be actually something like:

src=http://localhost/a-Expense/?wa=signoutcleanup1.0

src=http://localhost/a-Order/?wa=signoutcleanup1.0

With these tags, the browser will attempt to get the image from these URL (which happens to be located in each RP: a-Order and a_expense), and in fact you will see something like this:

The HTML:

Where do these green checks images come from? There are nowhere in a-Order or in a-Expense… you would spend hours looking for the PNG, or JPG or GIF and you will never find it, because it is very well concealed. Can you guess where it comes from?

Hint: page 115 of Vittorio’s excellent book.

Bonus question: how does the IdP know all the applications the user accessed to?

By the way, all this is now working on the new updated samples which we will post to our CodePlex site very soon.

ACS as a Federation Provider – Claims transformation

Eugenio Pace - MSFT — Mon, 14 Feb 2011 23:31:56 GMT

To work properly, a-Order needs a number of claims to be supplied:

User name
Organization
Role

The "Organization” claim is used to filter orders belonging to a specific customer of Adatum. For example, Litware users (like Rick) will eventually end up with a token containing a claim with “Organization=Litware”. All this is done in step 3 here in the diagram below:

Adatum’s FP takes whatever token it gets from the outside world and “normalizes” it to whatever the application needs. ADFS for example, ships with a powerful language to define these transformations. In our sample, we ship a simple “simulation” of a real STS, so our rules are all coded in C# and are obviously not “production”:

With ACS in the picture there are 2 places where transformation could happen though:

In ACS
In Adatum’s FP

In this scenario Adatum owns both (its own on-premises issuers and an instance in ACS), so it has full control of either components. Which one to use depends on many factors and there’s no “single right” way of doing it. Let’s consider one reason to keep mappings on Adatum’s side. for this we’ll pick one of the transformations required: the simple rule of associating “Mary@Gmail.com” with Organization=“Mary Inc”.

This rule would be fixed in ACS, there is no dynamic discovery or lookup code that ACS can execute at this time. It is likely that Adatum keeps a master record of all the companies it works with and the contact information associated with them. If that is the case, it’s probably better to have ADFS call a component or the master record database using the built-in SQL integration capabilities (if using ADFS). If Mary changes her e-mail, everything would just work. If the rule was in ACS, it would require Adatum to update the rule every time there’s an update.

Of course, ACS does provide an API for updating the configuration. So you could achieve something similar by just automating the update. Different companies will be more or less comfortable with one approach or the other.

The highest order bit in this situation is that the app remains completely isolated from these changes, as CodingOutLoud mentioned in his comment in a previous post.

Our next project – Claims based Identity and Access Control

Eugenio Pace - MSFT — Sat, 05 Feb 2011 06:40:46 GMT

Not surprisingly maybe, security in general, and authentication & authorization in particular, is a consistently highly rated concern for our customers. These concerns are especially elevated with those considering the cloud, because they don’t have as much control on the cloud as they would typically have in their own datacenters. Sometimes, one could argue, for their own benefit, but that is a different discussion.

The “Claims Identity Guide” published in December 2009, was a foundational component in our “Cloud series” that followed it: Moving Applications to the Cloud, Developing Application for the Cloud and the recently released Windows Phone 7 Developer Guide. The identity content in all of them, is essentially based on the core scenarios and design principles described in the claims guide.

With the Claims guide we also pioneered a new style and design in our books, and it was very well received! We’ve got some great feedback from you on the content and the approach. Exciting things are happening in the identity space and we want to continue to help you create great solutions using these new components.

Our next project then is an extension to this guide that will address two new areas:

1- Access Control Service (ACS) V2, in the Windows Azure Platform will be available in production soon. ACS opens the doors to advanced identity management scenarios including federation, interop with popular identity standards such as OpenId, OAuth, SWT and SAML, use of popular social identity providers such as Facebook, Windows Live ID and Google. All of this is available today in labs.

2- SharePoint 2010 is “claims enabled”, meaning that it natively supports advanced identity management based on WS-Federation.

Interestingly (or not maybe), the core scenarios remain the same but the implementation details change and new interesting things can now be done much more easily. More or less our scope now looks like this:

The “blue” line is the existing content, “green” and “black” are the new chapters. Notice that they almost mirror what’s covered today. News and updates (including drafts, early samples, etc) will be published on http://claimsid.codeplex.com

As usual, we welcome feedback very much!

A year’s balance–next project

Eugenio Pace - MSFT — Wed, 26 Jan 2011 18:02:30 GMT

A little bit late for a year balance since the year has already started, or so I’m told. Anyway, as we prepare for the next project, I reflected on my team’s work for the last 18 months. 18 months is more than a year, so you might wonder why am I doing a year balance on the work done on 18 months? Good question.

Does content that nobody sees and uses really exist? Like the tree falling where nobody can listen. Does it make a sound? I figured that what you cared the most is the stuff that was available to you, not what we actually do here in the remote American northwest and keep to ourselves.

Let’s say then, that the output of that last 18 months was available to you in the last 12 months. Makes sense?

And here it is:

A Guide to Claims based Identity

This guide published a year ago, laid the foundations for all subsequent books. We heavily reused the core designs explained in this little book. We also explored a new format for our books, and a new style. This book inaugurated the “tubemap”: the diagram we used from then on to explain in a single picture the entire scope of the content.

Credits to our brilliant partner, Matias Woloski. Little known secret: VS 2010 samples of the book are available on codeplex.

Moving Applications to the Cloud

Our first book specifically focused on Windows Azure. We explored the considerations of migrating (and optimizing) applications for the cloud. As a colorful anecdote, this book includes an Excel spreadsheet with dollar amounts! A technical book with economics! Some were very opposed to it, and $ is a big deal in PaaS (and SaaS, and IaaS, and XaaS)! Money is a big motivator and every month, you get direct feedback on how you are using the platform. Other nuggets worth mentioning: MSBuild tasks to automate deployment, setting up multiple environments (think “Dev”, “Test”, etc.). It’s quite a popular book: made it to the top 25 in O’Reilly this week.

Developing Applications for the Cloud

Our second book on Windows Azure Platform. This time with no legacy constraints. Ah! the joy of building something from scratch using the greatest and latest! Notice the “1” and “2” on the covers of this and the other book? Well, it turns out people had quite some difficulty differentiating one from the other. So we re-designed the cover with the numbers now. Yes, we learned quite a bit on book design too. In addition to the end to end case study,

In addition to the end-to-end scenario (the surveys application we use as the “case study”), a popular chapter has been: troubleshooting Windows Azure apps. My personal favorite content is the little framework we wrote for asynchronous processing with queues and workers. Seems like a common pattern and I’ve already used it in many places.

Windows Phone 7 Developer Guide

The ying-yang of the Microsoft platform in one single book: small, portable devices on one end and the massive, infinitely scalable datacenter in the backend: Windows Phone 7 and Windows Azure. The most controversial aspects of the book? Use of the MVVM pattern is the by far top of the list. Second in the rankings? Use of Rx (Reactive Extensions) for asynchronous communications. Rx is like Linq in its beginnings: mind twisting at first, confusing perhaps, too much “black magic”, but impossible to live without it afterwards. Glad to see the framework available broadly now: .NET, JavaScript, Silverlight, etc.

With regards to MVVM, well…Silverlight might not be fully optimized for this pattern, but we still believe it is worth considering and paying the extra cost if things like testability are important for you. testability is important to us, so we decided to implement it and show you how. We ported Prism to the phone and replaced Unity with Funq for increased efficiency. But of course you don’t have to use any of that. We do expect you to slice and dice the guide as you see fit. Go ahead rip it off.

So, what’s next? What’s next comes in detail in the next post. But here’s in short: what we’d like to do is to extend the identity guide to include some really compelling and demanded scenarios (federation with social identity providers, SharePoint, Access Control Service, etc.) What do you think? Are you passionate about tokens and STSs and claims and WS-Federation, etc.? Have strong opinions on all of these? I’d love to know.

Claims Identity Guide samples updated

Eugenio Pace - MSFT — Tue, 03 Aug 2010 06:26:43 GMT

I’ve just uploaded to CodePlex updated samples for the Claims based Identity Guide. This have all been adapted to work on Visual Studio 2010, .NET 4.0 and MVC 2.0. See here for downloading the bits.

From the release notes:

Required configuration changes for IIS, DevFabric and Windows Azure

Both solutions 1-SingleSignOn and 5-WindowsAzure involve the a-expense.ClaimsAware project.
This solution is configured by default to run hosted in IIS, but the solution 5-WindowsAzure will run in a different environment (DevFabric and Windows Azure).
Please find the notes about the required required in the microsoft.identityModel section of the web.config of the a-expense.ClaimsAware project.

Cookies encrypted using RSA
As mentioned in the guide, the federation cookies are now encrypted using an RSA algorithm as we recommend in the guide. This change enables the involved sites to support web farm scenarios. This involves the following changed lines from the previous release:

In global.asax.cs

protected void Application_Start()
{
	FederatedAuthentication.ServiceConfigurationCreated += this.OnServiceConfigurationCreated;            

	...
}

private void OnServiceConfigurationCreated(object sender, ServiceConfigurationCreatedEventArgs e)
{
	List<CookieTransform> sessionTransforms =
	new List<CookieTransform>(
	new CookieTransform[] 
		{
		new DeflateCookieTransform(), 
		new RsaEncryptionCookieTransform(e.ServiceConfiguration.ServiceCertificate),
		new RsaSignatureCookieTransform(e.ServiceConfiguration.ServiceCertificate) 
		});
	SessionSecurityTokenHandler sessionHandler = new SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());

	e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(sessionHandler);
}

These are exactly the same settings we use in the Windows Azure Architecture Guide.

In web.config:

<configuration>
    ...
    <microsoft.identityModel>
        ...
        <service>
            ...
			<serviceCertificate>
                <certificateReference x509FindType="FindBySubjectDistinguishedName" findValue="CN=localhost"/>
			</serviceCertificate>
        </service>
    </microsoft.identityModel>
</configuration>

Request validation in ASP.NET 4
ASP.NET by default validates all the POSTs done to the web application. This validation checks that the input is not dangerous. By default, an XML document that is not encoded is considered dangerous by ASP.NET. A token is normally submitted to the site as an XML document that is not encoded. To avoid getting an exception when the token is posted, you will add a class that will check if the input is indeed a security token. If it is it will return true and will let the request continue. If not, it will throw the regular "A potentially dangerous Request.Form value was detected..." exception.

The class WsFederationRequestValidator has been added for this purpose and it is enabled through the following web.config line:

<system.web>
    <httpRuntime requestValidationType="WsFederationRequestValidator" />
</system.web>

Windows Azure Architecture Guide – Part 2 – TailSpin Surveys – AuthN and AuthZ

Eugenio Pace - MSFT — Mon, 24 May 2010 23:38:59 GMT

Tailspin Surveys is a multitenant, SaaS solution, targeting many different customers. Some of these customers might be “enterprise” with “Big-IT” and are likely to demand advanced integration capabilities for identity (e.g. identity federation). Others, potentially smaller, are likely to not require these. Even smaller companies (e.g. someone working from home) might even want to reuse one of their existing identities (their e-mail provider, their LiveID, etc)

These 3 possibilities are illustrated above:

Adatum (the “big company”) uses ADFS to issue tokens for TailSpin Surveys. They want their employees (e.g. John) to have SSO between their own applications (potentially on-premises, but not necessarily). TailSpin Surveys will just trust their identity provider (ADFS in the example). Tokens issued by Adatum’s identity provider are therefore accepted in Tailspin Surveys.
Fabrikam (the “small company”). It has AD, but no ADFS (or any other equivalent infrastructure). The can’t issue tokens that TailSpin can understand and they have no desire to change anything from their side. For customers like Fabrikam, TailSpin provides an identity provider of their own that they can use (they federate with themselves). The biggest drawback is that Fabrikam users will have to remember another username/password, but…not many employees in Fabrikam use Surveys anyway. With this architecture however, TailSpin prepares better for the future. When Fabrikam upgrades their infrastructure, they would simply change the trust relationship.
Mark working from Home (a super small company). Mark doesn’t have an ADFS under his desk. It is likely that Mark does most of his work from a single PC, with quite a bit of software being delivered to him as a service (like Surveys). Mark however, already uses LiveID for mail (e.g.Hotmail) and various other things. For people like Mark, TailSpin offers the opportunity to associate this external identities with the application.

What’s important is that the application (Surveys) is completely agnostic of how the users authenticates. All this is delegated. trust is established as part of the on-boarding process when a new tenant subscribes to Surveys. This of course can be highly automated or completely manual.

If all this sounds familiar to you, don’t worry. You are not crazy :-). We have covered this same scenario many times already:

Exploring the Service Provider track – First station: Fabrikam Shipping – Part I (the scenario & challenges)

Exploring the Service Provider track – Fabrikam Shipping Part II (Solution)

Fortunately, most of the design needed for TailSpin is already covered in the “Claims Identity Guide”. There’s quite a bit we are reusing from it. Since Surveys is an MVC application we will be using exactly the same approach for securing it with claims. This other post describes how it works:WIF and MVC – How it works

WIF and MVC – How it works

Eugenio Pace - MSFT — Sat, 03 Apr 2010 16:03:21 GMT

I got a few questions from people on how the “Federation with Multiple Partners” sample of the guide works, so I figured I would just write it down in one place for eternity.

The guide explains all sequence in quite some detail (see pages 88 to 97), but sometimes a diagram is more helpful, so here’s a sequence diagram that describes all interactions:

An un-authenticated user browses a protected resource, say the “Shipping” page (which translates into a method in a Controller).
The Controller is decorated with the AuthenticateAndAuthorizeAttribute which implements MVC’s IAuthorizationFilter interface. Because the user is not authenticated yet, it will issue a SignInRequest to the configured issuer (this results in a redirection to the issuer). Among other tings it passes the user original URL in the context (wctx) of the request (in this example is the “Shipping” page).
The Issuer authenticates the user with whatever means and if successful, it issues a token for the user for that application.
The Token and the the context information is passed back to the app to a specific destination (indicated in the realm). In the MVC application, this is just another controller (“Home” in our sample, method “FederationResult”). This controller is not decorated by the AuthenticateAndAuthorizeAttribute.
The request however, does go through the WIF Module (the “FAM” in the diagram above). WIF will validate the token and create a ClaimsPrincipal that is eventually passed on to the controller.
The Home Controller inspects the context parameter, extracts the original URL (remember the context is preserved throughout all hops) and then redirects the user there.
The redirect will go again through the filter, but this time the user is authenticated.
Any authorization rules are performed (in our example, we checked for specific Roles) and if all checks pass…
The specific controller is finally called (e.g. Shipping).

A couple notes:

Everything within the green box above happens only when there’s no session established or when the session expires. Once there’s a session, the requests only go through the filter.

In our sample, there’re actually two Issuers. This is because the sample deals with “Multiple Partners” each one with its own Identity Provider, a scenario that makes convenient to have another intermediate Issuer (a.k.a. “Federation Provider”). I didn’t add it in the diagram above just to keep things simple and focus on the specifics of MVC and WIF.

Because the protocol uses redirections, interactions in the diagram above are “logical”. Whenever you see an arrow with “redirection” label, what actually happens is that the response is sent to the browser and then the browser initiates the interaction with whatever you are redirected to:

In our sample we chose to use “roles” as a way of providing access:

But it should be clear that you could use anything. Repeat: “roles are claims, but not every claim is a role” :-)

Also, this declarative model might not always work. You might have to make decisions on the parameters of the call, and since you have access to the claims collection (through the principal), you can programmatically use them for more advanced behavior. Using roles is just convenient for an examples.

Windows Azure Guidance – First version of a-Expense in the cloud

Eugenio Pace - MSFT — Tue, 23 Mar 2010 23:16:49 GMT

Available for download here, you’ll find the first step in taking a-Expense to Windows Azure. Highlights of this release are:

Use of SQL Azure as the backend store for application entities (e.g. expense reports)
Uses Azure storage for user profile information (the “Reimbursement method” user preference)
Application no longer queries AD for user attributes needed in the application (Cost Center and employee’s Manager, the expense default approver). These are received as claims in the security token issued by Adatum’s STS.
Authentication is now claims based.
Logging and tracing are now done through Windows Azure infrastructure.
Deployment to Windows Azure is automated.

#1 is straight forward thanks to SQL Azure relatively high fidelity with SQL Server.

For #2, we used the providers included in the Windows Azure training kit (with a few modifications/simplifications). The main challenge here is to initially migrate the data from the “on premises” SQL Server to Azure storage.

#3 is relatively simple by using WIF. The main changes are in the UserRepository class where instead of calling the (Simulated)LDAPProvider, we simply inspect the claims collection in the current principal:

#4 requires “claims enabling” a-Expense. Look inside the web.config for all extra config sections added by WIF:

It also requires a valid “Issuer” of claims. We have included a “Simulated” Issuer that creates the token we need. You’ll find this as part of the solution:

And of course in the application configuration:

We are also using a WIF configuration that is “web farm friendly”. Check the global.asax file for details. Here’s a note on the Claims Guide hat talks about it:

#5 is also rather simple. Because we are using EntLib blocks, we just defined the right trace listener:

The complement to this is a new class in the project (WebRole) where all the initialization happens:

#6 is just a bunch of PowerShell scripts. We are using the Azure CmdLets built by Ryan’s team which are great! These hide us all the underlying details of the Windows Azure Management API.

Some lessons learned

Request information to Azure Mgmt API is case sensitive. We spent quite some time with a silly bug that was just misspelling “aExpense” (it should have been “aexpense”). You don’t get a very insightful error message (“Invalid request”).
As expected, it is a good practice to polish as much as possible on the local development environment before uploading the application to the cloud. You can also test portions online and on-premises (for example: your website can run on the dev fabric, and connect to SQL Azure). We are still working on the details and recommendations.
“Deployment stuck”: sometimes there’s something wrong in the package that prevents the app to start. For example, a missing assembly. The symptom is that the deployment never starts and no errors are reported. This is because the startup of the app fails before diagnostics is initialized.
Use of the API for deployments also allows us to share access to our Windows Azure environment without sharing the (single) LiveID account. Remember the API is protected with a set of certificates that can be individually distributed and revoked.

Windows Azure Guidance – a-Expense “before” on CodePlex

Eugenio Pace - MSFT — Tue, 16 Mar 2010 03:37:42 GMT

First build of our samples is now available on CodePlex. This initial version is the “before the cloud” baseline application, so you won’t find anything related to Windows Azure here.

This week we will take this simple baseline and start moving it to the cloud.

Goals for this next iteration are to:

Claims-enable the application to keep SSO experience for users. We will use WIF for this.
Remove dependency with AD for querying the user Manager and Cost Center. This will be done by sending this information as claims as opposed to having the application querying AD. We want to avoid having to call back into Adatum from a-Expense.
Deploy an Identity Provider on Adatum (e.g ADFS). This is the issuer of security tokens for a-Expense. It will be configured to issue the claim set a-Expense needs (e.g. employee, Cost Center, employee manager)
Move database to SQL Azure. This is straight forward. We may add some connection retry logic to the data access layer to increase resiliency. But it should “just work”.
Move the Profile storage to Azure Table storage. This database is fairly small and has a simple data model. There’s really no need for full relational support.

How it works:

John @ Adatum opens the browser from his domain joined machine (he’d be already authenticated against AD)
John browses a-Expense (hosted on Azure)
Since there’s no session yet between a-Expense and John, a-Expense will redirect him to the configured trusted claims issuer (in this case Adatum’s ADFS)
ADFS authenticates John (using the Kerberos ticket in John obtained at logon) and issues a token including: John’s name, his manager name (e.g. Mary) and the Cost center he belongs to.
John’s browser posts this information back to a-Expense where WIF parses the token, validates it and creates an IClaimsPrincipal
John’s preferences (e.g. the reimbursement method) are retrieved from his profile. There are no changes to the application as it is using the contract of ASP.NET Profile provider.
Any exceptions are logged to Windows Azure diagnostics. Again, no changes to application as it was using EntLib for this. It just requires a configuration update.

In a nutshell:

We are trying to keep things as simple as possible.

A Guide to Claims based Identity – Released - The strategy behind it and our plans

Eugenio Pace - MSFT — Tue, 09 Mar 2010 00:01:07 GMT

As most of you know, the Guide for Claims based Identity is officially released. We’ve been “technically done” for a couple months, but it just takes some time for all content to be pushed to MSDN, an ISBN to approved, the final PDF to be ready for publishing and the process with the printer to be started.

So now that this is done I wanted to take an opportunity to share with you the reasons we invested on this guide and our plans moving forward.

There should be little doubt that Microsoft is betting heavily on “the cloud”. We knew this for quite a bit, way before Windows Azure was even called that. So one key question we asked ourselves at that time: what can we do today to help customers prepare for that? And “today” is a very important constraint. Back in June 2009, we knew Azure was coming, but features and implementation details were constantly changing. Investing on Azure specifics, would not have been wise; as the shelf-life of our deliverables would have been very short.

Looking at various scenarios for application development, it became quite clear to us that identity management was pretty basic thing that you had to get it right before considering serious development on the cloud. Especially if you are a company with quite a bit of on-premises investments considering moving some of those to the cloud. And this is a big segment of our customers.

So you take this, you add the fact that key technologies were in the last phase of being released (e.g. WIF and ADFS) and you now see why writing a guide on claims based identity made sense to me…It’d be small, simple deliverable, but a key stepping stone to our work on the cloud.

But there’re always tradeoffs. And the compromise was not to ship anything targeting Azure in 2009. Many questioned this and asked me: why aren’t you doing anything for this key platform? claims? identity? single-sign-on? WTF?

In retrospective I’m very happy of my decision and investment proposal. The jury is out on the guide itself of course, but here are some proof-points on the rationale for writing it:

This year’s RSA conference in San Francisco was about . . . the cloud.

During his keynote, Scott Charney (our own CVP Trustworthy Computing), said:

“…identity is so important in the context of the internet generally. It actually becomes an amplified issue in the cloud. It gets its own place in the stack…”

Travis Spencer, security expert (who we were very lucky to have as a reviewer for our guide), commented on the RSA conference:

…identity is going to be a fundamental obstacle that we must overcome. Including wording on his slides, Charney said identity over 25 times in his short address. Microsoft, all the other speakers, and myself believe that identity is key in the adoption of cloud computing which is the future of all organizations…

And this is from Art Coviello (Executive Vice President, EMC Corporation and President, RSA, The Security Division of EMC)

…enterprises [will] start to outsource their infrastructures to external service providers. But you won't want any part of that unless service

providers can demonstrate their ability to effectively enforce policy, prove compliance and manage multi- tenancy. At this stage, federation becomes an important capability.

Organizations will need the ability to dictate and federate identity and policy to their service providers on how information is accessed and handled.

Hey, even “amplified” was a word I used back then :-).

These are just a couple of examples that are very much in line with our strategy in delivering this guide: a required step towards cloud guidance.

Which brings me to the next topic: our plans for the next months.

Scott, our Dev Lead, has written an excellent summary, so I won’t bore you with different words and same meaning. We just started this project, again with a world class team and extended reviewers. What’s important to highlight though, is that in tune with the cloud’s agility, we are aiming at smaller pieces of content available more often.

My next posts will be about the scenarios, challenges and topics we want to cover. As usual, we’d live your input.

I very much look forward to working on this project and to getting your feedback so we can help you be more successful.

Just Released – Claims-Identity Guide online

Eugenio Pace - MSFT — Fri, 29 Jan 2010 20:12:53 GMT

The entire book is now available for browsing online on MSDN here: http://msdn.microsoft.com/en-us/library/ff359115%28lightweight%29.aspx

Now, to be honest, it doesn’t look as nice as the printed book (small preview here):

But everything is in there! (and doesn’t look that bad at all either, it’s just I really like the printed version :-) ).

What’s in there?

If you are new to identity federation, reading the Preface and Introduction to Claims are strongly recommended before diving into any of the scenarios. Claim Based Architectures is optional, but a good read anyway to understand the underlying protocols and how WIF works.

Here’s a quick map of the technologies covered in each of the following chapters:

Chapter	Technologies	Topics
Web Single-Sign On	ASP.NET WebForms	Single company SSO. Using WIF on WebForms based applications. ”Before” and “after” scenario. Using claims for user profile information.
Windows Azure	ASP.NET WebForms on Azure	Hosting a claims-aware application on Windows Azure.
Federation	ASP.NET WebForms	SSO across security realms. Simple Home Realm Discovery. Federation Provider (R-STS). Claims transformation.
Web Services	WCF, WPF	Federation across security-realms with “Active clients” using WCF bindings. Claims transformation.
Federation with Multiple Partners	ASP.NET MVC	Using WIF on MVC applications. More advanced Home Realm Discovery. Managing multiple trust relationships.

We also have a couple of Appendices for more details on relevant protocols, certificates, etc. Worth reading if you are interested in the lower level details and the what happens “under the hood”.

All sample code is available for download here.

if you have any feedback, which is always very welcome, please join us in our discussion board.

ADFS / WIF on Amazon EC2

Eugenio Pace - MSFT — Wed, 13 Jan 2010 04:46:00 GMT

Steve Riley’s post on growing interest from Amazon customers on identity federation is consistent with what I hear from our own customers.

As part of our project, we actually tested the two scenarios he describes on EC2:

“I imagine most scenarios involve applications on Amazon EC2 instances obtaining tokens from an ADFS server located inside your corporate network. This makes sense when your users are in your own domains and the applications running on Amazon EC2 are yours.”

This would be exactly Scenario #1 in the guide, hosting a-Expense sample on EC2:

The guide covers a similar deployment on Windows Azure.

“Another scenario involves a forest living entirely inside Amazon EC2. Imagine you’ve created the next killer SaaS app. As customers sign up, you’d like to let them use their own corpnet credentials rather than bother with creating dedicated logons (your customers will love you for this). You’d create an application domain in which you’d deploy your application, configured to trust tokens only from the application’s ADFS. Your customers would configure their ADFS servers to issue tokens not for your application but for your application domain ADFS, which in turn issues tokens to your application. Signing up new customers is now much easier.”

And this is exactly what we cover in the chapter “Federation with Multiple Partners” with Fabrikam Shipping sample:

Note: You could implement all these with ADFS v1 and Windows Server 2003. But now that Amazon support Win2008, you can deploy ADFS v2 so the story is even better.

In both cases, if the IP (the ADFS server in each company) is exposed to the internet, then users will also have easy access to EC2 hosted systems using the same corporate credentials.

The bottom line is that with ADFS & WIF it is very easy to enable a seamless login experience for your applications, regardless of where they are actually hosted. What’s the catch? Well, your app has to be “claims aware”. If you are application uses say, Windows integrated security, then you need to either:

1- Convert it so it understands claims.

2- Leave it on your premises.

3- Host it in an environment that supports the required network protocols. Typically, you need a VPN between the 2 datacenters (yours and the hoster’s).

#1 depends on your application architecture. The first scenario of the guide examines a simple “before and after”. For #3, you can use Amazon’s Virtual Private Cloud service, albeit at a much higher cost.

Update: fixed typos. Added link to David Chappell's whitepaper.

Updated code samples & chapters for Claims Identity Guide – Release Candidate

Eugenio Pace - MSFT — Mon, 21 Dec 2009 23:12:11 GMT

In synch with the availability of ADFS V2.0 Release Candidate, I’m very happy to announce that we are posting a new update of the guide. Our own “RC”.

You’ll find new samples and new chapters. Both content complete now.

We are now covering the following scenarios:

Single Sign on for web applications: one company, 2 applications, before and after claims
Windows Azure: an extension of scenario 1, this shows how to host a web application in Windows Azure and keeping SSO experience.
Simple federation sample: 2 companies collaborating. SSO across different security realms.
Federation with multiple partners: demonstrates an application with multiple federation relationships. It also shows WIF and MVC.
Web Services: this is essentially scenario #3, but using WCF and a WPF smart client.

The samples are packaged now as a self-extractable zip file and includes a dependency checking tool that will help you identify, install and configure all pre-requisites:

Note: the tool is not yet signed, you will need to first run Set-ExecutionPolicy RemoteSigned in PowerShell.

The documents cover all scenarios listed above, in addition to the introductory chapters which are a must read if you are new to the world of claims. We have also included four appendices on various common subjects (e.g. certificates usage, detailed message exchange between clients and relaying parties, standards used, etc).

Please bear in mind, that these documents are not formatted to the final layout. That’s something we’ll do at the end of the project. However, the content is complete and we expect only minor changes and fixes to happen from now on.

I want to thank my team for all their hard work, and all external reviewers and advisors for all their feedback!

I hope you enjoy this guide!

Link to download: http://claimsid.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=37515

RIA Services and WIF – Part II

Eugenio Pace - MSFT — Wed, 25 Nov 2009 18:26:32 GMT

As promised in my previous post, here’s the second part of my findings playing with WIF and RIA Services beta. This time, I used the HRApp sample available here.

The initial steps are essentially the same I described before:

1- Installed the sample and make sure it runs

2- Ran “FedUtil” which:

a- Created an STS and added it to the solution.

b- Change the application web.config with necessary settings for WIF (added modules, added federation information, etc)

3- F5 and voila. It just works:

My next step was to make a few modifications to:

1- Transfer “Roles” information to the UI. I wanted that information to be available on the Silverlight app and eventually drive UI behavior based on that.

2- Add finer grained Authorization logic to the service. For example, I wanted not only authenticated users to approve sabbaticals, but only those who are “Managers”

More good news! It turns out this is very easy to implement:

For #1, I simply used the same technique I used in my original prototype (adding a RoleProvider that inspects the Role claims):

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();
}

Note: in RIA Services beta, “RiaContext” has been replaced by “WebContext”. So instead of using: RiaContext.Current.User.Roles you use: WebContext.Current.User.Roles.

The second requirement is even easier. RIA Services ships with a built in attribute you can use to decorate a method in your service: RequiresRoleAttribute.

So, I simply replaced “RequiresAuthentication” in the original sample for:

[RequiresRole("Manager")]
public void ApproveSabbatical(Employee current)
{
    // Start custom workflow here
    if (current.EntityState == EntityState.Detached)
    {
        this.ObjectContext.Attach(current);
    }
    current.CurrentFlag = false;
}

The STS that FedUtil created for me, adds this claim to the token when I authenticate (see inside GetOutputIdentityClaims method in CustomSecurityTokenService.cs):

    ClaimsIdentity outputIdentity = new ClaimsIdentity();

    // Issue custom claims.
    // TODO: Change the claims below to issue custom claims required by your application.
    // Update the application's configuration file too to reflect new claims requirement.

    outputIdentity.Claims.Add( new Claim( System.IdentityModel.Claims.ClaimTypes.Name, principal.Identity.Name ) );
    outputIdentity.Claims.Add( new Claim( ClaimTypes.Role, "Manager" ) );

If now I change “Manager” for “Employee”, RIA will raise an “Access Denied” exception:

This works for Roles, but what if you wanted to express access rules based on other claim types (repeat after me: Roles are Claims, Claims are not Roles)? Let’s say, you have to be in a “Manager” role working in the “HR” group to approve sabbaticals:

[RequiresRole("Manager")]
[RequiresGroupMembership("HR")]
public void ApproveSabbatical(Employee current)

All you need to do is create a RequiresGroupMembershipAttribute and inspect the claim set for presence of a claim of type “Group” with value “HR”:

public class RequiresGroupMembershipAttribute : AuthorizationAttribute
{
    public string requiredGroup;
 
    public RequiresGroupMembershipAttribute(string group)
    {
        this.requiredGroup = group;
    }

    public override bool Authorize(IPrincipal principal)
    {
        var identity = ((principal as IClaimsPrincipal).Identity as IClaimsIdentity);
        return identity.Claims.Exists(c => c.ClaimType == "http://hrapp/Org/Groups" && 
                                                 c.Value == requiredGroup);
        
    }
}

and add the claim to the STS:

outputIdentity.Claims.Add( new Claim( System.IdentityModel.Claims.ClaimTypes.Name, principal.Identity.Name ) );
outputIdentity.Claims.Add( new Claim( ClaimTypes.Role, "Manager" ) );
outputIdentity.Claims.Add( new Claim( "http://hrapp/Org/Groups", "HR") );

Of course you could refactor the above to accept any claims, not just Groups or Roles. Something like:

public class RequiresClaimAttribute : AuthorizationAttribute
{
    private string requiredClaimType;
    private string requiredClaimValue; 

    public RequiresClaimAttribute(string claimType, string value)
    {
        this.requiredClaimType = claimType;
        this.requiredClaimValue = value;
    }

    public override bool Authorize(IPrincipal principal)
    {
        var identity = ((principal as ClaimsPrincipal).Identity as IClaimsIdentity);
        return identity.Claims.Exists(c => c.ClaimType == requiredClaimType && 
                                           c.Value == requiredClaimValue);
    }
}

and

public class RequiresGroupMembershipAttribute : RequiresClaimAttribute
{
    public RequiresGroupMembershipAttribute(string group) : base("http://hrapp/Org/Groups", group)
    {
    }
}

Then, you could write:

[RequiresRole("Manager")]
[RequiresGroupMembership("HR")]
[RequiresClaim("http://hrapp/Location", "UK")]
public void ApproveSabbatical(Employee current)

Caveats: this is sample code, so I’ve not invested much in error handling, etc. This is “as is”.

Updated RIA and WIF samples – Part I

Eugenio Pace - MSFT — Sun, 22 Nov 2009 14:37:17 GMT

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.

WIF is RTM

Eugenio Pace - MSFT — Tue, 17 Nov 2009 20:54:32 GMT

Windows Identity Foundation is here! Congrats to my colleagues shipping great Framework.

http://msdn.microsoft.com/en-us/evalcenter/dd440951.aspx

Claims based Identity Guide – New release and PDC goodness

Eugenio Pace - MSFT — Sat, 14 Nov 2009 15:25:55 GMT

New updated chapters & samples are posted on CodePlex. The samples are all updated for WIF RC and include new scenarios and technologies (e.g. web services with WCF and web sites with MVC).

If you are going to PDC, lot’s of interesting things are happening there. Of all things, you will have a chance to see (and speak) to the faces behind the blogs: Vittorio Bertocci, Matias Woloski, Keith Brown.

We have printed a limited amount of “preview” copies of the Guide. You can get them at Pluralsight’s (#441), patterns & practices and Identity booths.

In addition to the “previews”, Pluralsight is giving away a ton of great content: (3) Zune HDs loaded with Pluralsight On-Demand! content, Pluralsight Cloud tag t-shirts & 1-week subscriptions to Pluralsight On-Demand!. And, if let them know, they will be hosting their first-ever annual Pluralsight Customer Appreciation Party. Invite required for entrance.

Sessions you don’t want to miss:

Windows Identity Foundation Overview

Vittorio Bertocci in 403AB on Wednesday at 11:30 AM

Hear how Windows Identity Foundation makes advanced identity capabilities and open standards first class citizens in the Microsoft .NET Framework. Learn how the Claims Based access model integrates …

Claims-Based Identity

Keith Brown in 309 on Thursday at 11:30 AM

Are you interested in or currently building out applications that use claims-based identity? Come join others who are also working on similar systems and discuss your successes and pain points with …

Software + Services Identity Roadmap Update

Kim Cameron, Dmitry Sotnikov in Petree Hall D on Tuesday at 11:00 AM

At PDC 2008, Microsoft unveiled a comprehensive offering of identity software and services, based on the industry standard claims-based architecture, and designed to address the rapidly growing …

Enabling Single Sign-On to Windows Azure Applications

Hervey Wilson in 403AB on Wednesday at 3:15 PM

Learn how the Windows Identity Foundation, Active Directory Federation Services 2.0, and the claims-based architecture can be used to provide a uniform programming model for identity and single …

How Microsoft SharePoint 2010 was Built with the Windows Identity Foundation

Sesha Mani in 403AB on Thursday at 3:00 PM

Explore how SharePoint 2010 has undergone a shift in identity and access control by adopting the claims-based object model offered by Windows Identity Foundation (WIF). Learn how SharePoint 2010 …

Leveraging and Extending Microsoft SharePoint Server 2010 Identity Features

Venky Veeraraghavan in 403AB on Tuesday at 3:00 PM

Get an architectural and programmatic overview of Claims based Identity implemented in SharePoint 2010 including how identity is dealt with at Sign-in and for service calls both within SharePoint and …

Have a great time in L.A.!

Claims based Identity & Access Control Guide – Updated drafts & samples available

Eugenio Pace - MSFT — Tue, 20 Oct 2009 19:28:53 GMT

Yesterday, we uploaded a new release of the Guide and the samples. You can download the content from here. (Note: if you downloaded them yesterday, you might want to check again. We mistakenly uploaded the samples with no docs. It is fixed now).

You’ll find:

Updated introduction & WebSSO chapters, incorporating quite a bit of feedback
New updated samples, including scenario #2 (Federation with Partners). This is inspired in this article I wrote some time ago.

Getting started with the samples:

Just download the zip file, expand somewhere in your disk. There’s a readme.htm with some very basic instructions and prerequisites.You’ll have to run StartHere.cmd batch file with elevated privileges (this essentially installs necessary certificates). Open the solution (as admin), compile and run.

Prerequisites haven’t changed:

Visual Studio 2008
IIS (for HTTPS)
WIF

There are 2 scenarios folders now: scenario #1 (WebSSO), which is the same we published a couple of weeks ago. Then there’s the new one that shows federation between Adatum’s a-Order and Litware.

The first time you open Visual Studio, it will create some new web sites for you.It might happen that those websites already exist from previous drop, you might want to delete them beforehand if you expand the files in a different location.

Make sure the default app is “Litware Portal”:

This is the launching point for the application from Litware’s perspective.

The major changes from the code in Scenario #1 is that now Adatum.IdentityProvider has been extended to other things, namely manage the trust relationship between Adatum and Litware. That’s why we now call it Adatum.Issuer. This new functionality includes transforming claims issued by Litware into claims understood by a-Order. All this is happening in the FederationSecurityTokenService class.

Adatum.Issuer is a “mock” STS and its implementation is no more and no less than what is strictly needed for the sample to work. In the real world you would replace it, as we did in our test Lab, with a real/production quality issuer such as ADFS v2.

The transformation rules in our mock STS are trivial and are all implemented in the GetOutputClaimsIdentity method override:

protected override IClaimsIdentity GetOutputClaimsIdentity(IClaimsPrincipal principal, RequestSecurityToken request, Scope scope)
        {
            var outputIdentity = new ClaimsIdentity();

            if (null == principal)
            {
                throw new InvalidRequestException("The caller's principal is null.");
            }

            var claimsIdentity = (ClaimsIdentity) principal.Identity;
            var issuer = claimsIdentity.Claims.First().Issuer;

            switch (issuer)
            {
                case "litware":
                    ProcessClaimsFromLitwareIssuer(claimsIdentity, outputIdentity);
                    break;
                default:
                    throw new InvalidOperationException("Issuer not trusted.");
            }

            return outputIdentity;
        }

The samples contain a number of annotations and hints here and there to explain what is happening. Make sure you hover with the mouse over this little information icon to get extra context:

This is still under development of course, so expect quite some changes. But we hope you’ll find it useful anyway. Feedback is very much welcome as always.

Very special thanks to the following people for their extensive feedback and suggestions for this Guide:

Mario Szpuszta, Pablo Cibraro, Travis Spencer, Mario Fontana, Jason Hogg, Michele Leroux Bustamante, Pedro Felix.

RIA Services and Windows Identity Foundation – Claims enabling a RIA application

Eugenio Pace - MSFT — Fri, 09 Oct 2009 20:35:34 GMT

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:

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

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:

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:

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:

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:

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.

Claims based Identity & Access Control Guide – Early drafts available

Eugenio Pace - MSFT — Sat, 03 Oct 2009 02:20:21 GMT

We finally have a CodePlex site for sharing early content with you all. Check the downloads section for:

A few intro chapters (some of the “theory”, technologies and protocols behind claims based identity)
The first scenario (roughly described in my post here, but better and nicer, and written in English :-))
The sample code for this first chapter

The first scenario is fairly basic. However, I think people with little previous experience with Claims will find this really useful. Those who are very experienced, will probably not find a lot of new content at this point.

Few things to highlight:

On the code:

We wanted to keep it very very simple. Right now the only pre-requisites are: IIS and Windows Identity Foundation (WIF). IIS is needed because some pieces of the samples require HTTPS. WIF is needed because, well…this is about claims right? All the rest is mocked or simulated.

We tried to minimize the amount of setup required, but there are a few steps that are needed (e.g. installing a certificate, enabling HTTPS). There’s a small script that explains what to do. But we added quite some checking and verification here and there to highlight if something is likely to fail due to a problem in the configuration.

The IIS web sites are created the first time you open the solution in Visual Studio. Running the samples you should see:

Wherever you see the little blue “i” icon, there will be a tip with further explanations.

Many things in the samples are simulated. For example, a-Order in the chapter is described as a Windows Authentication enabled app. We don’t want to mess-up with your AD or with your machine accounts & groups. Also, when we claims-enable an app we don’t want to require you to necessarily deploy ADFS. Therefore we included in the solution a “fake” Issuer to create the required claims. The Guide explains the differences between the real scenario and the simulation though; and steps to configure a real scenario.

Following a-Expense (Claims Aware), for example leads you to:

Notice the extra explanation. Generally, you will not see anything automagically happening. The intent is that everything not obvious will have a tips like this or an in-line comment.

On the chapters:

The first three chapters are introductory and you will see a lot of TBDs and comments. All of this is, of course, work in progress; but we’d love your input.

The introduction chapters are mostly “theory”: background, context, terminology, etc. The fourth chapter is the first scenario: WebSSO. You will see callouts here and there from one of our four main characters in the book:

- Bharath, the Security Expert

- Jana, the Architect

- Poe, the Operations guy

- Markus, the Developer

The intent is to highlight specific points of views from each of these guys and enrich the guidance we want to provide.

Important note: these chapters are NOT formatted to the final layout. So, for example, the callouts will be on the margins in the final book. Please concentrate on the content and not on the format for now.

Hope you like it! Let us know what you think!

Exploring the Service Provider track – Fabrikam Shipping Part II (Solution)

Eugenio Pace - MSFT — Fri, 04 Sep 2009 07:45:10 GMT

Now that we presented the scenario & the requirements, let’s take a look at the solution.

What is conceptual solution we propose?

Fabrikam Shipping in the pre-Claims era:

This diagram shows Fabrikam Shipping today if used by Adatum (no claims, no federation):

You will see the usual suspects for a typical .NET web application. Furthermore, Fabrikam is using standard providers for authentication, authorization and profile. In this configuration, everyone in Adatum must use, of course, user name & passwords. The username is the handle associated with a role in the roles database, which drives application behavior (what you can do).

In the example, John from sales, can only Order New Shipments, but Peter from Customer Service, can Manage them.

Making Fabrikam Shipping Claims-Aware

What we want now, is Fabrikam to be claims aware and trust claims issued by Adatum. Claims issued by Adatum will be used for authentication and authorization. We also want to map Adatum internal roles to Fabrikam’s for authorization purposes: who will be a “Shipment Creator”? Who will be an “Administrator”?

Let’s see how this would work:

When John attempts to use FS for the first time (e.g. https://adatum.fabrikamshipping.com), because there’s no session established yet (John is un-authenticated from FS point of view) he will be redirected to Fabrikam’s Issuer (e.g. https://login.fabrikam.com). Fabrikam’s Issuer is trusted by the application.
Again, John will be redirected to Adatum’s Issuer, because that is what Fabrikam’s Issuer trusts.
If John uses a domain joined desktop, he’d already be authenticated in his network and will have a valid Kerberos token. This token is used by the Adatum’s Issuer to create Adatum’s claims: employee name, employee address, cost center, and department John works for.

The process unwinds then:

Adatum’s claims are sent back to Fabrikam’s Issuer, where they are transformed:

- Name, address and cost center are simply copied (no transformation)

- Other rules are applied that will result in a “role” claims to be issued (any of the valid roles FS understands)

More examples of mappings:

exists([issuer == "Adatum"]) => issue(type = "Role", value = "Shipment Creator");

Which can be interpreted as:

“Any employee from Adatum can create shipment orders”

c:[type == “http://schemas.xmlsoap.org/claims/Group”, value == "Shipments"] => issue(type = “Role”, value = “Shipment Manager”);

that would implement the rule:

“Any employee from Adatum in “Shipments” (indicated by group membership) department can manage shipment orders”

2. After these transformation happens, John is finally directed back to the application with the transformed claims.

Adatum could issue Fabrikam’s specific claims, but we don’t want to pollute Adatum’s Issuer with Fabrikam specific concepts (like Fabrikam roles). Fabrikam will allow Adatum to issue any claims they want or can, and then will allow Adatum to configure the system to map these Adatum claims into Fabrikam claims.

Fabrikam will do this for every new Customer using Fabrikam Shipping. Yet, their application will always understand the same set of claims: “Shipment Creator”, etc. FS stays decoupled.

Note 1:
This scenario is almost identical to IssueTracker. If you feel deja-vu, don’t be surprised. Only in IssueTracker, we used .NET Services ACS as the Service Provider (Fabrikam) Issuer.

Note 2:
This scenario is also similar (but not quite the same) to Adatum’s a-Order. Some key differences: Fabrikam is a multi-tenant system, probably with a provisioning experience, that a-Order lacked. This is because in our fictitious (but hopefully realistic) world, the Customer churn in Fabrikam Shipping is much higher than in a-Order. That is, we assume the frequency customers join and leave Fabrikam is higher. Thus, Fabrikam needs to automate this as much as possible.

Note 3:
Yes, there will be another post with Adatum’s side of the story. But I’m sure by now you’ll guess what’s in there.

I’ll cover provisioning in the next post, as it has some interesting discussion points. But you can see some hints here.

Feedback very much welcome.

Post-post announcement:

We hope to have a some running code and much much polished chapters soon. We’ll probably upload those to a CodePlex site. Stay tuned!

Exploring the Service Provider track – First station: Fabrikam Shipping – Part I (the scenario & challenges)

Eugenio Pace - MSFT — Wed, 02 Sep 2009 01:57:10 GMT

Once again, thanks everybody that wrote us with reviews, feedback and suggestions! Please keep it coming! Also: we hope to have soon a CodePlex site where we can start sharing more. We are still working out some details.

As usual, the Disclaimer: this post and the next ones are early drafts to share with you the direction we are taking. They might (and I hope they will) change quite a bit in the actual Guide! We might end up not covering one of these scenarios in the book.

An additional disclaimer for this post: I wrote the whole scenario following the same template of the previous posts and it resulted in a very loooong article. So I divided it into two parts. This is Part I –> the scenario, the challenges and the requirements. Part II will be the solution.

An Ode to Simplification: there’s been quite some debate internally to this project as how to name things, especially “STS” vs. “Issuer” vs. “I-STS” vs. “R-STS” vs. “FP”, etc. Keith has started this on his blog some time ago. We definitely want to keep things simple. As simple as possible, but not simpler. For now we have settled on the term “Issuer”, independently of the logical role it takes part in. In simpler words: what we used to call “Identity Provider” is now an “Issuer”. What we called a “Federation provider” is also an “Issuer”.

Keith is writing a whole section of our book on “Jargon” and meaning of the different terms.

Credits: this scenario is largely inspired on Vittorio’s PDC demo. See here.

The themes for the first “Service Provider” scenario are:

Identity in a SaaS application
Federation with multiple Customers

There’s 1 variations in this scenario:

Automating the on-boarding process

The Introduction

Fabrikam is a company that provides shipping services. As part of their offering, they have an application (Fabrikam Shipping – FS) that allows its customers to create new shipping orders, track them, etc. Fabrikam Shipping is delivered as a service and runs in Fabrikam’s datacenter. Fabrikam Customers use a browser to access it.

FS is a fairly standard .NET web application: the web site is based on ASP.NET 3.5, the backend is SQL Server, etc. In the current version, users are required to authenticate using (guess what): username and password!!

Fabrikam uses ASP.NET standard providers for authentication (Membership), authorization (Roles provider) and personalization (Profile).

Fabrikam Shipping is also a multi-tenant application: the same instance of the app is used by many customers.

One sunny day in Seattle, they sign a great deal with a marquee Customer: Adatum Corp. And Adatum doesn’t like the username and password, because they are working hard to get rid of identity silos. They have 3 concerns:

Usability for their employees. Lack of SSO, forgetting passwords, using sticky notes to remember them, etc.
Maintenance costs:

What happens if an employee forgets his or her corporate password? He will probably call Adatum’s IT help desk. What happens if they use FS and they forget its password? who should they call? Consider this:

If they instruct employees to call Fabrikam’s help desk, there would be a special procedure for IT guys, would probably require training, etc.
If they instruct employees to call Fabrikam directly, they would impact #1

When a new employee is hired, he is already provisioned in Adatum’s systems. They don’t want special processes for FS.

Liability:
1. Adatum has authentication policies that are there for a reason. They also want to retail control on who has access to what (regardless of where that is deployed) and FS is no exception.
2. If an employee leaves the company, he should not have access to FS anymore, effective immediately. If they used username / passwords, they could potentially access FS from other places, even if they are not an Adatum employee anymore.

Back to FS:

Access Control to FS is based on Roles. There are 3 roles:

“Shipment Creators”. Anyone in this role can create new orders.
“Shipment Managers”. Can create and modify existing shipment orders.
“Administrators”. Can configure the system (e.g. look and feel, shipping preferences, billing, etc).

FS also keeps profile information for users, to avoid repeatedly entering common information and preferences. More concretely, FS allows its users to store:

Package Sender information (sender address)
Cost Center information for billing

Fabrikam can open the bills to its Customers by Cost Center. With this, 2 employees from Adatum belonging to 2 different departments would get 2 different bills.

Key Requirements.

Adatum wants SSO for its employees.

Fabrikam wants to avoid storing configuration information about the shipment that can become stale later on (e.g. the package sender information).

Fabrikam wants to bill customers by Cost Center if they supply one.

Some assumptions:

Adatum has an Issuer (see Scenario #1)
Fabrikam can change anything in their application

We’ll look at the solution space in the next post.