Vibro.NET

Brand New ACS Walkthrough on the New Windows Azure Developer Center

Vittorio Bertocci - MSFT — Mon, 12 Dec 2011 18:48:25 GMT

By now, I am sure, you already heard about the flurry of improvements that swept the Azure Land. If you didn’t, please take a moment to go through Bob’s post here: socks will be blown, the Windows Azure team did an *amazing* job.

If you explore the new developer center you’ll eventually land on a brand new howto guide which provides a concise introduction to ACS. If you are new to this space and want to get a feeling of what ACS can do, I am sure you’ll find the new guide useful. If you already know about ACS, you now have a nice, self-contained guide you can use with the ones in your team who need to ramp up.

Have fun, and don’t forget to tune in for tomorrow’s Learn Windows Azure online event! I might even have a brief cameo

Identity Is Your Passion? We Are Hiring!

Vittorio Bertocci - MSFT — Wed, 02 Nov 2011 07:53:22 GMT

We have a number of open positions for developers and testers in the identity team. We are building something pretty awesome, which of course I can’t (yet) talk about, but if you are a regular reader of this blog I can tell you this: you *will* want to be part of it

You can take a look at the details of the various positions here: but in general I can tell you that we seek talented C, C++ and C# developers who like to ship software. If you have experience with distributed services that would definitely help; experience with Windows Azure would be a *really*nice boost.
The list of positions covers a pretty broad seniority spectrum, hence chances are there is a spot that matches with your current career level.

Ah, and just in case the idea of working with yours truly and the (waaaay more) talented people here is not enough:

Microsoft has just been named the Best Place in the World to Work.

‘nuff said, folks.

If you are interested, feel free to contact me: I am glad to chat about this. Looking forward to work with you!

BlobShare Sample: ACS-Protected File Sharing

Vittorio Bertocci - MSFT — Mon, 31 Oct 2011 08:54:38 GMT

Weather is not that good this Sunday afternoon, and the wife warned me already yesterday that today she was going to catch up with the AI class; hence, I think I am going to break the blog-silence and spend some time describing BlobShare, a little jewel my DPE friends quietly released last week (and covered during the latest CloudCover episode, no pun intended).

BlobShare is a very nice Windows Azure sample, which demonstrates one way of solving a very concrete problem: how to share large files on the public internet, while maintaining full control over who can access what?
The usual disclaimers about a sample being a sample apply here, however you’ll be happy to know that DPE has been using an instance of BlobShare for sharing content for many months by now, it started while I was still over there. Many features in BlobShare derive from real usage requirements that emerged while actually using the application. I am so glad to see they finally managed to release it in a consumable form. Good job Wade’s gang!

Many of the things demonstrated in BlobShare have been featured in other samples: exhibit A, the email invitation system (seen in FabrikamShipping, the Umbraco ACS accelerator, etc). However it was always buried within many more moving parts, whereas here it is pretty easy to isolate. I am sure you’ll find it much easier to grok.
The same holds for various other aspects I am often asked about, like how to integrate an incoming IClaimsIdentity with attributes from a store which is local to the application: BlobShare does it to enable one of its key capabilities, enforcing locally stored permissions, hence the signal/noise ratio should be blindingly good.

Do watch the latest CloudCover episode, where Wade & Steve properly introduce the project, talk about setup, etc etc: here I am (surprise surprise) mostly focusing on the identity & access aspects.

Overview

In a nutshell:

BlobShare is an MVC app which sits in front of your blob storage account
The MVC app leverages ACS for admitting users with accounts from any of the identity providers it can trust…

…but it maintains an application-local (SQL Azure) database of user profiles and roles.

local user info and roles are used to establish if a given user has access to the blob he/she is requesting

Basically, all your blobs live in a trusted subsystem: only BlobShare can access blobs directly. BlobShare offers individual URLs for every blob, of course, but they are all rooted in the BlobShare app itself. As you try to get to one blob, BlobShare will funnel you through the authentication process and if it turns out you don’t have permissions for that specific blob, you don’t get access.
That’s pretty handy when you are sharing stuff you want to keep a close eye on: with a shared signature if the URL leaks you’re done, here not only you force authentication, you can even keep a useful audit trail and notice if there’s something fishy going on (if the same user accesses the same content in a small time interval and from many different machines, chances are you have somebody who’s sharing his account).

BlobShare offers a full UI for all the tasks that the flows introduced above entail. Administrators can upload blobs, group multiple blobs in larger sets, create users by sending them an invitation email, assign roles to users, permissions to roles and individual users, and examine a complete audit trail of all the users’ activities. Users can sign up (by responding to an invitation) and access the blobs for which they received permissions for, for as long as those permissions have been deemed valid.

Justo give you a feeling of the kind of things BlobShare keeps track of, below you can find the diagram of its SQL Azure database.

As you might notice, all the access control policy is kept in the database. Here ACS is being used to take care of authenticating with all the various trusted IPs: BlobShare’s setup will add the usual IPs, add the BlobShare instance as an RP, and create pass-through rules for all. BlobShare expects ACS to return a normalized token containing just the NameIdentifier and the IdentityProvider claims (take note if you later add custom providers). Those two claims are used to uniquely identify each user in the BlobShare database. There is no concept of pure, un-provisioned federated user here: if the incoming NameIdentifier-IdentityProvider tuple is not present in the db (and associated to the permissions of the blob being requested) the access is denied.

From the access control point of view, there are three (actually, four) different types of requests that are interesting to examine:

Bootstrap, or Imprinting. The very first time a newly deployed BlobShare instance runs, it will onboard its first Administrator
User redeeming an invitation. One new user received an invitation and is now going through the sign up flow
User accessing a BlobShare URL that points to a blob.
User signing in. Very similar to the above, sans interesting authorization tidbits

Instead of discussing those in abstract, we will explore those paths while walking through some typical application use. In a minute.

As you know I have this unhealthy passion for putting together pictures which show as many things at the same time as I can fit in the allotted real estate. That’s great when you already understand the matter, I find it helps me to understand relationships and an architecture as a whole; but while you are learning it might not offer the most gentle slope for ramping up.
Well, below you can find one such diagram: it lists the relevant moving parts in BlobShare that come into play when a request carrying a token shows up.

Please ignore the details of the flows for now, you can come back to this figure every time we’ll delve in the details of those. The thing I’d like you to observe at this time is how the solution is layered in various elements, each taking care of a specific access control task:

WIF sits in front of the application

The first layer implements the classic mechanisms of federated authentication: forward the user to the identity provider (or to a broker like ACS, in this case) according to the protocol of choice, verify that incoming tokens are well-formed/have not been tampered with/are not expired/come from the expected authority and so on
The next layer is a ClaimsAuthenticationManager implementation. In BlobShare this an especially important stage, as so much information that is relevant to the incoming user’s identity resides in the RP’s database and needs to be reconciled before the call can go any further. Moreover, which information is relevant changes dramatically between call types (more below)
The last layer before giving control to the application is an implementation of a ClaimsAuthorizationManager. This is a cornerstone in BlobShare, as it represents the enforcement stage for the policies defined through the application flow

The application itself will use the incoming claims to customize what is shown (i.e. every user will see only the blobs he/she has access to) and for auditing purposes

IN the rest of the post I’ll go through BlobShare doing some basic tasks. As the elements and the different requests types come into play I’ll add commentary & take the chance to dig deeper in some of those concepts.
As I mentioned earlier, those tasks correspond to questions I get very often, hence I suspect that some of you guys will really like some of this stuff

Imprinting

Handling the administrator of those sites that use federated identity is always an interesting challenge. How to ensure that once you deployed your site, the administrator can log in and start working right away?

Adding a username/password is kind of bad form. Every user can reuse existing social accounts, why should the admin be left out? On the other hand, if you want to authenticate the admin with a social account you have the following problems:

at design time you might not know the values (like the nameidentifier) that will be in the authentication token the admin will send. Without those values how can you tell if the incoming user is really the intended admin?
you might not even know which identity provider the admin will want to use: live id? Google? who knows.

Sure, one could use also with the admin the classic email invitation flow: after all, we are using it for other users right? Unfortunately it might not be a good idea to take a dependency on a setting that the admin itself might be required to provide (in BlobShare the SMTP server is already set up, but it’s just coincidence: I think that the original plan was to make it configurable on first run).

At the time we toyed with the idea of just making admin the first user who logs in in the newly deployed instance: I like to call this imprinting, isn’t this a bit like Konrad Lorentz’s ducks?

However, even if the probability that a random dude beats you to your deployment, it was still a possibility: hence we devised a schema for which at deployment time you establish a secret, and you are required to provide that secret on first run to associate your social account to the administrator user of that BlobShare’s instance.

Easier to show that to describe! Hit F5 on your local instance, you’ll be brought straight to the page below.

At the time this page was called sign up: I am not sure why the guys decided to change it, but it works nonetheless. Just sign in using whatever account you prefer.

You’ll go through the usual dance with your IP and ACS, then land on the page below.

Add the email you want to use, provide the secret and…

…the duckling will think you are Momma, and from now on you’ll have admin access to BlobShare.

How did this happen? Didn’t I say above that one user needs to be in the database in order to have access? Yes I did, but AccountAssociationClaimsAuthenticatonManager makes an exception for the case in which the database has exactly zero users. It even creates a new user for the occasion! The secret verification takes place in the associated controller (point (A ) in the uber-diagram).

Uploading Files

Now that we are admin, we can start to play. Let’s sign in.

..and we’re in (BTW: wow, this sample looks great. The designers did an excellent job).
You might not see anything out of the ordinary, but that’s mostly because you didn’t see that I used Live ID for signing in. Live ID does not give any claims besides the nameidentifier, whereas in the screenshot below BlobShare is clearly greeting me with something else (my email).

That’s because AccountAssociationClaimsAuthenticatonManager graciously recognized me as an existing user of BlobShare, hence retrieved my extra attributes (Name and email, which in this case are both set to the email value) and used them to augment the claims already in the existing ClaimsPrincipal.

Let’s go under Blobs.

Hmm, it’s pretty barren here. Let’s click on Upload, then Single File Upload.

Let’s add a picture I am sure I own the rights for, and jolt down some comments just for color.

…and here there’s our first blob.

Let’s hit on Permissions.

Handling Access Rights and Users

Here I can grant access to this blob for users or roles, but I have none for now (apart from myself and the admin role, who already does have access).

Let’s add a new role, then. Click on Roles on the top bar.

Click new, and you get to the simplest role creation form you’ve seen to date. Once you’re done hit Update.

Excellent, we have a role now; but no user to assign this to. Let’s go to Users by clicking the associated entry in the top bar.

Inviting Users

Here there’s the list of our users, currently including only myself. I could add many at once, but for the sake of demonstration I’ll create just one. Hit on Invite User.

(note: all those controllers, which require administrative privileges, are decorated by a custom AuthorizeAttribute which enforces things accordingly).

The matter is pretty simple: you specify an email address to send the invite to, and you decide which roles the new guy will belong to. Hit Create and you’re done for now.

The user has been created in BlobShare’s database, and an email with the invitation has been sent; however until Adam has not accepted, we don’t know which nameidentifier should be associated to this profile (nor from which identity provider we should expect Adam to come from).

What happened is that BlobShare created a unique ID associated to this profile. That ID will be embedded in one registration URL that Adam will receive in the invitation; whomever will present a token through that URL will become Adam as far as BlobShare is concerned.

Accepting an Invitation

Let’s take a look at things from Adam’s perspective.

Adam receives the invitation mail below. The mail contains the mentioned invitation URL; nobody but Adam (or better, whomever has access to the mailbox specified at invitation time) know this URL, which is a pretty good way to be reassured that we are inviting the right person. Let’s click on the URL.

Here we once again encounter the sign-in page (again, at the time it was supposed to say sign-up and some helpful text, but that’s a technicality). Adam can use whatever account from the listed providers: that account will become Adam for BlobShare. Once again, take a look at AccountAssociationClaimsAuthenticationManager to see how the reconciliation happens.

Once the profile-token reconciliation took place, you can even update some values (like the name that was originally specified when creating the invitation).

Once signed in (again) and gone to Blob, Adam will find that there are still no blobs he can see. Let’s leave Adam for a moment and go back to the administrator’s experience.

Assigning Roles & Permissions

If you refresh Adam’s page, you’ll see that the user is now active and the attributes all have the correct values.

Now that our Colleagues role is non-empty, we can get back there and assign some permissions.

And here it is: the Colleagues role has been granted Read access to our only blob. Note that I could have granted access directly to Adam instead of the group he belongs to; or that I could have put my blob in a blob set and handled access to the set rather than the individual blob. BlobShare is VERY flexible.

It is worth stressing that all those changes are happening in the SQL Azure database, not in ACS: no new rules are being written. In BlobShare all settings are at the RP side.

Accessing a File

Let’s get back to Adam. If Adam hits F5, the browser will refresh & show the newly granted blob.

Adam can hit both the name of the file in the blob (Phoenix in the sample) or Download. Access-wise there is no difference, this only impacts how the file will be served. Clicking on the file will show it in the browser, as you can see below (yes, that was a LONG meeting).

Now, until now I omitted to mention the BlobAuthorizationManager. The reason is that the guy steps out of the way every time the request is going to a controller other than MyBlobs. If it is MyBlobs, as it is the case now, it queries the db (via a service) to ensure that the user has the rights to access the blob he is requesting. Check out the code, it’s very nicely readable.

