Justin Smith's Blog : Azure Services

ACS integration with Windows Live ID & Facebook Connect

justinjsmith — Sun, 15 Nov 2009 21:20:28 GMT

I’ve received several requests regarding ACS and Windows Live ID integration for websites. This post describes what you can do with ACS and Windows Live ID today (with the new release of ACS). It takes a bit of code, but the integration is pretty straightforward.

Note that this code isn’t hardened and it relies heavily on server side code. I’m showing it as an architectural sample, and I’m showing it now based on the number of requests I’ve received for the sample. In the future, I’ll work on a better sample that’s easier to setup (and possibly one that uses javascript & cross domain iFrames).

I’ll be discussing WLID Web Authentication as an integration point. The same basic model can apply to other WLID capabilities and other web identity providers. The code sample also has Facebook connect integration, but I won’t go into any detail about how it works in this post (in the future I will).

The basic model is fairly simple. The swim lane and description is shown below.

1. A user browses to your website and clicks a login button.

2. This button redirects the user to the WLID Redirector. The code for this redirector is in this post. For now, you’ll need to write and host this code yourself.

3. The redirector redirects the browser to the WLID login page with correct WLID AppID. From there, the user logs into WLID using their credentials.

4. Upon a successful login, WLID returns the browser to the redirector. The response contains a unique pair-wise ID for that user.

5. Once the redirector receives the user ID, it packages that ID into an ACS token request (OAuth WRAP request for an Access Token)

6. ACS will issue a token for that user and return it to the redirector (the token is a SWT).

7. From there, the redirector will return the ACS token to the website

8. The website will validate the token. If validation passes, the website will write the token to a cookie.

9. (Not shown on the diagram) On subsequent requests to the website, the website will use the cookie to authenticate and authorize the user.

10. (Not shown on the diagram) If the user logs out, the website will clear the cookie and send the browser to the redirector. From there, the redirector will send the browser to WLID for logout. This will remove the WLID cookie for that website.

Setup Steps IdpRedirector project

1. First, you’ll need to have a domain name for the redirector. You can host the redirector in Azure, or your own server. The site needs to have a public address.

2. After you have the address, go to the Live ID developer portal at http://go.microsoft.com/fwlink/?LinkID=144070

3. Setup your WLID developer account. The steps are at http://msdn.microsoft.com/en-us/library/bb676626.aspx.

The only trick here is to be very careful about the return URL. For this sample, you’ll want to enter http://<yourdomainname>/wlidfederation-handler.aspx, where <yourdomainname> is the hostname + any subdomains for your redirector.

4. Copy the Application ID and Secret shown below

5. Open the VS solution in the zip at the bottom of this post.

6. In the WebRedirector project, open the web.config and edit the values below with your Application ID and secret.

<add key="wll_appid" value="yourappid"/>

<add key="wll_secret" value="yoursecret"/>

7. Change the rploginpage and rplogoutpage to the URL for the RelyingPartyWebsite project. I used Cassini in this project, so your port number will likely change.

<add key="rploginpage" value="http://localhost:32210/RelyingPartyWebsite/login.aspx"/>

<add key="rplogoutpage" value="http://localhost:32210/RelyingPartyWebsite/logout.aspx"/>

8. Update the ACS specific settings.

<add key="serviceNamespace" value="updateToYourServiceNamespace"/>

<add key="clientIssuerKey" value="updateToYourIssuerKey"/>

<add key="clientIssuerName" value="updateToYourIssuerName"/>

<add key="tokenPolicyKey" value="updateToYourTokenPolicyKey"/>

<add key="acsHostName" value="accesscontrol.windows.net"/>

<add key="applies_to" value="updateToYourAppliesTo"/>

9. Upload the project to the domain specified in (3)

Setup Steps RelyingPartyWebsite project

10. Open the web.config of the RelyingPartyWebsite in VS. Update the appSettings below to the settings for your ACS Service Namespace & the domain of your IdPRedirector.

<add key="idpRedirectHost" value="updateToYourRedirectorHost"/>

<add key="serviceNamespace" value="updateToYourServiceNamespace"/>

<add key="tokenPolicyKey" value="updateToYourTokenPolicyKey"/>

