The Microsoft Security Intelligence Report for 2010 was released not too long ago. It is a report on the threat landscape seen across 600 million systems worldwide.
This report has a summary for quite a number of countries (170 and counting), and Canada is in the list. Here are the stats they found:
Microsoft detected malware on 4.2 of every 1,000 computers scanned in Canada in 4Q10 (a CCM score of 4.2, compared to the 4Q10 average worldwide CCM of 8.7).
- The most common category in Canada in 4Q10 was Adware, which affected 35.6 percent of all cleaned computers, down from 41.0 percent in 3Q10.
- The second most common category in Canada in 4Q10 was Misc. Trojans, which affected 35.3 percent of all cleaned computers, up from 29.0 percent in 3Q10.
- The third most common category in Canada in 4Q10 was Misc. Potentially Unwanted Software, which affected 26.3 percent of all cleaned computers, down from 26.1 percent in 3Q10.
Ever have one of those days where you swear that you've written something, but can't find it? I could have sworn that I wrote this article before. Ah well.
--
It makes a lot of sense to use ACS to manage Identity Providers. It also makes sense to use Active Directory for letting users sign in to your cloud application. Therefore we would hope that ACS and ADFS play nicely together. It turns out they do. in a previous post I talked about federating ACS and ADFS, where ACS is an identity provider to ADFS. Now lets reverse it. We want users to be redirected to ACS, then to ADFS to sign in.
First things first. Lets log into our ACS namespace and navigate to the Identity Provider section, and then Add an Identity Provider:
From there we want to select what type of provider to use, and in this case we will select WS-Federation:
We are now provided with a form to fill out. There are five properties: Display Name, WS-Federation metadata, Login Link text, Image Url, and Email domain names.
Display name is fairly straightforward. What do you want the internal name of this IdP to be?
Next we need to provide a link to the Federation Metadata document that ADFS provides. The path is https://adfs.domain.com/FederationMetadata/2007-06/FederationMetadata.xml.
Then we give it a public name, such as "ObjectSharp Internal Users".
If we want to use an image instead if showing text, we can provide a path to the image.
Finally we are asked for a semicolon separated list of email domains. This may seem a bit confusing at first. Basically, it allows us to filter out the IdP from the Home Realm Discovery page, and requires that the user enter in their email address. That way, instead of seeing the "ObjectSharp Internal Users" link, we are provided a text box, where we need to enter an email address like ssyfuhs@objectsharp.com. ACS will then look up the domain in their list, and if there is a reference to it, it will redirect to the IdP.
This takes care of the ACS bit. just like in the previous post, you need to tell the other IdP about the other. So we need to tell ADFS that ACS will be calling. This is pretty simple. We just need to add a relying party to ADFS using the ACS metadata. You can find the ACS metadata under Application Integration:
There isn't much to federating ADFS to ACS and vice-versa.
When you start working with Windows Azure in your spare time there are quite a few things that you miss.
I knew that it was possible to manage Windows Azure with multiple accounts, but since I was the only one logging into my instance, I never bothered to look into it. Well as it turns out, I needed to be able to manage Azure from a separate Live ID. It's pretty simple to do. You get into your subscription, navigate to User Management under the Hosted Services tab, and then you add a new Co-Admin.
Turns out that you can't manage ACS this way though. You don't have access to the namespaces as the Co-Admin. Crap. That's really what I wanted to manage with the separate account. After a minute of swearing at the control panel, I logged into ACS with my original account and looked around.
Portal Administrators
Aha! It was staring me right in the face:
There is a full MSDN article on how to deal with Portal Administrators.
Upon clicking the link you are given a list of current administrators. I wanted to add one.
When you add an administrator you are given a list Identity Providers to choose from. Interesting.
This means that I can manage this ACS namespace using any IdP that I want. I already have ADFS created as an IdP, so I'm going to use it. Getting Single Sign-On is always a bonus.
It asks for a claim type. When the ACS management portal receives a token, it will look for this claim type and compare it's value to the Identity claim value. If it matches the value, you are authorized to manage the namespace. I chose email address. It seemed simple enough. To log in I just navigate to https://syfuhs2.accesscontrol.windows.net/ and then gives me the default Home Realm Discovery page:
I've already preconfigured ACS to redirect any email addresses with the objectsharp.com domain to our ADFS instance. Once I click submit it redirects to ADFS, I authenticate using Windows Authentication, and then I'm back at the ACS Control Panel. The next time I go to log in, a cookie will be there and the Home Realm Discovery page will see that I logged in with ADFS last time, so it will list that option first:
It just so happens that ObjectSharp is Awesome.
Now how cool is that?
Sometime in the last few years Facebook has gotten stupidly popular. Given the massive user base, it actually makes a little bit of sense to take advantage of the fact that you can use them as an identity provider. Everyone has a Facebook account (except… me), and you can get a fair bit of information out of it on the user.
The problem though is that it uses OpenAuth, and I, of course, don't like OpenAuth. This makes it very unlikely for me to spend any amount time working with the protocol, and as such wouldn't jump at the chance to add it into an application. Luckily ACS supports Facebook natively – AND it's easy to setup.
First things first, we need to log into our ACS management portal, and select Identity Providers under Trust Relationships. Then we need to add a new Identity Provider:
Then we need to select Facebook as the type we want to add:
Once we start filling out the details for the federation we need to get some things from Facebook directly.
There are three fields we need to worry about, Application ID, Application secret, and Application permissions. We can get the first two from the settings page of our Facebook application, which you can get to at www.facebook.com/developers/.
You should create a separate application for each instance you create, and I'll explain why in a minute.
You then need the Application permissions. This is a list of claims to request access to from Facebook. The full list can be found here: http://developers.facebook.com/docs/authentication/permissions/, but for now email will suffice.
Once you have saved this identity provider you need to create a rule for each relying party. This will define how the claims are transformed before being sent to your relying party. If you already have rules set up you can modify one:
I'm pretty content with just using the default rules, which is to just pass everything, but you need to generate them first:
Once the rules have been generated you can save the rule.
Now you can test the federation.
It should fail.
If you watched everything in Fiddler you will see a chunk of JSON returned that looks something like:
{
"error": {
"type": "OAuthException",
"message": "Invalid redirect_uri: Given URL is not allowed by the Application configuration."
}
}
This is about my warning earlier about creating a separate application for each ACS namespace. Basically, Facebook doesn't like the request for authentication because it has no idea who the requestor is. Therefore I need to tell Facebook about my application.
To do this you need to get into the Web site settings for your application Facebook:
You will need to set the Site URL property to the ACS namespace:
Given the requirement for the FQDN, you need to create an application for each namespace you decide to create.
At this point federation with Facebook should now work. If you are using the default login page you should see something like this:
And if you sign-in you should get a token from Facebook which ACS will normalize, and then return to your relying party. Based on the permissions request you set above you should see something this:
** UPDATE **
Some of you may be wondering about this AccessToken claim. Part of the ACS configuration asks for a set of permissions to request, and these permissions are tied to this access token. Instead of receiving everything within claims, you need to make a separate call to Facebook to get these details by using the access token.
Dominick Baier has a good article explaining how to accomplish this: http://www.leastprivilege.com/AccessControlServiceV2AndFacebookIntegration.aspx.
** END UPDATE **
For those of you who want to federate with Facebook but don't like the idea of writing OpenAuth goo, ACS easily simplifies the process.
Part of the Mix11 announcement was that ACS v2 was released to production. It was actually released last Thursday but we were told to keep as quiet as possible so they could announce it at Mix. Here is the marketing speak:
The new ACS includes a plethora of new features that customers and partners have been asking with enthusiasm: single sign on from business and web identity providers, easy integration with our development tools, support for both enterprise-grade and web friendly protocols, out of the box integration with Facebook, Windows Live ID, Google and Yahoo, and many others.
Those features respond to such fundamental needs in modern cloud based systems that ACS has already become a key asset in many of our own offerings.
There is a substantial difference between v1 and v2. In v2, we now see:
Federation provider and Security Token Service (FINALLY!)
- Out of box federation with Active Directory Federation Services 2.0, Windows Live ID, Google, Yahoo, Facebook
New authorization scenarios
- Delegation using OAuth 2.0
Improved developer experience
- New web-based management portal
- Fully programmatic management using OData
- Works with Windows Identity Foundation
Additional protocol support
- WS-Federation, WS-Trust, OpenID 2.0, OAuth 2.0 (Draft 13)
That's a lot of stuff to keep up with, but luckily Microsoft has made it easier for us by giving us a whole whack of content to learn from.
First off, all of the training kits have now been updated to support v2:
Second, there are a bunch of new Channel9 videos just released:
Third, and finally, the Claims Based Identity and Access Control Guide was updated!
Talk about a bunch of awesome stuff.
So how do you know when Windows Azure Access Control Services has upgraded to V2? You get federation metadata…
Or you follow the Windows Azure App Fabric team blog!
I have been waiting MONTHS for this release, begging and pleading with Microsoft to get more information on when the big day would come. Needless to say I am super excited!
This version adds:
Federation provider and Security Token Service (FINALLY!)
- Out of box federation with Active Directory Federation Services 2.0, Windows Live ID, Google, Yahoo, Facebook
New authorization scenarios
- Delegation using OAuth 2.0
Improved developer experience
- New web-based management portal
- Fully programmatic management using OData
- Works with Windows Identity Foundation
Additional protocol support
- WS-Federation, WS-Trust, OpenID 2.0, OAuth 2.0 (Draft 13)
Now to just migrate from Appfabric Labs…
Got this email earlier today:
Dear Steve Syfuhs,
Congratulations! We are pleased to present you with the 2011 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Developer Security technical communities during the past year.
[…]
Needless to say I'm super excited about this award, and the opportunity that it gives me to talk more about security. More on this later.
Now I just need to figure out what to put in my email signature. 
When you set up ADFS as an IdP for SAML relying parties, you are given a page that allows you to log into the relying parties. There is nothing particularly interesting about this fact, except that it could be argued that the page allows for information leakage. Take a look at it:
There are two important things to note:
- I'm not signed in
- I can see every application that uses this IdP
I'm on the fence about this one. To some degree I don't care that people know we use ADFS to log into Salesforce. Frankly, I blogged about it. However, this could potentially be bad because it can tell an attacker about the applications you use, and the mechanisms you use to authenticate into them.
This is definitely something you should consider when developing your threat models.
Luckily, if you do decide that you don't want the applications to be visible, you can make a quick modification to the IdpInitiatedSignOn.aspx.cs page.
There is a method called SetRpListState:
protected void SetRpListState( object sender, EventArgs e )
{
RelyingPartyDropDownList.Enabled = OtherRpRadioButton.Checked;
ConsentDropDownList.Enabled = OtherRpRadioButton.Checked;
}
To get things working I made two quick modifications. First I added the following line of code to that method:
OtherRpPanel.Visible = this.IsAuthenticated;
Then I added a line to the Page_Init method:
SetRpListState(null, null);
Now unauthenticated users just see this:
And authenticated users see everything as expected:
You could extend this further and add some logic to look into the App Settings in the web.config to quickly and easily switch between modes.
A quickie, but a goodie.
In an earlier post on setting Salesforce.com as a SAML Relying Party to ADFS, I talked about how I felt a little dumb because I couldn’t figure out how to get ADFS to post the token to Salesforce. The reason I felt that way was because with WS-Federation there is a URL parameter that is designed to tell the STS which relying party requested the token. Notsomuch with SAML.
Turns out with ADFS there is such a parameter. By default if you pass in ?loginToRp=[rpIdentifier] to the IdpInitiatedSignOn.aspx page, ADFS will look for a relying party based on the parameter.
If you are unsure of what identifier to use, you can go to the relying party properties, and check out the Identifiers tab. It will accept any of the identifiers in the list:
As an aside, if you don’t like that URL parameter name, you can go into the IdpInitiatedSignOn.aspx.cs file and update line 21 to whichever you feel is appropriate:
const string RpIdentityQueryParameter = "loginToRp";
Then you compile the site, and redeploy.
You are properly securing ADFS by compiling the site’s source code, right? 
Other possible titles:
- So Long and Thanks for all the Identity
- Goodbye awesome technology; Hello Awesomer Technology
- CardSpace? What’s CardSpace?
Over on the Claims Based Identity Blog they made an announcement that they have stopped development of CardSpace v2. CardSpace was an excellent technology, but nobody used it. Some of us saw the writing on the wall when Microsoft paused development last year, and kept quiet about why. For better or for worse, Microsoft stopped development and moved on to a different technology affectionately called U-Prove.
U-Prove is an advanced cryptographic technology that, combined with existing standards-based identity solutions, overcomes this long-standing dilemma between identity assurance and privacy. This unlocks a broad range of scenarios that have historically been out of the reach of both the private and public sectors - cases where both verified identity information and privacy are required.
So what exactly does this mean? Central to U-Prove is something called an Agent:
Specifically, the Agent provides a mechanism to separate the retrieval of identity information from trusted organizations from the release of this information to destination sites. The underlying mechanisms help prevent the issuing organizations from tracking where or when this information is used, and to help prevent different destination sites from trivially linking users’ actions together.
Alright, what does that really mean?
Short answer: it’s kind of like CardSpace, except you—the developer—manage the application that controls the flow of claims from IdP to RP.
The goal is to enable stronger control of the release of private data to relying parties.
For more information check out the FAQ section on Connect.