Reports

Let’s get back to the administrator for one more thing. If you click on Reports, you’ll land on the page below.

Let’s click on User Activity; we’ll see all the things we’ve been doing until now with BlobShare, which is quite handy. If you look at the code, you’ll see that the current ClaimsIdentity is used across the board for retrieving the user info in a nice, consistent way, regardless of whether they come from the identity provider or they have been extracted from the RP database.

Summary

Well, the afternoon kind of stretched well into the evening but BlobShare is a great sample, and I think it deserves all the coverage it can get.

If you are into WIF, this is a great sample that demonstrates how to take advantage of the main extensibility points. Do play with the code, and if you have questions or feedback I am sure that the Wade gang will be delighted to hear you out. If you want to chat about the identity side of things, I am happy to chat as well but I can’t take feature requests, that’s Wade’s jurisdiction

Happy BlobSharing!

TechEd 2011微软中国技术大会：下周与您相约

Vittorio Bertocci - MSFT — Fri, 07 Oct 2011 02:43:00 GMT

亲爱的中国读者，

我很高兴地宣布今年我也将会出席在北京的TechEd技术会议！

我将会在10月13日星期四演讲几个话题；其中的一个话题跟我在几周前的//Build会议上展示的比较相似，另外一个话题将会是基于claims身份架构的深入浅出。

不过我来北京最重要的原因其实是见到你们！我想向你们学习一切有关如何处理你们应用程序身份的问题，这样我才能够把你们的要求带回雷蒙德。我将会有空出席于TechEd 会场星期三（12日）以及星期五（14日）的会议，如果您感兴趣，请跟我联系吧。

谢谢！期待下周与您相约！

维托里奥

附言：十分感谢我的好朋友兼同事王超帮我翻译这篇博客。

P.P.S.: last year’s keynote recording:

Using ACS in Metro Style Applications

Vittorio Bertocci - MSFT — Wed, 14 Sep 2011 18:20:00 GMT

I am sure that many of you, amazed by the fantastic news about the Windows Developer Preview capabilities, wondered if it will be possible to take advantage of ACS even from Metro Style applications.

The answer is “yes, absolutely”.

We’ve been working with the appropriate Windows engineering team to make sure we connect to ACS from Metro style applications by making proper use of the new Windows security features: today we are sharing with you some of the outcomes of that conversation.

More precisely:

If you are at //BUILD, or were watching the keynote in streaming, you just saw a Metro Style app taking advantage of ACS
Today my formidable ex-colleagues in DPE are releasing the Windows Azure Toolkit for Windows 8 which, among other super-cool things, features an ACS sample which demonstrates the same flow shown in the keynote
Tomorrow at 2:30pm I’ll dig deeper in the scenario here at //BUILD

Below I’ll add some details on the first two items.
Please keep in mind at all times that, in line with what you heard these days, what we are sharing on this topic is a developer preview.

John Shewchuk’s Demo in Today’s //BUILD Keynote

If you weren’t following the keynote, or if you were spacing out right at the crucial moment, here there’s a brief summary of what John demonstrated today (minus the notification parts, I am focusing just on authentication here). The demo John showed is a version of the app I built with the help of the Windows guys: Wade made a great job in polishing it and inserting in a realistic scenario, turning the rough developer-oriented prototype in a nice looking demo. In my session on Thursday you are going to see things in details.
I don’t want to spoil the simplicity of the scenario by hitting you with the explanation of what’s going on behind the scenes; not yet. I’ll get to that in a moment.

The application is a very simple travel management utility, with the typical look of the Metro Style app:

If you hit the login button, you’ll be prompted to sign in by choosing among four well-known identity providers.

Let’s pick Facebook: the familiar Facebook authentication UI appears in what looks like a dialog.

Upon successful authentication the application lets you in and retrieves your data.

Simple, right? But there’s more.

If the application ran on a trusted device, and you logged on the machine using Windows Live ID, you are in for a nice surprise. If you launch the travel application on another trusted device, you won’t have to go through the authentication phase again; you will find that you are already logged in!

Now that you saw how the user experience unfolds, let’s take a quick pick under the hood.

The App

The application is Metro style app based on HTML. All the code running on the client site is Javascript. And in Javascript tradition, it is extremely simple.

The Identity Providers

The list of identity providers displayed at sign in time is, surprise surprise, retrieved from ACS. As many of you loyal readers know by now, ACS offers the list of configured identity providers (and their sign-in URLs) in form of a JSON list. And how hard is it to retrieve a JSON list via Javascript? Thought so.

function SignIn() {

    try {

        Show('signon-block');
        var request = new XMLHttpRequest();
        request.open("GET", IPSFeedURL("https://xxxxxxxxxxx.accesscontrol.windows.net"), false);
        request.send(null);
        var jsonString = request.responseText;
        var jsonlist = ParseIPList(jsonString);

        BindJsonToList(jsonlist);
        // result

    } catch (e) {
        ShowDialog(e);
    }
}

Web Authentication Experience in a Metro Style App

The dialog which displayed the Facebook authentication UI is part of a new Windows runtime feature. I don’t want to go too much in details, as I am sure that the Windows guys will talk at length about it and they are THE authoritative source of information about their feature. Here I’ll stick to the talking points they gave me: the WebAuthenticationBroker is a surface that developers can use to host authentication experiences for online services, just like the demo did for Facebook (and would have done for any other provider, had we picked a different one).

function ItemSelected(element) {

    try {
        var acsURL = ipList[element.detail.itemIndex].LoginUrl;

        var startURI = new Windows.Foundation.Uri(acsURL);
        var endURI = new Windows.Foundation.Uri(callbackURL);

        Windows.Security.Authentication.Web.WebAuthenticationBroker.authenticateAsync(
            Windows.Security.Authentication.Web.WebAuthenticationOptions.n,
            startURI,
            endURI).then(callbackACSAuth, callbackACSAuthError);

    } catch (e) {
        ShowDialog(e);
    }
}

Invoking a Service With OAuth

Upon successful authentication, the flow bounces from Facebook to ACS, where a slim, RESTful SWT token is minted. The token is returned from the broker to the application (more about how that happens in the section about the toolkit). The token is then used for securing an OAuth 2.0 call to a service on the travel app backend (on Windows Azure of course, but technically it could live anywhere). The operation in itself is absolutely trivial to implement in Javascript, it’s just a matter of putting the token in the authorization HTTP header according to the OAuth2.0 syntax.

function GetTravelerInfo(token, serviceUrl) {
    try {
        var authHeader = "OAuth " + token;
        var request = new XMLHttpRequest();
        request.open("GET", serviceUrl, false);
        request.setRequestHeader("Authorization", authHeader);

        request.send();

        return request.responseText;

    } catch (e) {
        ShowDialog(e);
    }
}

The token validation on the service side is done via WIF, but given the simplicity of the operation it could be done even directly in the app code.

Roaming Tokens

This is all fine and dandy, I can almost hear you say: but how did you pull off the trick of avoiding the need to re-authenticate on the other device? The answer lies in another great new feature of Windows, the Credentials Vault. The considerations I made earlier about the WebAuthenticationBroker are valid for the Vault, too: in fact, it is coming from the same awesome Windows feature team.
Here I will just say that, as you have seen in the keynote and big picture sessions, Windows is introducing phenomenal new roaming capabilities: if you save your tokens in the Vault, and the correct conditions are met, you can take advantage of those roaming capabilities too.

//saving the token in the Vault
            var vault = new Windows.Security.Credentials.PasswordVault();
            var cred = new Windows.Security.Credentials.PasswordCredential(
                url,
                username,
                token);
            vault.add(cred);

Now, that was quite the whirlwind tour! Don’t get fooled by the length of the post, that is due to the fact that there are so many new things to describe. In fact, I keep being amazed by how little, non-esoteric code all this requires on the client side when you develop Metro Style apps.
What’s that? You want to try it by yourself? Keep reading, then!

The ACS Sample in the Windows Azure Toolkit for Windows 8

Want to take advantage from the Windows Developer Preview of the Windows Azure services you already know and love? Want to learn more about the new Windows Push Notification Services?
Then download the Windows Developer Preview, install it and get yourself a copy of the Windows Azure Toolkit for Windows 8.

The Windows Azure Toolkit for Windows 8 contains a sample ACS application which demonstrates the same flow described earlier for the keynote demo. The notable differences are that the UI is much less fancy (but still metro style!) and the backend is designed to run on the local Windows Azure simulation environment, which makes it especially handy.