<add key="acsHostName" value="accesscontrol.windows.net"/>

<add key="applies_to" value="updateToYourScopeAppliesTo"/>

Running The Sample

11. Start the RelyingPartyWebsite and browse to the Default.aspx page. You should see something like the following:

12. If you click on the WLID icon, you’ll be redirected to the IdPRedirector, then to WLID. Enter your creds at WLID & you should be redirected back to the IdPRedirector, then to the login.aspx page in RelyingPartyWebsite. If all is well, you’ll see something like:

Here’s the code sample:

ACS SAML / ADFS v2 Sample

justinjsmith — Sat, 14 Nov 2009 22:55:25 GMT

The November 2009 CTP of ACS integrates with Active Directory Federation Server v2. ACS can act as a bridge between enterprise identity and REST web services.

The runtime flow is pretty simple (shown below).

At runtime, the client app requests a SAML bearer token from AD FS v2. The easiest way to do this is with Windows Identity Foundation (WIF).
The client app POSTs the SAML token to ACS over SSL. ACS uses configurable rules to calculate the claims in a Simple Web Token (SWT), creates a SWT, signs it, and returns it to the client app. The protocol for this exchange is OAuth WRAP.
Next, the client packages the SWT in the HTTP Authorization header and sends it to the REST web service along with whatever payload the REST web service requires.
Once the REST web service receives the token & payload, it validates the token and checks the claims in the token. The REST web services allows or denies access based on the outcome.

Viola. You have a REST web service that integrates with AD FS v2 via OAuth WRAP and SWT.

Mini AD FS setup (for this scenario only)

There is some setup required to enable this scenario (other than acquiring an ACS Service Namespace). For starters, you’ll need an AD FS v2 server. Since this requires a domain, I’ve provided a service that replicates the basic token issuing behavior of AD FS (at the bottom of this post). The only relying party trusted by this service is ACS.

To setup the service, you’ll need to update the App.config file. Update the “signingCertName” to a cert in your LocalMachine / Personal cert store. Also update the “serviceNamespace” to your ACS service namespace.

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
  <appSettings> 
    <add key="signingCertName" value="CN=localhost"/> 
    <add key="stsBaseAddress" value="localhost/miniadfs"/> 
    <add key="stsPath" value="Trust/13/Windows"/> 
    <add key="serviceNamespace" value="justinpdcdemo"/> 
    <add key="acsHostname" value="accesscontrol.windows.net"/> 
  </appSettings> 
</configuration>