In this post I won’t drill too deep in the code, that’s for a future installment (or, if you are at //BUILD and you are interested, come by on Thursday). For now I just want to give you few tips for finding your way through the sample and run it successfully.

Setup

Install the Windows Developer Preview; download the Windows Azure Toolkit for Windows 8 and launch it. That’s all you need to do. The (metaphorically) award-winning Dependency Checker takes care of tracking down everything you need and offer you the right links for downloading/installing it. In fact, I used it for getting Visual Studio 2010 installed and configured side by side with the IDE out-of-the-box in this preview, Visual Studio 2011 Express.

Few suggestions:

Some of the entries in the dependency checker can take a long time. Be patient when
- downloading & installing WebPI (if you don’t have it already)
- enabling the Internet Information Services 7 (IIS7) feature
The ACS sample is in c:\WindowsAzure\WATWindows\Samples\ACS.
In order to use the sample, you need to run SetupSample.cmd in the same folder. You can’t skip this, as the setup needs to adapt the code to the ACS namespace you’ll use and update the namespace itself accordingly
- The setup will ask you for one ACS namespace and its management key. I suggest getting those info in advance: instructions on how to do that are in the readme of the toolkit, in Appendix II
- If you want to use Facebook, you’ll need to create one Facebook app tied to your ACS namespace; the setup will ask for the app ID and the secret. Again, I suggest getting those values in advance

The Sample

The sample includes two solutions:

ACSMetroClient, the Metro style application
ModernCloudIdentity, the service called by the client (and some other stuff)

The Metro style application templates are available only in Visual Studio 11; and as of today, the Windows Azure tools for Visual Studio will work only with VS 2010. This means that you need to open ACSMetroClient with VS11 and ModernCloudIdentity with VS10.

Pro tip: although you can open ACSMetroClient.sln by double-clicking it, it is suggested that you open ModernCloudIdentity.sln by first launching VS10 via the shortcut to VisualStudio2010WindowsAzure.cmd that the setup placed on your desktop, and then you open the solution from there.

The Service solution

The solution contains three projects:

DPE.OAuth, a class library containing an OAuth implementation for WIF (from the good old FabrikamShipping)
ModernCloudIdentity, the cloud project hosting the web role for the service
ModernCloudIdentity.Web, a web role containing the service and a a couple of utility pages (Default.aspx and Bouncer.aspx)

The service part is well known, basically the same as every REST-based sample or hands-on lab we released in the past.

The Default page here is a little trick in this sample for bridging the different ways in which ACS issues tokens in redirect scenarios (in a POST) and the WebAuthenticationBroker expects them (in the querystring of the Url that has been defined as callback). As I mentioned I don’t want to go in details here. I’ll just say that when Default.aspx receives the SWT token from ACS in a classic wresult POST , it extracts the token and adds it in the querystring of a redirect to Bouncer.aspx; but Bouncer.aspx is the designated callback URL, hence the broker retrieves the token from the querystring and returns. More complicated to explain than to do; and in any case, please keep in mind that this is just a sample based on developer preview software.

Hit F5 to start the simulation environment: you’ll get a couple of browsers complaining that you didn’t send a token, don’t mind them and move to the client solution.

The Metro Style client

The client code is really straightforward. It is basically the default app as it comes out of the template, with just few modifications to default.html and default.js:

The UI is really a series of DIVs, which are made visible or invisible depending on where in the app the user. There is a splash screen, a home realm discovery screen, and a service invocation UI. If you follow the flow described for the keynote demo, you’ll see them in that order. The main difference, apart from the look&feel, is that the call to the service does not happen automatically right after the authentication experience but takes place when you click on “Invoke”. Note that the token text is available on the page, so that you can experiment with tampering with the string before sending it and get an “invalid signature” on purpose.
If there is already a token in the vault from former sessions, the app will skip the authentication and go straight to the invoke screen.
The JS contains the logic for moving thru the app, getting the list of IPs and presenting it to the user (databinding is fun! Thanks Giorgio and Jaime for all your help on that), using the WebAuthenticationBroker, the Vault, and performing calls. As mentioned, I won’t go in details yet: we’ll get to this in tomorrow’s session.

Exciting times!
Among all the great news of the last two days, it’s nice to see that claims-based identity is the gift that keeps on giving. I just *love* to see how ACS can really simplify your life even when used with those brand-new development technologies. Looking forward for your feedback!

Guess what?

Vittorio Bertocci - MSFT — Mon, 22 Aug 2011 06:45:09 GMT

…and that’s as much as I can say for now

Hands-on lab: Windows Azure Marketplace for Applications

Vittorio Bertocci - MSFT — Tue, 09 Aug 2011 07:51:12 GMT

For the series “things I was working on before moving from DPE to the product team”. Today Wade’s gang released an update to the Windows Azure Platform Training Kit containing a new lab, “Introduction to the Windows Azure Marketplace for Applications”. Here there’s a bit of brain dump (not too long, it’s already past midnight here) of what were the thoughts in designing the lab: I see that the guys did some changes here and there, but the structure appears to be the same.

You may have seen last month the announcement that Windows Azure opened up a marketplace for applications: the aforementioned lab walks you though the process of adapting one existing SaaS application to take advantage of the marketplace for handling subscriptions & subscription lifecycle.

The main idea behind the lab was to show how an existing subscription management solution- such as a redeemable code handed out by your salesperson for every new deal - could be handled in a much more natural way by integrating with the Windows Azure marketplace.
Another reason for starting from an existing working solution was to make extra-clear where the marketplace responsibilities end and yours begin: for example the user registration (via ACS, of course) are entirely up to you. I would have liked to add a feature for handling multiple users (in order to be extra certain that nobody confuses “user” with “tenant”, you won’t believe how many times that happens) but there was no time. In any case, I am satisfied with the amount of identity topics we got in there

I won’t spoil (all) the surprise to you, but integrating your app in the marketplace largely consists in adding to your app an endpoint that the marketplace can call to notify you of a new subscription, a deprovisioning of an existing subscriptions, and the various details you need to act upon that info (for example which subscription level the customer paid for). Those calls are secured by…. surprise surprise… OAuth2. In fact, the lab takes advantage of WIF’s OAuth2 extensions.

The Windows Azure marketplace has various developer-friendly features, such as a “playground” from where you can send test subscription and deprovisioning messages; the lab walks you thru their user in detail. The lab also demonstrates how to go through the publication process, necessary to get one entry for your app in the application catalog.

Of course another important goal of the lab was to help you wrap your head about how to handle multitenancy (by managing the subscriptions info accordingly) and think a bit about what a real system may need to cope with (for example avoiding to delete all tenant data upon preprovisioning messages, or handle idempotency in case the same message needs to be re-sent). You tell me, but I think that the lab covers that pretty nicely.

Extra goodness? The lab setup uses the ACS cmdlets.

What is there to add? Congratulations to Wade, Donovan & he rest o the gang for the new release, and I wish you best of luck for your Windows Azure apps in the Marketplace!

A Digression on ACS and Rules

Vittorio Bertocci - MSFT — Tue, 26 Jul 2011 06:12:00 GMT

As you know, ACS offers a simple-yet-powerful rule engine which you can use for processing incoming claims and keep out of your application a considerable chunk of logic: claims set normalization, occasional policy decision point, and so on. The primitive there is the claim mapping rule: if an incoming claim matches the premise of a rule then the conclusion (in form of output claim) is added to the token that ACS will issue. Classic modus ponens, for the first-order logic aficionados among you. In inference rule notation:

Simply put, that means that I can codify logic such as “if you see a claim coming from Google, of type ‘email’ and with value ‘johndoenet64@gmail.com’ please add to the output token a claim of type ‘role’ and value ‘hairdresser’”. There are variations, for example I can omit claim type and/or value if I want my rule to be triggered for a wider range of inputs (i.e. I might want a rule which gets triggered every time I get something from Google, regardless of which claims are provided: the system rule adding identity provider info is a good example of that), but that’s pretty much it.

One interesting fact you may not be aware of is that ACS rules can be chained: that is, you can create rules which will be triggered by the output of other rules. All you need to do is create a rule whose input claim has ACS itself as issuer.

For example: you could create a rule which assigns to all the users in the role “hairdresser” to the role “cashier” and “authorized shipment slips signer”, two roles associated to the hairdresser position.

The advantages of the chained approach to the “enumeration” one is obvious. If both John and Pamela are hairdressers, with the chaining I need just 4 rules (two for assigning the hairdresser role to the users, two for adding the extra roles to the hairdresser role (which starts looking more like a group)) versus the 6 I’d need without chaining (three rules with email premise and role conclusion per user). That’s N+2 vs 3N… they diverge pretty quickly
Apart from the sheer number of rules, there’s also the manageability of the system. Onboarding Pamela as hairdresser, or changing her position later on, entails just adding (or changing) one single rule. If the hairdresser responsibilities change over time, all you need to do is changing the rules that have role-hairdresser as premise. Neat-o.

The above is a schema of how the usual rules work. A is the set of all possible claim types/values from the A issuer, O is the set of the claims issued by ACS (B is there just for showing that there can be multiple IPs). The blue arrow from A to O represent rules of the first type, the blue arrow that loops from O to O represents the chained rules. Let’s abuse this notation a bit and give a representation of the two rule styles above.

In the version without chaining, we have 6 rules (all of the form {A,O} predicate) which assign to John and Pamela to the 3 roles.

In the version with chaining, we have two rules of the form {A,O} and two of the form {O,O}. Welcome to the exciting world of predicates.
See what we have done here? The blue rule assigned Joe and Pamela to the set of the hairdressers; the red and green rules got chained and indirectly assigned Joe and Pamela to the set of the signers and the set of the cashiers, too.

The case above is a fairly unfortunate case, as the defining property we are using for determining that a user belongs to a given set (hairdressers) is unique to every element (every user has a different email address) hence in order to define our first set we need to add as many rule as there are users.
If our users would come from an identity provider that supplies more structured info, such as the directory for a cosmetology school, we could be in a better shape. For example students may be subdivided in groups according to the specialties they elected: hair stylist, skin care, nail technology and so on. Why did I pick up this sample again? Now I have to play along, tho
Anyway, let’s say that those students all go to work in a salon during the summer break, and that salon uses an application secured via ACS. At this point the rule could be “if you see a claim coming from the cosmetology school AD, of type ‘group’ and with value ‘hair stylist’ please add to the output token a claim of type ‘role’ and value ‘hairdresser’”. That rule would instantly cover all the students satisfying the criteria, as opposed to just one as before. You can even extend those sets by boolean union, for example adding a rule which establishes that the Barbering students are also in the Hairdresser role.
The chaining technique would have the same value, refining the properties of one set instead of having to recreate it; but never really doing anything for altering the number of elements affected.

Now what if, instead of the union of sets, we’d want to target the intersection? This is a very, very common requirement. For example, let’s say that the salon will employ only hair stylist students who are at the last year of the course. With the current {A, O} and {O, O} set of predicates, the answer is simple: you can’t. Or better, you can if you “cheat”. You can go by enumeration: if you know in advance that Rudy is a last year student in the hair stylist track, you can provision him by email and do the same with everybody else. That is not always possible, of course, and it’s not very efficient or manageable.
The other possibility is to rely on the directory administration of the school, and ask him/her to create a group “employed at salon A” that can can be used by ACS for assigning the hairdresser role to the correct group. There will be occasions in which you’ll be able to do it, but most often than not you should take as little dependency from the incoming source as possible (no guarantees they are willing to help, or will reliably and timely do so).

As mentioned here, from today ACS offers a new type of rule which allows you to identify the intersection of two sets. By allowing you to define two input claim conditions in logical AND from the same IP, that is to say a predicate of the form {A&A,O} you can effectively express that
“if you see a claim coming from the cosmetology school AD, of type ‘group’ and with value ‘hair stylist’ AND
you see a claim coming from the cosmetology school AD, of type ‘group’ and with value ‘last year student’
please add to the output token a claim of type ‘role’ and value ‘hairdresser’”.

In other “words”, our diagram earns an extra predicate with different arity:

..and adding a bit of notation abuse, we can see how this new predicate effectively gives you the power of identifying intersections:

Now, you may raise the fact that some conditions may require intersection with more than two sets. That’s fair. The good news is that you can add extra conditions, by feeding the result of one rule as one of the two inputs of another. In other words, you can write rules of the form {A&O, O} (of course the order of A and O in the premise does not matter, as AND is commutative). So if you want one of the students you employ to be allowed to operate a cashier machine only if older than 21, you can cascade the former cashier rule by modifying it as follows:

basically that means we added a predicate of the form shown in red:

Here you can see one case in which no student is actually allowed to operate the cashier:

There is one guy in the “adults” group, but that group has empty intersection with the hairdresser role (which was itself the intersection of the hair stylists and the last year students groups). You can iterate as many times you want, and you can even do intersections entirely in the O domain (with predicates of the form {O&O, O}).

Well, it’s the 3rd blog post I write this weekend, and it’s technically Monday morning now the time is up, I better get some sleep.
The hair salon scenario is perhaps not the most common SaaS application you’ll find around, but I hope this was useful for you to think about how to use ACS rules. If you have feedback on how ACS rules, don’t be shy!

Using the Windows Azure Access Control Service in iOS Applications

Vittorio Bertocci - MSFT — Mon, 25 Jul 2011 17:02:00 GMT

Nossir, there is nothing wrong with my blog the screenshot above is indeed taken from a Mac desktop, and the one you see on the center is actually an instance of the iPhone emulator. What you should notice, however, is the list of Identity Providers it shows, so strangely similar to what we have shown on Windows Phone 7 and ACS… but I better start from the beginning.

A couple of months ago the Windows Azure Platform Evangelism team, in which I worked until recently, released a toolkit for taking advantage of the Windows Azure platform services from Windows Phone 7 applications. The toolkit featured various integration points with ACS, as explained at length here.
At about the same time, the team (and Wade specifically) released a version of the same toolkit tailored to iOS developers. That first iOS version integrated with the core Windows Azure services, but didn’t take advantage of ACS.
Well, today we are releasing a new version of the Windows Azure toolkit for iOS featuring ACS integration!

Dear iOS friends landing on this blog for the first time: of course I understand you many not be familiar with the Windows Azure Control Service. You can get a quick introduction here, however for the purpose of providing context for this post let me just say the following: ACS is a fully cloud-hosted service which helps you to add to your application sign-in capabilities from many user sources such as Windows Live ID, Facebook, Google, Yahoo, arbitrary OpenID providers, local Active Directory instances, and many more. Best of all, it allows you to do so without having to learn each and every API or SDK; the integration code is the same for everybody, and extremely straightforward. All communications are done via open protocols, hence you can easily take advantage of the service from any platform, as this very post demonstrates. Try it!

I am no longer on the Evangelism team, but the ACS work for this deliverable largely took place while I was still on it: recording the screencast and writing this blog post provides nice closure. Thanks to Wade for having patiently prepped & provided a Mac already perfectly configured for the recording! Also, for driving the entire project, IMO one of the coolest things we’ve done with ACS so far.

And now, for something completely different:

The Release

As usual, you’ll find everything in DPE’s GitHub repository: https://github.com/microsoft-dpe
There will be four main entries you’ll want to pay attention to:

watoolkitios-lib

This is a library of Objective-C snippets which can help you to perform a number of common tasks when using WIndows Azure. For the specific ACS case, you’ll find code for listing identity providers, acquire and handle tokens, invoke the ACS management APIs, and so on.
watoolkitios-doc

As expected, some documentation
watoolkitios-samples

A sample application which demonstrates how to put the various snippets together
cloudreadypackages

Those are a set of ready-to-go packages that can be directly uploaded and launched in Windows Azure, without requiring you to have access to Visual Studio or the Windows Azure SDK: all you need is to deploy them via the portal (which works on Mac, too). The packages can be used as test backend for your iOS applications.
The packages take advantage of the technique described here to allow changes in the config settings even after deploy time. Which is a great segue for…
The ACS config tool for IOs

In the Windows Azure Toolkit for Windows Phone 7 we included some Visual Studio templates which contain all the necessary logic for wiring up a phone application to ACS and configure ACS to issue tokens for that app. In iOS/xCode there’s no direct equivalent of those templates, but we still wanted to shield the developer from many of the low level details of using Windows Azure. To that end, we created a tool which can automatically configure the application, ACS and Windows Azure.

Using the ACS Configuration Tool for iOS in the Toolkit

If you want to see the tool in action, check out the webcast; here I will give you few glimpses, just to whet your appetite.

This is a classic wizard, and it opens with a classic welcome page. We don’t like surprises, hence we announce what the tool is going to do let’s click next.

The first screen gathers info about the Windows Azure storage account you want to use; nothing to do with ACS yet. Next.

The next screen gathers the certificate used for doing SSL with the cloud package. Again, no ACS yet. Next.

Ahh, NOW we are talking business. Just like in the toolkit for Windows Phone 7 we offered the possibility of using the membership provider or ACS, here we do the same: depending on which option you pick, the way in which the user will be prompted for credentials and how calls will be secured will differ accordingly. Here we go the ACS way, or course

I would say this is the key screen in the entire process. Here we prompt the developer to provide the ACS namespace theyw ant to use with their iOS application, and the management key we need to modify the namespace settings accordingly. If you are unsure about how to obtain those values, a helpful link points to a document which will briefly explain how to navigate the ACS portal to get those.

In this wizard we try to strike a balance between showing you the power of the services we use and keeping the experience simple. As we did for the WP7 toolkit, here we apply some defaults (Google, yahoo and live id as identity providers, pass-through rules for all) that will show how ACS works without offering too many knobs and levers to operate. If you are unhappy with the defaults, you can always go directly to the portal and modify the settings accordingly. For example you may add a Facebook app as identity provider, and that will show up automatically in the phone application without any changes to the code.

The final screen of the wizard informs you that it has enough info to start the automatic configuration process. First it will generate a ServiceConfiguration.cscfg file, which you’ll use for configuring the Windows Azure backend (your cloudready package) via the portal. Then the wizard will reach out directly to the ACS management endpoint, and will add all the settings as specified.

As soon as you hit Save the wizard will ask you for amlocation for the cscfg file, then it will contact ACS and show you a bar as it progresses thru the configuration. Pretty neat!

Above you can see the generated ServiceConfiguration.cscfg. Of course the entire point of generating the file is so that you don’t have to worry about the details, but if you are curious you can poke around. You’ll mainly find the connection strings for the Windows Azure storage and the settings for driving the interaction with ACS.

All you need to do is to navigate (via the Windows Azure management portal) to the hosted service you are using for your backend, hit Configure and paste in the autogenerated ServiceConfiguration.cscfg.

The next step in the screencast shows how to run the sample application, already properly configured, in Xcode. If you hit the play button, you’ll be greeted by the screen which which I opened the post.

The rest is business as usual: the application follows the same pattern as the ACS phone sample and labs: an initial selection driven by browser based sign in protocols to obtain and cache the token from ACS (a SWT) and subsequent web service calls secured via OAuth. Below a Windows Live ID prompt, followed by the first screen of the app upon successful authentication.

Well, that’s it folks! I know that Wade and the gang will keep an eye on the GitHub repository: play with the code, let them know what you like and what you don’t like, branch the code and add the improvements you want, go crazy!

New in ACS: Portal in Multiple Languages, a New Rule Type… and Wave Bye-Bye to Quotas

Vittorio Bertocci - MSFT — Mon, 25 Jul 2011 16:00:00 GMT

Big news in ACSland today! There few new key features that - I am sure – many of you will welcome with a big smile.
As usual, for the full scoop take a look at the announcement and the release notes; here I’ll just give you few highlights & customarily lighthearted commentary.

The Portal Comes in 11 Languages

Riding the wave of the general localization effort sweeping the Windows Azure portal, the ACS portal can now entertain users in 10 extra languages, such as Japanese, Chinese (simplified and traditional), Korean, Russian, Portuguese, Spanish, German, French and even Italian .

Switching it is pretty trivial, to the point that I am daring to switch to Chinese without (too much) fear of not being able to revert to English . Just pick the language you want in the dropdown on the top right corner, and the UI will switch immediately. Also note the URL (in my case it moved to https://windows.azure.com/Default.aspx?lang=zh-Hans).

From that moment on, everything will be localized accordingly: for example if I invoke the management portal for one namespace, I get the HRD page localized accordingly:

And of course, the portal itself is now fully localized:

Note that I can override the language settings directly from the ACS portal, as highlighted in the image above.
Biographic note: I always have a lot of fun checking out the Italian versions of the software I use. The reason is that everybody have a different threshold about what should be translated and what should remain in their original formulation (why translating IP to “provider di identita’” but leaving RP as “relying party”? (or even why keeping “provider” but translating “identity”?)), and for expats like myself that threshold is often 0 (as in “do not translate at all”). Mismatches in expectations lead to those "benign violations” that McGraw claims constituting the basis of humor but I digress: ignore my pet peeves, I am sure that having the portal available in multiple languages will be of enormous help for making ACS even easier to use. Good job guys!

Quotas Are No More

Ah, this one is as simple as it will be appreciated, I have not the slightest doubt about it.
Some of you occasionally stumbled on quotas: deliberate restrictions which capped the maximum number of entities (rules, trusted IPs, RPs, etc etc) that could be created within a given namespace. Well, rejoice: those restrictions are now all gone. Have fun!

Rules Accept Up To 2 Input Claims

Here I risk throwing myself in a somewhat lengthy explanation, which I know many of my colleagues will deem unnecessary (as in “why does he always take hours to get to the point?!”). In order to preempt their complaints, here there are the sheer facts about the new rules:

From this release on, you have the option of specifying up to two claims as input for claims transformation rules. If claims triggering both input conditions are present (logical AND), then the rule will trigger. The input claims must both be from the same identity provider, as there is no flow that would allow ACS to gather claims from multiple sources at once; alternatively, they can mix one identity provider and ACS itself.

That’s all very straightforward. When you create your rule, specify your input claim conditions as usual; you’ll have the chance of adding a second input claim, by clicking on “Add a second input claim” as shown above.

That opens up a new area in the UI, where you can specify the details of the second input claim. It’s that easy! Note that only newly created rules will allow a second input claim, and that rules created via the Generate command won’t have the second input claim either.

One application of this new rule type is pretty obvious: you can express logic which depends from more than one factor (two, in fact) in the input token. As in “you get to be in the ‘Gold’ role only if you are in the group ‘Managers’ AND in the group ‘Partners’”, which was impossible to express before introducing the new rule type. Unless you enlist in the process the administrator of the IP and you convince them to add the rule in THEIR system directly at the origin, but that would be cheating.

Another application is slightly less obvious: it is the chance of composing the current input with decisions taken in former iterations. I know, that’s not especially clear that’s why I am throwing myself in the lengthy explanation in this other post, which is totally optional.

That’s it folks! Once again, don’t rely on this unreliable blog and read for yourself about the news in the announcement and the release notes. I am sure you’ll surprise us with real creative uses of those new features now at your disposal!

Updated Windows Azure Access Control Service Cmdlets: Modules, Continuation and Backup/Restore!

Vittorio Bertocci - MSFT — Tue, 12 Jul 2011 08:00:35 GMT

As promised yesterday, here there’s one of the deliverables I mentioned. About one month ago we published the first release of a set of PowerShell cmdlets for ACS: wrappers for the ACS management APIs, which allow you to easily script tasks such as wiping a namespace, adding an OpenID provider, automating often-used provisioning flows and much more.
The cmdlets were sample quality, but that didn’t prevent you from jumping on it with enthusiasm and give us a lot of great feedback: I credit especially the hosts and the audience of the Powerscripting podcast, who were so kind to have me on one episode and provide passionate commentary on what we had to improve.

Well, I am happy to announce that many of the requested improvements are here! If you head to http://wappowershell.codeplex.com/, you’ll find a new drop of the ACS cmdlets waiting for you. It’s the file ACSCmdlets20110711.exe, for good measure I took down the old one.

Make no mistake: this is still sample quality, but we added some features which will make those even more useful. Here there’s a list:

Snap-ins are out of fashion? Try our Modules

Hal and Jonathan had no doubt: our choice of delivering the cmdlets via snap-in was anachronistic, and we absolutely had to move things in a module.
We decided to offer that as an option at install time: now when you unpack the sample you will be prompted to choose if you want to use a module or a snap-in, perhaps if you are running an older version of PowerShell.

No more “plurals”

Another thing the Powerscripting crew was adamant about was the presence of one “singular” and one “plural” commands for every entity (ie Get-Rule and Get-Rules). As it turns out, the common practice in PowerShell is to have just the “singular” version and cleverly use the parameters (or lack thereof) to let PowerShell figure out the multiplicity of the result. That’s exactly what we’ve done! In our case, it’s the presence of the –Name parameter which determines if we are interested in one specific entity or a collection. The snippet below, helpfully provided by Lito from our friends at Southworks, hopefully gets the point across:

# retrieve the full list of Identity Providers

> Get-IdentityProvider –Namespace $yourNamespace –ManagementKey $yourManagementKey

# retrieve a single Identity Provider

> Get-IdentityProvider –Namespace $yourNamespace –ManagementKey $yourManagementKey –Name “Windows Live ID”

Your list exceeds the 100 entries? Try our new Get API

The feedback for this feature came from a colleague, who was very happy of the cmdlets until he discovered that he never managed to get result sets with more than 100 elements (he had the need to get MANY MORE). The ACS management API indeed cap their result to 100 elements, but as good OData citizens they also support continuation tokens. In the first release we didn’t handle those hence you were limited to what you get in the first shot to the API. This release does handle continuation tokens. It does so transparently, without surfacing the continuation token itself and forcing you to make multiple calls: we retrieve all the results for you, and if you want to break things down you can use the tools that PowerShell offers (like the classic | more).

# retrieve the full list of rules from a RuleGroup

> Get-Rule -GroupName $ruleGroup -Namespace $namespace -ManagementKey $managementKey | more

Add-, Get- and Remove- cmdlets for SeviceIdentities and ServiceIdentityKeys

You asked to be able to handle ServiceIdentity and associated keys: we obliged. Just make sure that you don’t fall in the fallacy of misusing them to use ACS as an identity provider, instead of unleashing its true federation provider potential.

> Add-ServiceIdentity -ServiceIdentity <ServiceIdentity>

> Add-ServiceIdentity –Name <String> –Description <string>

> Get-ServiceIdentity [-Name <string>]

> Remove-ServiceIdentity -Name <string>

> Add-ServiceIdentityKey -ServiceIdentityKey <ServiceIdentityKey> -ServiceIdentityName <String>

> Add-ServiceIdentityKey -Key <String> [-EffectiveDate <DateTime>] [-ExpirationDate <DateTime>] -ServiceIdentityName <String> [-Name <String>]

> Add-ServiceIdentityKey -Password <String> [-EffectiveDate <DateTime>] [-ExpirationDate <DateTime>] -ServiceIdentityName <String> [-Name <String>]

> Add-ServiceIdentityKey -Certificate <X509Certificate2> -ServiceIdentityName <String> [-Name <String>]

> Get-ServiceIdentityKey [-Id <Int64>] [-ServiceIdentityName <String>]

> Remove-ServiceIdentityKey -Id <Int64>

Add- cmdlets now can take an entire object as a parameter

We are getting closer to the entrée of this release, and the update discussed here is what makes it at all possible.

In the former release every Add- cmdlets took the attributes constituting the entity to be created as individual parameters. That worked, especially thanks to the fact that we picked meaningful defaults should the cmdlet be called with some omitted parameter. However it made especially hard to concatenate Add- with other commands, like a Get-, without adding complicated parsing logic that would break down the object coming from Get- in the individual parameters that Add- required. Well, get this: now all the Add- cmdlets accept also entire objects as parameters, making possible some interesting tricks like the one below:

# retrieve an Identity Provider from one namespace and add it to another one

> $RP = Get-RelyingParty -Name “Name Here” -MgmtToken $sourceNamespaceToken

> Add-RelyingParty -RelyingParty $RP -MgmtToken $targetNamespaceToken

You see where I am getting at here, right?

Backup and restore an ACS namespace

Enabling backup and restore was one of the main reasons for which we thought of creating a PowerShell cmdlets sample in the first place: with this release we are finally able to demonstrate that in a reasonably short and easy to read script.

In the cmdlets installation folder, sub-folder sampleScript/, you’ll find a series of sample scripts which can be used for save, restore or even transfer an entire namespace at once. Let’s play! Open a PowerShell prompt and navigate to the sampleScript folder. Pick an ACS namespace you like, retrieve the management key and enter something to the effect of

.\ExportNamespace.ps1 "myNamespace" "8m+1[.key.]mUE=" "c:\temp\myNamespace.acsns"

You’ll get the following output:

Importing AcsManagement Module...
Getting all the Identity Providers from myNamespace namespace...
Getting all the Relying Parties from myNamespace namespace...
Getting all the Rule Groups from myNamespace namespace...
Getting all the Service Keys from myNamespace namespace...
Getting all the Service Identities from myNamespace namespace...
Serializing all the information in myNamespace namespace to the c:\temp\myNamespace.acsns file...

Done

Looks pretty simple! Let’s see what have we got in myNamespace.acsns. The namespace I used is pretty rich, resulting in a 32K file, hence dumping it here would not make a lot of sense. However take a look of the screenshot of the file as shown by XML Notepad:

Yessirs, that is an XML representation of your namespace! The script that generated this file is surprisingly simple and readable:

Param($sourceNamespace = "[your namespace]",
$sourceManagementKey = "[your namespace management key]",
[string]$fileToExport = "[path to output file]")

function Get-ScriptDirectory
{
$Invocation = (Get-Variable MyInvocation -Scope 1).Value
Split-Path $Invocation.MyCommand.Path
}

$scriptDirectory = Get-ScriptDirectory
Set-Location $scriptDirectory

.\AddSnapInAndModule.ps1

$sourceToken = Get-AcsManagementToken -Namespace $sourceNamespace -ManagementKey $sourceManagementKey
$acsNamespaceInfo = New-Object Microsoft.Samples.DPE.ACS.ServiceManagementTools.PowerShell.Model.ServiceNamespace

"Getting all the Identity Providers from $sourceNamespace namespace..."
$acsNamespaceInfo.IdentityProviders = Get-IdentityProvider -MgmtToken $sourceToken

"Getting all the Relying Parties from $sourceNamespace namespace..."
$acsNamespaceInfo.RelyingParties = @()
foreach ($s in Get-RelyingParty -MgmtToken $sourceToken)
{
$acsNamespaceInfo.RelyingParties += @(Get-RelyingParty -MgmtToken $sourceToken -Name $s.Name)
}

"Getting all the Rule Groups from $sourceNamespace namespace..."
$acsNamespaceInfo.RuleGroups = @()
foreach ($s in Get-RuleGroup -MgmtToken $sourceToken)
{
$acsNamespaceInfo.RuleGroups += @(Get-RuleGroup -MgmtToken $sourceToken -Name $s.Name)
}

"Getting all the Service Keys from $sourceNamespace namespace..."
$acsNamespaceInfo.ServiceKeys = Get-ServiceKey -MgmtToken $sourceToken

"Getting all the Service Identities from $sourceNamespace namespace..."
$acsNamespaceInfo.ServiceIdentities = Get-ServiceIdentity -MgmtToken $sourceToken

"Serializing all the information in $sourceNamespace namespace to the $fileToExport file..."
if (! [System.IO.Path]::IsPathRooted("$fileToExport"))
{
$fileToExport = Join-Path "$scriptDirectory" "$fileToExport"
}
$acsNamespaceInfo.Serialize($fileToExport)

""
"Done"

In fact, there is nothing difficult about the above script: it’s more or less the same foreach applied in turn to IPs, RPs, rule groups & rules, service identities and keys.
Now that you have all your namespace in file you can restore it in its entirety via ImportNamespace.ps1. In fact, nothing prevents you from applying those settings even to a different ACS namespace! The CloneNamespace.ps1 demonstrates exactly that scenario.

Well, that’s it! Play with the cmdlets and let us know what you like, what you dislike and what you’d like to see: I’ll make sure to pass the feedback appropriately. As you know by now, I moved to the product team I won’t be driving the next release of the ACS cmdlets; in fact, without the kind help of Wade who took care of some last minute logistic details even this release would not have been in your hands now: thanks Wade!

And since we are on the thanks section, I wanted to take this chance to express my gratitude to the good folks at Southworks, with whom I worked very closely for the last few years, and to whom I owe my current caramel addiction (dulche de leche, to be precise). From the first identity training kits to the monumental work in FabrikamShipping SaaS, going through the identity labs in the windows azure platform training kit, keynote demos and occasional projects, the partnership with Tim, Matias, Lito, Johnny, PC, Iaco (signor Iacomuzzi!), Ariel, Nahuel, Diego, Fernando, Mariano, Nicholas, the “other Matias” and many others (sorry guys for not remembering all the names!) has been invaluable. You are probably not going to miss my OCS-grade nitpicking and inflexible quasi-religious ideas about how claims based identity should be messaged, but I will miss your professionalism, flexibility, exceptional work ethic, will to burn the midnight oil (remember that night in which the fire alarm rang in B18 (or was B24?) and when we came out we were practically the only ones in the place?) and especially all the common ground we built over the years. Best of luck you guys!

Ch-ch-ch-changes

Vittorio Bertocci - MSFT — Mon, 11 Jul 2011 06:55:52 GMT

[Dave, forgive me for lifting your headline it’s just too good a fit for the occasion]

As anticipated during a recent CloudCover episode, tomorrow it’s going to be my first day as Principal Program Manager in the identity product team. I’ll be looking after the developer experience for our identity products on premises and in the cloud. My office is being moved from Building 24 to the Redwest campus, I won’t have a place to put stuff down until Tuesday, and yet I am excited as a kid the day before school.

Claims based identity has been my passion for the last few years, or at least the one passion I have I could talk about in public: and talked about it I have, at literally hundreds of events big and small, in form of samples, hands-on labs, whitepapers, articles, videos, books; to customers, partners, students, colleagues, journalists and anybody who would care (or pretend) to listen. In the years in which I have been the identity evangelist, claims-based identity has gone from arcane code samples that few brave would would dare picking up to a fully mainstream technology, recognized by everybody and used by many, with the shift to the cloud providing even further acceleration. I am not taking any credit for it, mind you just stating some facts.

The point is that I believe we are now at the stage in which the claims-based identity meme is self-sustaining, we’ve been there for some time already. There is still the need to evangelize it, but in my opinion that is largely due to the fact that claims-based identity has not sank deep enough yet in the iso-osi stack or in our dev tools to be simply used without conscious effort. Joining the engineering team is my best chance to contribute to that transition. The identity team overflows with incredibly talented people, many of whom I already had the pleasure to work with through the years: joining them is an honor and a privilege I’ll work hard to deserve.

As much as I’m excited to jump on this new adventure, I cannot help but feel a sting of sadness in leading the Evangelism group. Through the 6 years I’ve been working there, I’ve received nothing but trust in me and my ideas, and empowerment to put them in practice. I have learned a ton and grew really a lot: who would have thought that I went from being incomprehensible to nearly everyone to get #2 spot among the PDC10 speakers, #6 at TechEd EU 10, deliver keynotes in fronts of thousands, and many other great personal satisfactions I would have never thought within my reach? If you would have told me back in 2005, when I moved to the US, I would have told you you are nuts
I am convinced this is largely thanks to my immediate team: I’ve been lucky to share meeting room and backstages with a long series of peers and leaders, many of whom I now call friends. Thank you guys, I have learned so much from all of you!

What does this change mean to you, my loyal reader? At least at first, not much. I was focused on identity, developers and the cloud, and that’s what I will be keep focusing on. I’ll keep showing up at events, albeit considerably less often (goodbye, Diamond status with Delta!).
There is a pipeline of deliverables I contributed to, which will progressively surface during the next few weeks as part of the output of the Windows Azure Evangelism Team: I’ll blog about it, as usual.
After that, you’ll likely no longer see posts on big samples (a’ la FabrikamShipping or Umbraco integration). Most of my energies will go directly in the product (tools, SDK samples, etc), hence that’s what I’ll talk about (when the time is right, of course). I will also come back to some of the more abstract posts I was used to write few years back, and I will ask much more often for your input!

In fact, I want to start RIGHT NOW. Here there’s a short survey on WIF and ACS, which I’ve been circulating with some MVPs and would like to open to everyone now. This is your chance to let us know what we need to improve: take advantage of it, while my enthusiasm for new challenges is at its peak!

Cloud Identity Summit: Come to Our Workshop!

Vittorio Bertocci - MSFT — Mon, 27 Jun 2011 08:24:34 GMT

Photo: Skinned Mink

In just about three weeks the who’s who of identity in the cloud is going to converge to Keystone, in the beautiful Rocky Mountains, to talk each other into identity-induced stupor. The Cloud Identity Summit, hosted by our friends at Ping Identity, is an event that I greatly enjoyed last year: and judging from the speakers lineup, this year holds great promises as well!

For the occasion, the egregious¹ Brian Puhl, the formidable Laura Hunter and (the …hairy?) yours truly will fight (for three full hours!) that mysterious force that seems to keep IT administrators and developers apart, and will share a stage to tell you about identity in Windows Azure and Office 365. Here there’s the abstract:

Tuesday, July 19, 2011 - 9am to 12pm

Identity in the Microsoft Cloud - Windows Azure, Office 365, and More!

In this unique workshop, come and hear about adopting and implementing the Microsoft Cloud from seasoned identity professionals who have been working with these technologies first-hand from Day One. We’ll begin with an overview and description of the technologies that allow an Identity Management professional to interact with both Windows Azure and Office 365. We’ll then walk through a real-life example of integrating Microsoft Cloud technologies from the perspective of both the application developer and the infrastructure architect. Along the way, we’ll share best practices and tales from the trenches from customers, partners, and Microsoft’s own Evangelists and internal Identity Management Architects.

Now, let me tell you for a moment about Brian and Laura’s work on this. Microsoft IT has been using ADFS2.0 not from Day One, but like from Day –360 Our Corp STS has been a critical service for our worldwide organization for a pretty long time, and is quite a spectacular deployment across geographies (for a snapshot from more than 1 year ago check out this video). Among other things, this was a fantastic enabler for us to take advantage of cloud services in our LoB applications at a spectacular pace: but this also meant really a lot of work for Brian’s team, who had to experiment with different policies/practices and really see what works. Brian and Laura are going to share some gems you won’t hear from anyone else.

About the developer’s portion of the workshop… well, I’ll refrain from chest-beating (at my shape/age, that would not be a good sight anyway). Let’s just say that I’ve been talking & writing about identity for developers for quite some time, and I hope you’ll find at least some insights in my logorrhea.

If the above was not enough to convince you to come, I don’t know what else to do… oh wait, I do!
For the first 15 people that will register using the code MSFT719%15, our workshop is free. Pretty neat trick.

Well, I registered and booked the flights & the hotel, I just have to rent the car at this point. If you want to partake to the intellectual feast of sharing a table with the likes of Gunnar Peterson, John Shewchuk, Bob Blakley, Eric Sachs, Andrew Nash and many others… you know what to do - see you there!

-----------------------
¹In Italian the term “egregio” means “excellent”. I am told that in English “egregious” can mean that as well, but the default meaning is less flattering. Of course I meant it in its “excellent” meaning

Powerscripting Podcast: ACS, Windows Azure and… PowerShell

Vittorio Bertocci - MSFT — Tue, 14 Jun 2011 06:27:33 GMT

Last week I had the pleasure of being guest on the PowerScripting podcast, THE show about PowerShell. That’s actually pretty uncharacteristic for me, considering that at every session I deliver at TechEd I spend the first few minutes on colorful disclaimers about the session being for developers, as opposed to IT administrator… however both the hosts (Hal & Jonathan) and the guys in chat were simply awesome and made me feel perfectly at home!

You can find the recording here. What did we chat about? Well, when I finally managed to stop speaking about myself we went through Windows Azure & PaaS, the idea of claims based identity, WIF & ACS, and finally on the Windows Azure and ACS cmdlets we released on Codeplex. I got a lot of encouragement, you guys seem to like those really a lot, and I also got a ton of useful feedback (“plurals? really? Snapins instead of modules? REALLY?” - Guys, what do I know, I am a dev ) that we are already working into the planning.

If you are an IT administrator, I would be super grateful if you could take a quick look at a simple 4-questions survey: that will be of immense help for prioritizing our next wave of releases, and will give you the chance to be heard

Thanks Hal & Jonathan for having me on your great show!

Edit and Apply New WIF’s Config Settings in Your Windows Azure WebRole… Without Redeploying!

Vittorio Bertocci - MSFT — Tue, 31 May 2011 08:30:35 GMT

In short: in this post I will show you how you can leverage the OnStart event of a WebRole to enable changing the WIF config settings even after deployment.

Since the very first time Hervey and I made the first foray in Windows Azure with WIF, all the way to the latest hands-on labs, books and whitepapers, one of the main challenges of using WIF in a WebRole has always been the impossibility of updating the settings in <microsoft.identityModel> without redeploying (or preparing in advance for a pool of alternative <service> elements fully known at deployment time).

Last Friday I was chatting with Wade about how to solve this very problem for some future deliverables in the toolkit, and it just came to me: why don’t we just leverage the WebRole lifecycle and use OnStart for setting the values we want even before WIF reads the web.config? All we need to do is create suitable <setting> entries in the ServiceConfiguration.cfg file, which can be modified without the need to redeploy, and use the events in WebRole.cs to ensure that our apps picks up the new values. Simple!

I created a new WebRole, hooked it to a local SelfSTS, and started playing with ServiceDefinition.csdef, ServiceConfiguration.cscfg and WebRole.cs. I just wanted to make sure the idea works, hence I didn’t pour much care in writing clean (or exhausting) code. Also, I totally ignored all the considerations about HTTPS, NLB session management and all those other things you learned you need to do in WIndows Azure. None of those really interferes with the approach, hence for the sake of simplicity I left them all out.

First, I created <Setting> entries in the .csdef for every WIF config parameter generated by the Add STS Reference you’d likely want to control:

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="WindowsAzureProject5" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="WebRole1">
    <Runtime executionContext="elevated" />
    
    <!--... stuff-->
    <ConfigurationSettings>
      <Setting name="audienceUri" />
      <Setting name="issuer" />
      <Setting name="realm" />
      <Setting name="trustedIssuersThumbprint" />
      <Setting name="trustedIssuerName" />
    </ConfigurationSettings>
  </WebRole>
</ServiceDefinition>

Yes, yes, having settings just for one issuer in the trusted issuers registry is not especially elegant; and adding a homeRealm would probably be useful. Some other time.
The important thing to notice here is the <Runtime executionContext=elevated” />. Without that, you won’t be able to save the modifications to the Web.Config.

Then I added the same settings in the .cscfg, leaving all the values empty (for now).

<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="WindowsAzureProject5" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="1" osVersion="*">
  <Role name="WebRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
      <Setting name="audienceUri" value="" />
      <Setting name="issuer" value="" />
      <Setting name="realm" value="" />
      <Setting name="trustedIssuersThumbprint" value="" />
      <Setting name="trustedIssuerName" value="" />
<!--...stuff-->
    </ConfigurationSettings>
    <!--...stuff-->
  </Role>
</ServiceConfiguration>

Very straightforward. Then I went ahead and added to WebRole.cs the code below:

namespace WebRole1
{
    public class WebRole : RoleEntryPoint
    {
        public override bool OnStart()
        {
            RoleEnvironment.Changing += RoleEnvironmentChanging;

                using (var server = new ServerManager())
                {
                    var siteNameFromServiceModel = "Web";
                    var siteName =
                        string.Format("{0}_{1}", RoleEnvironment.CurrentRoleInstance.Id, siteNameFromServiceModel);

                    string configFilePath = server.Sites[siteName].Applications[0].VirtualDirectories[0].PhysicalPath + "\\Web.config";
                    XElement element = XElement.Load(configFilePath);

                    string strSetting;

                    if (!(String.IsNullOrEmpty(strSetting = RoleEnvironment.GetConfigurationSettingValue("audienceUri"))))
                        element.Element("microsoft.identityModel").Element("service").Element("audienceUris").Element("add").Attribute("value").Value = strSetting;
                    if (!(String.IsNullOrEmpty(strSetting = RoleEnvironment.GetConfigurationSettingValue("issuer"))))
                        element.Element("microsoft.identityModel").Element("service").Element("federatedAuthentication").Element("wsFederation").Attribute("issuer").Value = strSetting;
                    if (!(String.IsNullOrEmpty(strSetting = RoleEnvironment.GetConfigurationSettingValue("realm"))))
                        element.Element("microsoft.identityModel").Element("service").Element("federatedAuthentication").Element("wsFederation").Attribute("realm").Value = strSetting;
                   
                    if (!(String.IsNullOrEmpty(strSetting = RoleEnvironment.GetConfigurationSettingValue("trustedIssuersThumbprint"))))
                        element.Element("microsoft.identityModel").Element("service").Element("issuerNameRegistry").Element("trustedIssuers").Element("add").Attribute("thumbprint").Value = strSetting;
                    if (!(String.IsNullOrEmpty(strSetting = RoleEnvironment.GetConfigurationSettingValue("trustedIssuerName"))))
                        element.Element("microsoft.identityModel").Element("service").Element("issuerNameRegistry").Element("trustedIssuers").Element("add").Attribute("name").Value = strSetting;

                    element.Save(configFilePath);
                }
           
                            
            return base.OnStart();
        }
        private void RoleEnvironmentChanging(object sender, RoleEnvironmentChangingEventArgs e)
        {
            e.Cancel = true;
        }
    }
}

Let’s look at what happens in the using block first. If you want to read good writeups on this technique I suggest this msdn entry or this really nice entry from Andy Cross.
When OnStart runs, the WebRole application itself didn’t have a chance to do anything yet. What I want to do here is getting my hands on the web.config file, override the WIF settings with all the non-empty values I find in ServiceConfiguration.cscfg and save back the file even before WIF gets to read <microsoft.identityModel>.
What I do above with Linq to XML for modifying the WIF settings is pretty dirty, very brittle and definitely tied to the assumption that the config we’ll be working with is the one that comes out from a typical Add STS Reference run. I tried to use ConfigurationManager at first, but it complained that <microsoft.identityModel> has no schema hence I just went the quicker, easier, more seductive “let’s just see if it works”. But remember, for the one among you who caught the reference: the dark side is not stronger. No no no.
Aaanyway. The element.Save(configFilePath) is the line that will fail if you forgot to add the elevated directive in the csdef, you’re warned.

The RoleEnvironmentChanging handler hookup at the beginning of OnStart, and the handler itself, are meant to ensure that when you change the values in ServiceConfiguration.cscfg Windows Azure will properly restart the role. If you don’t add that, just changing the config will not drive changes in the WebRole behavior until a stop & restart occurs. Technically there are few things you may try to do to get WIF to pick up the new settings at mid flight, but all those would entail changing the application code and that’s exactly what I am trying to avoid with all this brouhaha.
BTW, you can thank Nick Harris for the RoleEnvironment.Changing trick
Nick just joined the Windows Azure Evangelism team and he is already doing an awesome job.

That should be all. Now, try to ignore the impulse that would make you change the config before deploying, and publish the project in Windows Azure staging “as is”.

In few mins the instance is up and running, listening at a nice (and totally unpredictable) URL http://eddb883659d04d0bbbb570f17c52ea01.cloudapp.net. What do you think will happen if I just navigate there?

That’s right. WIF is still configured for the address the application had in the environment formerly known as devfabric (now Windows Azure simulation environment), as described in the realm entry, hence SelfSTS (which behaves like the WIF STS template if there’s no wreply in the signin message) sends the token back there instead of http://eddb883659d04d0bbbb570f17c52ea01.cloudapp.net. Normally we’d be pretty stuck at this point, but thanks to the modification we made we can fix the situation.

All you need to do is navigating to the Windows Azure portal, select the deployment and hit the Configure button.

Here you can pick the Edit current configuration option to update the values inline. In this case, all you need to do is pasting http://eddb883659d04d0bbbb570f17c52ea01.cloudapp.net in the audienceUri and realm settings, and hit OK.

You’ll see the portal updating the instance for few moments. As soon as it reports the role as ready, navigate to its URL and, surprise surprise, this time the authentication flow ends up in the right place! In the screenshot below you can see (thanks to the SecurityTokenVisualizerControl, which you can find in all the latest ACS labs in the identity training kit) that the audienceURI has been changed as well.

I think that’s pretty cool

Now, you may argue that this scenario is an artifact of how the WIF STS template handles things, and if you would have ben dealing with an STS (like ACS) which keeps realm and return URLs well separated you could have solved the matter at the STS side. All true, but beside the point.
Here I used the staging & realm example because with its unknowable-until-it’s-too-late GUID in the URL it is (was?) the paradigmatic example of what can be challenging when using WIF with Windows Azure; but of course you can use the technique you saw here for pushing out any post-deployment changes, including pointing the WebRole to a different STS, updating certificate thumbprints as keys rollover takes place or any other setting you may want to modify.

Please use this technique with caution. I haven’t used extensively yet hence I am not 100% sure if there are gotchas just waiting to be found, but so far it seems to be solving the problem pretty nicely

Storing Encrypted Tokens with the Windows Phone Developer Tools 7.1

Vittorio Bertocci - MSFT — Wed, 25 May 2011 23:01:00 GMT

If you went through the hands on lab for using ACS on your Windows Phone 7 application, you already know that saving the user the hassle to re-authenticate all the times entails a security tradeoff. Here there’s what I wrote in the lab’s instructions:

Saving a token on the phone’s storage is not very secure. The isolated storage may prevent other applications from stealing the persisted token, but it does not prevent somebody with physical access to the device to eventually get to it. Any form of encryption would not solve the issue if the decryption key resides on the phone, no matter how well it is hidden. You could require the user to enter a PIN at every application run, and use the PIN to decrypt the token, however the approach presents obvious usability and user acceptance challenges.

While we wait for a better solution to emerge, it may be of some consolation considering that saving token is much better than saving direct credentials such as a username/password pair. A token is typically scoped to be used just with a specific service, and it has an expiration time: this somewhat limits what an attacker can do with a token, whereas no such restrictions would be present should somebody acquire username and password.

Well, guess what: a better solution is emerging, and as of yesterday you can get a sneak peek of it with the Windows Phone Developer Tools 7.1

The solutions happens to be very simple, too: in a nutshell, it consists in making DPAPI available on the device.
In “Mango” you have access to ProtectedData, which you may recognize as the class that provides you access to DPAPI for encrypting and decrypting data via static methods Protect and Unprotect.
The ProtectedData class available on the device differs from the one in “big .NET” in the way in which it handles the scope.

In .NET you can choose to encrypt your data with the machine key or with the current user key. See MSDN.
On the device every application gets its own key, which is created on first use. Calls to Protect and Unprotect from the application code will implicitly use the application key, ensuring that all data remain private to the app itself: in fact, the scope parameter is not even present in the method’s signature. For what I understand, the key will survive subsequent application updates.

Back to the problem of saving tokens on the device: how do we modify the flow in the current samples in order to take advantage of this new feature?

Very straightforward. In step 12 of task 5 of the ACS+WP7 lab you hook up your app to a store façade, RequestSecurityTokenResponseStore, which is responsible for persisting in isolated storage the RSTR messages received from ACS (you can find it in SL.Phone.Federation/RequestSecurityTokenResponseStore). All you need to do is ensuring that you use Protect and Unprotect when putting stuff in and out of isolated storage.

Note: Why the entire RSTR instead of just the token? Mainly because we can extract the expiration from directly from there, whereas the token itself may be encrypted for the destination service hence opaque to the client. We use that info just as an optimization – we can save a roundtrip to the service if we already know that the token expired – but the service is still on point for validating incoming tokens hence errors on this are not too costly.

As we progressively refresh our ACS+WP7 content to take advantage of the new Mango features (with its occasional road bumps) we’ll incorporate those new features, but I wanted to make sure that you know ASAP how to mitigate the token-persistence-on-the-device problem. Don’t you feel better already?

“Mango” and the ACS+Phone Samples

Vittorio Bertocci - MSFT — Wed, 25 May 2011 20:33:15 GMT

Yesterday we released the Beta of the Windows Phone Developer Tools 7.1, with a boatload of new awesome features (I’ll write about one of those in the next post).

Beta versions are likely to have some known issues, and this one is no exception. In fact, there is a bug that you are likely to encounter if you go through the ACS+WP7 hands-on lab, the Windows Azure Toolkit for Windows Phone 7 (which still targets Windows Phone 7.0, see Wade’s post here) and the phone sample on the ACS site.
The WebBrowser control in the emulator periodically resets the scale and position of the page being rendered, making it challenging to enter your credentials on IP authentication pages that are not designed for mobile. It is still definitely possible, but you may need to do a bit of chasing of the username and password fields on the screen (or type without having the fields into view, using the page up combination for entering values in the emulator via the PC’s keyboard).

While we wait for a release of the tools in which the bug has been fixed, here there are a couple of workarounds you may want to consider if your Windows Phone app scenario requires ACS:

Use the mobile version of the IP authentication pages. Many providers offer mobile-friendly versions of their authentication pages, that will render well on the phone’s screen without requiring you to zoom in and pan through the page. In that case the bug will just make the page flicker a bit, but you’ll be able to enter your data without issues.
This entails taking control of the home realm discovery experience, as the default pages used by ACS for contacting the preconfigured IPs are not the mobile-ready versions. For ideas on how to do it I suggest taking a look at the code of the phone client generated by the template in the latest Windows Azure Toolkit for Windows Phone 7
Keep the Windows Phone Tools 7.0 on some of your machines. I am keeping a couple of my machines on 7.0: not only because of this specific issue, but also because AFAIK with 7.1 Beta you cannot publish apps to the marketplace and I need to be able to do so (if I’ll finally find the time to update my poor neglected Chinese & Japanese dictionary apps)

If neither of the above works for you, let me stress that entering your credentials is still perfectly possible: it just requires you a bit more effort. Those are the joys of prerelease software

Adding a Custom OpenID Provider to ACS… with JUST ONE LINE of PowerShell Code

Vittorio Bertocci - MSFT — Fri, 20 May 2011 05:49:37 GMT

ACS offers you a variety of identity provider you can integrate with. Many of you will be familiar with the list shown by the management portal at the beginning of the add new identity provider wizard.

Some of you may also know that ACS integrates with Yahoo! and Google using OpenID, however from your point of view that doesn’t matter much: the details are abstracted away by ACS.

A less-known factlet is that ACS also supports integration with other OpenId providers: however that capability is not exposed via portal, you can only set it up via management APIs. We do have a tutorial which shows you how to do that step by step using myOpenID, you can find it here.

It’s not hard, that’s just OData after all, but it is still 6 printed pages. Now, how would you feel if I’d tell you that if you use the ACS cmdlets you can do exactly the same in ONE line of PowerShell code? Mind == blown, right?

Here we go:

PS C:\Users\vittorio\Desktop> Add-IdentityProvider –Namespace “myacsnamespace” –ManagementKey “XXXXXXXX” -Type "Manual" -Name "myOpenID" -Protocol OpenId –SignInAddress “http://www.myopenid.com/server”

That’s it! With the –Manual switch I can explicitly create any IP type. In order to maintain my boast that one line of code is enough, I used the inlined syntax for passing the namespace and the management key directly. In the announcement post I first obtained a management token with Get-AcsManagementToken, assigned it to a variable and passed it along for all subsequent commands, which is more appropriate for longer scripts (hence from now on I’ll use it instead).

That did the equivalent of the tutorial: however, that’ not enough to use myOpenID with the application yet. We still need to create rules that will add some claims or ACS won’t even send a token back. Luckily, that’s just another line of PowerShell code:

PS C:\Users\vittorio\Desktop> Add-Rule -MgmtToken $mgmtToken -GroupName "Default Rule Group for myRP" -IdentityProviderName "myOpenID"

Here I didn’t specify any input or output claim, which substantially ends up in a pass-through rule. NOW we’re ready! Let’s see what happens if I hit F5 on a plain vanilla Windows Azure webrole project where I added the SecurityTokenDisplayControl (you can find the VS2010 version in the identity training kit labs about ACS).

Oh hello myOpenID option! I’s there, good sign. Let’s hit it.

As expected, we end up on the auth page of openID. Once successfully authenticated, we get to the consent page:

Note that the consent does not mention any attributes, this fact will become relevant in a moment. Let’s click continue and…

congratulations! You just added an arbitrary OpenID provider, and all it took was just 2 lines of PowerShell (without even touching your application or opening the ACS management portal).

Now, you may notice one thing about this transaction: we got an awfully low amount of information about the user, just the OpenID handle in fact. I am not very deep in OpenID, I’ll readily admit. Luckily Oren, Chao and Andrew from the ACS team came to the rescue (thank you guys) and explained that ACS gets claims in OpenID via Attribute Exchange, which myOpenID does not support (they use Simple Registration).

Bummer! I really wanted to show passing name and email. Luckily adding another OpenID provider which supports AX is just a matter of hitting the up arrow a couple of times in the PowerShell ISE and change the name and signin address accordingly. In the end I settled with http://hyves.net, since I was just recently in the Netherlands

Add-IdentityProvider -MgmtToken $mgmtToken -Type "Manual" -Name "hyves.net OpenID" -Protocol OpenId -SignInAddress https://openid.hyves-api.nl/

Add-Rule -MgmtToken $mgmtToken -GroupName "Default Rule Group for myRP" -IdentityProviderName "hyves.net OpenID"

Another F5…

…and the new option for hyves.net shows up. Good! Let’s hit it.

We get to their auth page. Let’s log in, we’ll get to the consent page.

Now this looks more promising. Hyves.net asks permission to share the email address with the ACS endpoint, as expected. Let’s grant it and see what happens.

Bingo! This time ACS (hence the RP) got the name and email claims, just like I wanted.

Soo, let me recap. I just enabled users from two arbitrary OpenID providers to authenticate with my application; and all it took was writing two commands in the window below to provision the first provider, then modifying those two commands for provisioning the second. We are talking minutes here, and just because I am not a very good typist nor an expert in PowerShell.

I know it’s bad form that I am the one saying it: but isn’t this really awesome? Come on, do something with the cmdlets too! I am super-curious to see what you guys will be able to accomplish

Announcing: Sample ACS Cmdlets for the Windows Azure AppFabric Access Control Service

Vittorio Bertocci - MSFT — Wed, 18 May 2011 06:06:45 GMT

Long story short: we are releasing on Codeplex a set of PowerShell cmdlets which wrap the management API of the Windows Azure AppFabric Access Control Service.

This is hopefully for the joy of our IT admin friends who want to add ACS to their arsenal, but I bet that this will make many developers happy as well. I’ve never really used PowerShell before, and I’m using those cmdlets like crazy since the very first internal drop!

You can use those new cmdlets to save repetitive provisioning processes in form of PowerShell scripts, and consistently reuse them just by passing as parameters the targeted namespace and corresponding management key. You can use them for backing up your namespace settings on file and restore them at a later time, or copy settings from one namespace to the other. You can easily integrate ACS management in your existing scripts, or even just use the cmdlets to perform quick queries and adjustments to your namespace directly from PowerShell ISE or the command line. In fact, you can do whatever you are used to do with PowerShell cmdlets .

The initial set we are releasing today is not 100% exhaustive, for example we don’t touch the service identities yet, but it already enables most of the scenarios we encountered. The command names are self-explanatory:

IPs

Add-IdentityProvider
Get-IdentityProvider
Get-IdentityProviders
Remove-IdentityProvider

RPs

Add-RelyingParty
Get-RelyingParties
Get-RelyingParty
Remove-RelyingParty

Rules

Add-DefaultPassThroughRules
Add-Rule
Get-Rule
Get-Rules
Remove-Rule

Rule Groups

Add-RuleGroup
Get-RuleGroup
Get-RuleGroups
Remove-RuleGroup

Crypto

Add-TokenEncryptionKey
Add-TokenSigningKey
Get-ServiceKey
Get-ServiceKeys
Remove-ServiceKey

Utils

Get-AcsManagementToken

There’s just 23 of them, and we might shrink them further in the future. For example: do we really need an Add-DefaultPassThroughRules cmdlet or can we just rely on Add-Rule? You tell us!
All cmdlets support get-help including the –Full option, although things are not too verbose at the moment: in subsequent releases we’ll tidy things up, but we wanted to put this in your hands ASAP.

Now for the usual disclaimer: Those cmdlets are distributed in source code form and are not part of the product. you should consider them a code sample, even if we provide you with a setup that will automatically compile and install them so that you can use them without ever opening the project in visual studio if you don’t want to. Of course we are happy to take your feedback, especially now that the package is still a bit rough on the edges, but you should always remember that those cmdlets are unsupported.
Other disclaimer: this release have been thoroughly tested only on Windows 7 x64 SP1, and quickly tested on Windows 7 x86 SP1 and Windows 2008 R2 x64 SP1. There are known problems on older platforms, which we’ll iron out moving forward. Think of this release as one preview.

That said, I am sure you’ll have a lot of fun using the cmdlets for exploring the features that ACS offers.

Some More Background, and One Example

If you want to manage your ACS namespaces, there’s no shortage of options: you can take advantage of the management portal (new in 2.0) or you can use the OData API exposed via management service.

In my team we make pretty heavy use of ACS, both for our internal tooling (for example managing content and events) and for the samples, demos and hands on lab we produce.
In order to enable the scenario we want to implement, at setup time all of those deliverables require us to go through fixed sets of configuration steps in ACS. For example, when you use the template in the Windows Azure Toolkit for Windows Phone 7 to generate an ACS-ready project, the initialization code needs to:

Add Google as an IP
Add Yahoo! as an IP
Remove any RP which may collide with the new one
Create the new RP
Get rid of all the rules which may already be in the rule group we are targeting
Generate all the pass-through rules for the various IPs

This is a relatively simple sequence of operations; other setups we have to do, like the enterprise subscription provisioning flow we follow when we handle a new FabrikamShipping subscriber, are WAY more complicated.
In order to automate those processes, we progressively populated a class library of C# wrappers for the ACS management APIs. Then we started including that library in the Setup folder of various projects, together with a console app which calls those wrappers in the sequence that the specific sample being set up dictates; for example, the sequence described above for the Windows Azure toolkit for Windows Phone 7.
In that specific case, the setup solution (it’s C:\WAZToolkitForWP7\Setup\acs\AcsSetup.sln if you have the toolkit and you are curious) is almost 580 lines of code.

Now, multiply that for all the projects we have (for the newest ones see this post) and the number starts to look significant. Add it to the frequent requests we get from customers to extend the cmdlets we created for Windows Azure to other services in the Windows Azure platform, and you’ll see why we decided to create a set of cmdlets for ACS.
Quite frankly, it was also because it was a low hanging fruit for us. We already had our wrapper library for the ACS management API, and we had the cmdlets wrapper solution we used for generating the Windows Azure cmdlets; putting the two together was pretty straightforward.

Once we had the right set of cmdlets we went ahead and re-created the sequence above in for of PowerShell script, and the improvement in respect to the AcsSetup.sln approach is impressive. Check it out:

# Coordinates of your namespace
$acsNamespace = "<yourNamespace>";
$mgmtKey = "<yourManagementKey>";

# Constants
$rpName = "WazMobileToolkit";
$groupName = "Default Rule Group for $rpName";
$signingSymmetricKey = "2RGYmQiFT9uslnxTTUn9MFr/nU+HeVwkmMJ6MwBNGuQ=";

$allowedIdentityProviders = @("Windows Live ID","Yahoo!", "Google”);

# Include ACS Management SnapIn
Add-PSSnapin ACSManagementToolsSnapIn;

# Get the ACS management token for securing all subsequent API calls
$mgmtToken = Get-AcsManagementToken -namespace $acsNamespace -managementKey $mgmtKey;

# Configure Preconfigured Identity Providers
Write-Output "Add PreConfigured Identity Providers (Google and Yahoo!)...";
$googleIp = Add-IdentityProvider -mgmtToken $mgmtToken -type "Preconfigured" –preconfiguredIPType "Google";
$yahooIp = Add-IdentityProvider -mgmtToken $mgmtToken -type "Preconfigured" –preconfiguredIPType "Yahoo!";

# Remove RP (if it already exists)
Write-Output "Remove Relying Party ($rpName) if exists...";
Remove-RelyingParty -mgmtToken $mgmtToken -name $rpName;

# Remove All Rules In Group (if they already exist)
Write-Output "Remove All Rules In Group ($groupName) if exists...";
Get-Rules -mgmtToken $mgmtToken -groupName $groupName | ForEach-Object { Remove-Rule -mgmtToken $mgmtToken -rule $_ };

# Create Relying Party
Write-Output "Create Relying Party ($rpName)...";
$rp = Add-RelyingParty -mgmtToken $mgmtToken -name $rpName -realm "uri:wazmobiletoolkittest" -tokenFormat "SWT" -allowedIdentityProviders $allowedIdentityProviders -ruleGroup $groupName -signingSymmetricKey $signingSymmetricKey;

# Generate default pass-through rules
Write-Output "Create Default Passthrough Rules for the configured IPs ($allowedIdentityProviders)...";
$rp.IdentityProviders | ForEach-Object { Add-DefaultPassthroughRules -mgmtToken $mgmtToken -groupName $groupName -identityProviderName $_.Name }

Write-Output "Done";

Excluding the comments (but counting the Write-Output) those are 20 lines of very understandable code, which you can modify in notepad (typically just for the namespace and namespace key) and run with a simple double-click; or, if you are fancy, you can open it up in PowerShell ISE and execute it line by line if you want to. Does it show that I am excited about this?

Let’s play a bit more. Let’s say that you now want to add Facebook as an identity provider. First you’ll need to add some config values at the beginning of the script:

$fbAppIPName = "Facebook IP";
$fbAppId = "XXXXXXXXXXXXX";
$fbAppSecret = "XXXXXXXXXXXXX";

We can even be fancy and subordinate the Facebook setup to the existance of non-empty facebook app coordinates in the script:

$facebookEnabled = (($fbAppId -ne "") -and ($fbAppSecret -ne ""));

Then we just add those few lines right where we create the preconfigured IPs:

# Configure Facebook App Identity Provider
if ($facebookEnabled)
{
    Write-Output "Add Facebook App Identity Provider ($fbAppIPName)...";

    # Remove FB App IP (if exists)
    Remove-IdentityProvider -mgmtToken $mgmtToken -name $fbAppIPName;

    # Add FB App IP
    $fbIp = Add-IdentityProvider -mgmtToken $mgmtToken -type "FacebookApp" -name $fbAppIPName -fbAppId $fbAppId -fbAppSecret $fbAppSecret;
}

Super straightforward; and the part that I love is that you can just test those commands one by one and see the results immediately, saving them in the script only when you are certain they do what you want them to do. For management tasks, it definitely beats fiddling with the debugger and the immediate window.

Want to play a bit more? Sure. One thing I often need to do is wiping a namespace clean after I did a demo during a session. Sometimes I have many sessions in a day, from time to time even back to back: as you can imagine, clicking around the portal for deleting entities is not fun nor very fast. But now I can just double click on the following script and I am done!

$acsNamespace = "holacsfederation";
$mgmtKey = "XXXXXXXXXXXXXXXXXXXX";
# Include ACS Management SnapIn
Add-PSSnapin ACSManagementToolsSnapIn;

$mgmtToken = Get-AcsManagementToken -namespace $acsNamespace -managementKey $mgmtKey;
Write-Output "Wiping IPs (and associated rules)";
Get-IdentityProviders -mgmtToken $mgmtToken | where {$_.SystemReserved -eq $false} | ForEach-Object { Remove-IdentityProvider -mgmtToken $mgmtToken -name $_.Name };
Write-Output "Wiping RPs (and associated rules)";
Get-RelyingParties -mgmtToken $mgmtToken | where {$_.SystemReserved -eq $false} | ForEach-Object { Remove-RelyingParty -mgmtToken $mgmtToken -name $_.Name };
Write-Output "Wiping Rule Groups";
Get-RuleGroups -mgmtToken $mgmtToken | where {$_.SystemReserved -eq $false} | ForEach-Object { Remove-RuleGroup -mgmtToken $mgmtToken -name $_.Name };

Here I delete all IPs (which will delete the associated rules), all RPs and all rule groups. All three commands have the same structure. Let’s pick the IP one:

Get-IdentityProviders -mgmtToken $mgmtToken
| where {$_.SystemReserved -eq $false}
| ForEach-Object { Remove-IdentityProvider -mgmtToken $mgmtToken -name $_.Name };

Get-IdentityProviders returns all IPs in the namespace; the where clause excludes the system reserved ones (Windows Live ID) which we’d be unable to delete anyway, then the ForEach-Object cycles through all the IPs and removes them. You’ve got to love PowerShell piping.

Well, this barely scratches the surface of what you can do with the ACS cmdlets. Please do check them out! We look forward for your feedback, and for once not just from developers!

At TechEd Atlanta? Come Over to the Federated Identity Booth!

Vittorio Bertocci - MSFT — Tue, 17 May 2011 16:34:15 GMT

Friendly faces everywhere / Humble folks without temptation .

More seriously, this is one of those rare occasions where you could meet with the guy who wrote (or spec’ed) the exact feature you are interested into… and they are all here for answering your questions. Don’t miss the opportunity!

Attention ASP.NET Developers: SAML-P Comes to WIF

Vittorio Bertocci - MSFT — Mon, 16 May 2011 14:21:52 GMT

If I’d have a dollar for every time a customer or partner asked me if they could use WIF for consuming the SAML2.0 protocol… ok, I would not exactly buy a villa a Portofino, but let’s just say that this is one of the most requested features since WIF came out.

Well, dear .NET developers, rejoice: you no longer need to envy your friend the ADFS2 administrator. From now on you are gifted the ability to use ASP.NET for writing SAML-P SP-Lite compliant relying parties, which in fact I should probably call service providers just to add some local color.

The WIF team just released,and here I quote verbatim, the CTP of the WIF Extensions for SAML 2.0 Protocol.

At its core, what makes those extensions tick is the Saml2AuthenticationModule, which looks very similar (i.e. raises ~the same events, etc.) to the WSFederationAuthenticationModule and is in fact inserted in the pipeline more or less in the same way. The module lives in the assembly Microsoft.IdentityModel.Protocols.dll, together with the (lots of) classes it needs to implement the details of the SAML protocol.

The programming model may be similar, as one would expect, but of course the extensions implement features that are paradigmatically SAMLP. Examples? POST, Redirect and Artifact bindings; SP initiated and (can you believe that?) IP initiated SSO and SLO (single log out).

The package contains various other goodies: a good set of cassini-based samples, documentation that will get you started and that will help you to use ADFS2 as IP instead of the sample IP provided in the package. But my favourite is definitely the SamlConfigTool: it is a slightly more raw counterpart of fedutil/add STS reference, which can consume metadata from one IP and generate the corresponding SP config settings. And just like fedutil, it can generate the SP metadata so that the IP can easily consume it for automating the SP provisioning as well.

The WIF Extensions for SAML.20 Protocol unlock some new, interesting scenario: and of course, being this a CTP the WIF team really wants your feedback. If you’ll play with the extensions, please take a moment to chime in and let us know what you think!

Live from TechEd Atlanta: Drew Shows Windows Azure, Windows Phone 7–Uses Identity to Glue Them

Vittorio Bertocci - MSFT — Mon, 16 May 2011 14:11:46 GMT

Just few hours ago Wade announced the new release of the Windows Azure Toolkit for Windows Phone, with support for ACS. You can already see the bits in action from the stage of the TechEd keynote – nonetheless – from where a very elegant Drew Robbins is demonstrating Fabrikam Fiber, a really cool scenario scenario which integrates Windows Azure (storage, compute, Windows Azure Connect, Traffic Manager), Windows Phone 7 (featuring a lot of dev tools features coming in Mango!) and, or course, the Windows Azure AppFabric Access Control Service.

The scenario demonstrated uses the next evolution of the toolkit, where the integration with ADFS2 will make user provisioning no longer necessary (see notes in this post). That’s cool stuff, folks! Tune in to the keynote live streaming, or check out the recordings afterwards: highly recommended.

Bring Your Active Directory in Your Pockets with ACS, OAuth 2.0 and the New Windows Azure Toolkit for Windows Phone 7

Vittorio Bertocci - MSFT — Sun, 15 May 2011 23:11:00 GMT

As promised last week, today Wade released the 1.2 version of the Windows Azure Toolkit for Windows Phone 7. And again as promised, this version has full support for ACS!

Using the new feature is super straightforward: you can see that by yourself in the quickstart video in which I walk through the simplest ACS configuration.

As mentioned in the teaser post last week, we purposefully kept the VS template very simple. As a result, the initial setup ends up with one application which supports Windows Live ID, Yahoo! and Google, the identity providers which are pre-configured within ACS.

However, once the project has been created nothing prevents you from working directly on you ACS namespace for adding new identity providers, such as Facebook or even your own Active Directory; those identity providers will automagically show up in the list of IPs in the login screen without he need of changing a single line of code. Want proof? Read on!

Adding a New WS-Federation Provider (like ADFS2)

Here I’ll assume that you went through the steps I show in the quickstart video and you ended up with the basic ACS application as created by the toolkit.

If you want to enable your users to sign in the application using their Active Directory accounts, you can go directly to the ACS namespace you are using and add you AD (assuming you have ADFS2 deployed) as an identity provider.

Note: Right now the toolkit bits are still handling access at the account level, which means that your users will need to go through the same sign-up step you have for users coming from social providers; however this does not subtract anything to the joy of being able to reuse your domain credentials on a device, instead of having to memorize yet another password. In the future the integration will be even more seamless: think claim mapping rules, along the lines of what we’ve done for integrating ADFS2 with Umbraco.

Well, let’s do it then: it will only take a minute!

As usual I don’t have an ADFS2 instance on my laptop, hence I’ll simulate it using SelfSTS. This time I picked the SelfSTS1 folder from the assets of the ACS and Federation lab, copied it under c:\temp and modified it a bit to emit a different set of claims:

I also changed its port from the config, generated a new certificate, hit Start and refreshed the federationmatadata.xml file (hint: use the URL from the metadata field to open the file in Notepad, then save it over the old metadata file). Those may not be strictly necessary, but I always do that for avoiding collisions.

Now that you have your ADFS2 simulation up & running, go to your namespace in the ACS portal at https://YOURNAMESPACE.accesscontrol.windows.net/v2/mgmt/web. From there go to Identity providers, hit Add, keep the default ws-federation and hit Next.

From here you can add your SelfSTS instance. Remember, it simulates your AD! If you have an ADFS2 instance, use that instead. Enter whatever name you want in the display name and login text link fields, upload the metadata file from your SelfSTS, scroll to the bottom of the page and hit Save.

Now click Rule groups form the left-hand menu, click on Default Rule Group for WazMobileToolkit, hit the Generate link, accept the defaults and click the Generate button. You can also hit Save for good measure, if you are superstitious .

And you’re done! Go back to Visual Studio and start the portal/service and the phone client as shown in the quickstart. Here there’s what you’ll see on the phone app:

That’s right! Just like that, now your AD appears as one of the options. Neat. If you pick that option, ACS will contact SelfSTS for authenticating you. If you would be using a real ADFS2 instance at this point you would be prompted for your credentials: but SelfSTS is a test utility which automatically authenticates you, hence you’ll go straight to the next screen:

…and from now on everything is exactly as for the social providers: the user gets an entry in the system, which will be used for handling authorization. You can see it in the Users table in the management portal.

Let me reiterate: in addition to being able to use credentials from Windows Live ID, Yahoo and Google, the user can now reuse his domain credentials to sign in from one Windows Phone client to one application whose backend is in the cloud (Windows Azure). And enabling all that took just few clicks on the ACS management portal, no code changes required.

Now, do you want to hear a funny story? We did not plan for this. I am not kidding. I am not saying that we are surprised, I totally expected this, what I mean is that this scenario didn’t take any specific effort to implement, it came out “for free” while implementing support for ACS and social providers.
When you admit users from social providers in your application, you don’t receive very detailed (or verifiable, excluding email) information about the users; hence the usual practice is to create an account for the user and mainly outsource credential management to the external identity providers.
In the walkthrough above I treated my simulated ADFS2 exactly in the same way, and everything worked thanks to the fact that we are relying on standards and ACS isolates the phone application and the backend from the differences between identity providers. It’s the usual federation provider pattern, with the twist demonstrated in the ACS + WP7 lab; in a future blog post I’ll go a bit deeper in the architecture of this specific solution.

What could we accomplish if we’d explicitly plan for an identity provider like ADFS2? Well, for one: provision-less access, one of the holy grails of identity and access control
ADFS2 sources data from AD, hence can provide valuable information about its users (roles, job functions, spending limits, etc) which carries the reputation of the business running that AD instance. This means that we could greatly simplify the authorization flow, skipping the user registration step and authorizing directly according to the attributes in input. As mentioned above, we already have a good example of that in the ACS Extensions for Umbraco; that’s a feature that is very likely to make its way in the toolkit, too

There you have it. The bits are in your hands now, and we can’t wait to find out what you’ll accomplish with them! If you have feedback, please do not hesitate to visit the discussion section in http://watoolkitwp7.codeplex.com/. Happy coding!

25 Free Copies of “Programming Windows Identity Foundation” at Teched

Vittorio Bertocci - MSFT — Sat, 14 May 2011 07:42:37 GMT

Yesterday I posted about my sessions at TechEd and the book signing event. My friends at O’Reilly, though, graciously pointed out that I didn’t mention the juiciest fact:

The first 25 people who will show up at the book signing will receive a free copy of Programming Windows Identity Foundation! That is really super-nice of them.

Make sure you come at 11:00am on Tuesday the 17th at the O’Reilly booth (or is it the bookstore?) and we’ll get you something to read on your flight back!

TechEd USA 2010: Identity, Identity, Identity and Book Signing

Vittorio Bertocci - MSFT — Fri, 13 May 2011 07:30:00 GMT

These days practically everybody I meet on campus is preparing to fly to Atlanta for TechEd, with the notable exception of Steve Marx (it seems I may be losing our bet after all).

Atlanta holds a special meaning for me. Back in 2004 I won the Circle of Excellence award, which (among various awesome things) included a 1-hour long meeting with Bill Gates. You can of course imagine how many times that episode got told and retold, to the point that the memory is now a memory of a memory(^n) and entered the Myth; and with it the entire Atlanta city experience, with its raging thunderstorms and the weird-flavored sodas at the Coke Museum.

Well, this Sunday I am scheduled to fly down to Atlanta again, where I’ll be presenting three sessions and hold a book signing session.
Book signing session, I say? Why would somebody want to get their copy of the book written all over, which is very likely to lower the price it could command on eBay, is beyond me… but I’ll be happy to oblige! It will be Tuesday the 17th, at 11:00 AM at the O’Reilly booth (#1817). Or the bookstore?

For the sessions, we’ll have a couple of new entries. Let’s go in order:

SIM324 Using Windows Azure Access Control Service 2.0 with Your Cloud Application

Tuesday, May 17 | 8:30 AM - 9:45 AM | Room: C302

Level: 300 - Advanced

Track: Security, Identity & Management

The Windows Azure Access Control Service 2.0 provides comprehensive federation and authorization services for cloud applications, so that you don't have to build identity infrastructure yourself. Come to this session to learn how your application can take advantage of your user's existing Active Directory, Windows Live ID, Google, Yahoo, and Facebook accounts when they access your cloud application. This session is aimed at developers building cloud applications.

Product/Technology:

Cloud Power: Delivered, Windows Azure™, Windows® Identity Foundation

Audience:

Architect, Developer, Security Administrator, Solutions Architect, Strategic IT Manager, Systems Administrator, Systems Engineer, Tactical IT Manager, Web Administrator/Webmaster, Web Developer/Designer

Key Learning:

Understand how to simplify authorization in your applications using ACS 2.0 in Windows Azure

Finally, a session all about ACS. Although all ACS features appear in the generic claims in the cloud talk (see below), I never have the time to linger a bit on the how of the service: also, in this session I’ll try to touch on features a rarely have the time to show off.
Now, some extra comments here. Putting together a behemoth conference like TechEd is a monumental task, which is spread through multiple people. For example, I wrote the abstract for the sessions but not the Audience and Key Learning entries there, and they both contain some imperfection that may mislead you.

the audience for this talk is people in development roles. System Administrator types are NOT a target. I went to great lengths to be super clear in the title and the abstract about the audience, but something probably fell through the cracks.
About the key learning. ACS can do some authorization, but that is far from being its only (or even primary) feature. Don’t come with the wrong expectations!

Neeext!

SIM322 Developer's View on Single Sign-On for Applications Using Windows Azure

Tuesday, May 17 | 3:15 PM - 4:30 PM | Room: B312

Level: 300 - Advanced

Track: Security, Identity & Management
Signing users in and granting them access is a core function of almost every cloud-based application. In this session we show you how to simplify your user experience by enabling users to sign in with an existing account such as a Windows Live ID, Google, Yahoo, Facebook or on-premises Active Directory account, implement access control and make secure connections between applications. Learn how the AppFabric Access Control Service, Windows Identity Foundation, and Active Directory Federation Services use a cloud-based identity architecture to help you to take advantage of the shift toward the cloud while still fully leveraging your on-premises investments.
Product/Technology:

Cloud Power: Delivered, Windows Azure™, Windows® Identity Foundation

Audience:

Architect, Infrastructure Architect, Solutions Architect, Strategic IT Manager, Systems Administrator, Systems Engineer, Tactical IT Manager, Web Administrator/Webmaster, Web Developer/Designer

Key Learning:

How to simplify your approach enabling access to applications across on-premises and cloud

Nothing to say on this one. This is the usual scenarios enumeration talk which I’ve been giving around since PDC. COme only if you don’t know much about claims or our offering in that space for developers.

SIM325 Deep Dive: Windows Identity Foundation for Developers

Thursday, May 19 | 1:00 PM - 2:15 PM | Room: B313

Level: 300 - Advanced

Track: Security, Identity & Management
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 seamlessly with the traditional .NET identity object model while also giving developers complete control over every aspect of authentication, authorization and identity-driven application behavior. See examples of the point and click tooling with tight Microsoft Visual Studio integration, advanced STS capabilities, and much more that Windows Identity Foundation consistently provides across on-premise, service-based, Microsoft ASP.NET and Windows Communication Foundation (WCF) applications.
Product/Technology:

Windows® Identity Foundation

Audience:

Architect, Developer, Security Administrator, Solutions Architect, Strategic IT Manager, Systems Administrator, Systems Engineer, Tactical IT Manager, Web Administrator/Webmaster, Web Developer/Designer

Key Learning:

Learn how to use WIF to externalize authentication and authorization from your application.

Now this one is interesting. This session was supposed to be a 400, but yesterday I discovered that the catalog lists it as 300. Well, it’s a deep dive: hence it may end up being fairly 400ish, depending on the vibe I'll find the the room.

The key learning is good here, but unfortunately the audience is pretty off. Here “developers” is in the title, hence I won’t even start…

Well, that’s it. As usual, I am super happy to meet you guys at conferences: please do not hesitate to come and chat. Apart from the talk and book signing, you’ll see me hanging around the Identity and Windows Azure booths. See you next week!