You’ll also have to setup SSL for your IIS install (http://learn.iis.net/page.aspx/144/how-to-setup-ssl-on-iis-70/)

You’ll also need to install the WIF RC. Available here: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=defd2019-a61f-4327-9332-6a4b6103527a#tm

From there, you should be able to run the service.

Fed Metadata Setup with ACS

After you have the mini ADFS service running, you’ll want to use the Fed Metadata it publishes to create an issuer in ACS. Also in the sample below is some code that shows you how to programmatically do that.

If you’d rather use a tool, you can use the Management Browser (http://code.msdn.microsoft.com/acmbrowser).

Simply create a new Issuer, select FedMetadata from the Algorithm drop down, and set the URL of the fed metadata server. In the miniADFS server, that URL is https://localhost/LocalADFSv2/FederationMetadata/2007-06/FederationMetadata.xml

Creating a Scope & Rule for the new Issuer

Next, you’ll want to create a scope and a rule that refers to that issuer. The sample at the bottom of this post uses a scope with an applies_to URI of http://localhost/samltest. You can use the Management Browser to create one.

With the scope in place, we can create a rule. All rules require the name of the Issuer and a claim type in the antecedent. When you create an Issuer using Fed Metadata, the Issuer name is fixed in the Fed Metadata. My MiniADFS server uses an issuer name of https://localhost/miniadfs/Trust/13/Windows. It also spits out claims of type http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name.

With that data, you can create a Passthrough rule. Passthrough rules basically countersign the input claims. In this case, a passthrough rule would countersign any http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name claim issued by the issuer https://localhost/miniadfs/Trust/13/Windows. The consequent of the rule can be of any type you choose. To keep the token compact, I’ll use a claim type of “name”.

You can set all this up using the management browser, as shown below.

Acquiring A SAML Token

With the Issuer, Scope, and Rule setup, let’s get a SAML token using WIF (the RC). The code for doing this is in the SAMLClient project from the code sample in this post. The WIF code is pretty straightforward:

private static string GetSAMLToken()
{
    WSTrustChannelFactory trustChannelFactory =
        new WSTrustChannelFactory(new WindowsWSTrustBinding(SecurityMode.TransportWithMessageCredential),
            new EndpointAddress(new Uri(samlUrl)));

    trustChannelFactory.TrustVersion = TrustVersion.WSTrust13;

    try
    {
        RequestSecurityToken rst =
            new RequestSecurityToken(WSTrust13Constants.RequestTypes.Issue, WSTrust13Constants.KeyTypes.Bearer);
        rst.AppliesTo = new EndpointAddress(acsUrl);
        rst.TokenType = Microsoft.IdentityModel.Tokens.SecurityTokenTypes.Saml2TokenProfile11;

        WSTrustChannel channel = (WSTrustChannel)trustChannelFactory.CreateChannel();
        GenericXmlSecurityToken token = channel.Issue(rst) as GenericXmlSecurityToken;
        string tokenString = token.TokenXml.OuterXml;
        return tokenString;
    }
    finally
    {
        trustChannelFactory.Close();
    }
}

The only trick is to ensure you are using the Bearer key type (Yes, you can use WIF to request a Bearer token).

Using the SAML token to get a SWT

Next, you can use the SAML token to request a SWT from ACS:

private static string SendSAMLTokenToACS(string samlToken)
{
    try
    {
        WebClient client = new WebClient();
        client.BaseAddress = acsUrl;

        NameValueCollection parameters = new NameValueCollection();
        // ensure the applies_to URI is created in your ACS
        // service namespace
        parameters.Add("applies_to", "http://localhost/samltest");
        parameters.Add("wrap_SAML", samlToken);

        byte[] responseBytes = client.UploadValues("", parameters);
        string response = Encoding.UTF8.GetString(responseBytes);

        return response
            .Split('&')
            .Single(value => value.StartsWith("wrap_token=", StringComparison.OrdinalIgnoreCase))
            .Split('=')[1];
    }
    catch (WebException wex)
    {
        string value = new StreamReader(wex.Response.GetResponseStream()).ReadToEnd();
        throw;
    }
}

Viola! That’s all there is.

Here’s the full code sample – Let me know any feedback you have…

Management Browser uploaded

justinjsmith — Sat, 14 Nov 2009 19:15:29 GMT

Since releasing the new version of ACS on Nov 5, we’ve received quite a bit of feedback that we should provide a UI for managing ACS rules/scopes/issuers/token policies. In response, Cyrus put together a little WPF app that does the trick. It’s available on MSDN code gallery here: http://code.msdn.microsoft.com/acmbrowser

In the coming milestones, we are going to work on refining a UI – cutting it out of the Nov 5 release was a difficult decision. I’m confident that we will release a supported one in the coming milestones.

For now, hopefully this one will help. As always, please send us your feedback.

Web Resource Authorization Protocol (WRAP) and Simple Web Token (SWT) on google groups

justinjsmith — Fri, 06 Nov 2009 00:17:00 GMT

The Access Control Service uses a new community protocol and format that are now posted on google groups: ~~http://groups.google.com/group/wrap-wg~~ http://groups.google.com/group/oauth-wrap-wg

Check em out. If you are a security geek, it’s worth the read.

Interesting article on Azure Services

justinjsmith — Thu, 26 Mar 2009 11:20:16 GMT

Today I caught up on some press material on Azure Services. For those that haven’t seen it, the picture version of Azure Services is below:

One article published in late February popped out at me: http://blogs.zdnet.com/microsoft/?p=2173.

Among other things, this article brings good questions regarding how aligned and integrated the Azure Services platform is today. A quote from the article:

“Our engineering efforts are fully aligned with Red Dog now,” said Shewchuk. “We expect them (Red Dog) to be available with a fully integrated developer experience” upon which CSD and its customers can count when working with .Net Services, SQL Data Services and other components.

To be clear, the end results of this engineering alignment aren’t fully apparent yet. As John indicates, we are working on it.