Justin Smith's Blog : .NET Services

Mgmt Config sample for WLID / Facebook Connect sample

justinjsmith — Sun, 15 Nov 2009 21:41:33 GMT

Now that we have a mgmt tool, I can provide you with a template so you can setup the ACS part of the WLID / Facebook Connect sample with less effort. Here’s the XML configuration:

<ServiceNamespace xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Issuers>
    <Issuer handle="acswebauth">
      <IssuerName>acswebauth</IssuerName>
      <Algorithm>Symmetric256BitKey</Algorithm>
      <CurrentKey>gyiepxNtc7RkCZuvV6FyEPWOp788uc1T0DMSZ9c/5QA=</CurrentKey>
      <PreviousKey>bAO0llCgF5C00GW/h7Zp0lt2WAe3WRrdIj42UMbds+A=</PreviousKey>
    </Issuer>
  </Issuers>
  <Scopes>
    <Scope handle="root">
      <AppliesTo>http://acswebauth.com</AppliesTo>
      <TokenPolicyHandle>root</TokenPolicyHandle>
      <Rules>
        <Rule handle="wlidpassthrough">
          <Type>PassThrough</Type>
          <InputClaimIssuerHandle>acswebauth</InputClaimIssuerHandle>
          <InputClaimType>uuid</InputClaimType>
          <InputClaimValue xsi:nil="true" />
          <OutputClaimType>userid</OutputClaimType>
          <OutputClaimValue xsi:nil="true" />
        </Rule>
        <Rule handle="idppassthrough">
          <Type>PassThrough</Type>
          <InputClaimIssuerHandle>acswebauth</InputClaimIssuerHandle>
          <InputClaimType>idp</InputClaimType>
          <InputClaimValue xsi:nil="true" />
          <OutputClaimType>idp</OutputClaimType>
          <OutputClaimValue xsi:nil="true" />
        </Rule>
        <Rule handle="fbsession">
          <Type>PassThrough</Type>
          <InputClaimIssuerHandle>acswebauth</InputClaimIssuerHandle>
          <InputClaimType>fbsession</InputClaimType>
          <InputClaimValue xsi:nil="true" />
          <OutputClaimType>fbsession</OutputClaimType>
          <OutputClaimValue xsi:nil="true" />
        </Rule>
      </Rules>
    </Scope>
  </Scopes>
  <TokenPolicies>
    <TokenPolicy handle="root">
      <TokenLifetime>1200</TokenLifetime>
      <SigningKey>AZYQZFGR1epDZV3NC+sBEgOXVY4vIWTPZnEg28mDXy8=</SigningKey>
    </TokenPolicy>
  </TokenPolicies>
</ServiceNamespace>

Copy this to your clipboard, save locally, then click the load button

Browse to the file on your local machine, then click the Save to Cloud button. BE CAREFUL: clicking that button will erase the config in your ACS service namespace. We’ll get the merge written soon :)

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…

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.

Access Control Service and ADFS v2 demo

justinjsmith — Wed, 07 Oct 2009 14:42:00 GMT

In my last post I outlined the changes that were coming in the Access Control Service. Since that post, I’ve received many questions about how ACS will integrate with ADFS v2. Below is a link to a simple demo I put together to highlight this very cool integration point (video on Channel 9).

http://channel9.msdn.com/posts/justinjsmith/Access-Control-Service-and-ADFS-v2-Integration/

Mix 09 Deck

justinjsmith — Tue, 28 Apr 2009 17:53:14 GMT

For some reason the slide deck I presented at Mix didn’t show up on the Mix 09 website. If you are interested in the deck, see the link below.

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.

Federated website sample

justinjsmith — Fri, 13 Feb 2009 01:19:00 GMT

The Geneva Framework FAM is the simplest way to experience ACS and ASP.NET. My friends in platform evangelism wrote a cool app that uses ACS, LiveID, and the Geneva Framework. It's called issuetracker, and I recommend checking it out: http://www.codeplex.com/azureissuetracker

Access Control Service - Common Interaction Model

justinjsmith — Fri, 16 Jan 2009 20:32:00 GMT

In my previous post I described at a high level a simple scenario that leverages the Access Control Service. Now I'd like to describe the interactions between messaging participants and the .NET Access Control Service.

Recall the scenario: a multi-tenant payroll application is running in the cloud - it uses the Access Control Service to simplify federation with enterprise identity providers and handle RBAC processing.

The interaction pattern for this scenario is shown below.

Step 0

Before using the ACS, the payroll app (called Relying Party in the diagram) must establish a trust with ACS. This is done via a public key certificate exchange. The Relying Party administrator or developer defines or obtains a certificate from the certificate authority of it's choosing, then uploads the public key certificate to ACS.

Step 1

Next, the Relying Party administrator or developer will define access control rules in ACS. As indicated in my earlier post, the content of the rules is up to the administrator or developer. When this step is completed, ACS is setup and ready for use.

Step 2

The requestor sends a request for a token (Request for Security Token or RST) to ACS. An RST almost always contains claims (eg username / password, or another token issued from an identity provider).

Step 3

ACS then checks the claims in the RST. It then uses the input claims to determine the claims that will be sent in the RST response (called RSTR). Consider a simple rule: (Input) Username foo –> (Output) Role Administrator. If the input claim is Username foo, then the output claim is Role Administrator. ACS simply chains these rules together and calculates the output claim set.

Step 4

After the output claim set is determined, the claims are packaged into a SAML token and returned to the requestor. The token is signed with the ACS certificate and encrypted with the certificate used in step 0. There’s a little more to it than that, because the RP has to be able to differentiate its ACS STS from other ACS STSs. This will surely be a subsequent topic.

Step 5

The requestor then sends the token to the Relying Party along with a payload of its choosing.

Step 6

Upon receipt of the token + payload, the Relying Party verifies / validates the token, checks the claims in the token, then processes the payload accordingly. Concretely this means that the Relying Party verifies the token signature & decrypts the token. If the token signature / encryption keys are OK, the Relying Party then checks the claims in the token. If that endpoint or operation on the Relying Party requires Administrative privileges, then the token must contain an Administrator claim. Think of it like a simple toll gate. If the correct claim is present, the call proceeds. If not, then the call fails.

Claims Transformer

At a high level, ACS receives input claims and transforms them into output claims. We simplify these types of transformations into rules, and provide customers the ability to define these rules on a portal or through a simple API.

Access Control Service - A Simple Scenario

justinjsmith — Fri, 07 Nov 2008 10:42:56 GMT

To the already initiated claims disciples, the Access Control Service is a multi-tenant Resource STS. The behavior of each STS is determined by simple rules - the rules control how each STS transforms claims.

To those not already initiated in the claims methodology, the previous definition may seem a bit obtuse. If that's the case, then consider a simple scenario:

Background

Let's say you work for a software vendor (Foo) that sells a web application (how about employee payroll management) to businesses. You have an existing on-premise offering and an existing install base. This version of your software integrates with customer identity providers (e.g. Active Directory, Tivoli, etc.).

Customer administrators can allow other employees access to the payroll system - this is driven by group membership (e.g. Domain Users have access). Internally the application uses a set of pre-defined roles, and assigns permissions based on role membership. As an example, consider the following simple model:

Active Directory Group= HR Payroll --> Application Role = Administrator

Application Role = Administrator --> Permission = CreatePayroll

Application Role = Administrator --> Permission = PrintPayrollChecks

...

This approach is known as Role Bases Access Control (RBAC). It's very simple, powerful, and very common.

Given that Foo's existing offering is on-premise it works well. Initial setup requires some basic plumbing with a single on-premise identity provider and a bit of configuration by the application administrator.

The Winds of Change

Some of your existing customers and many prospects are asking for a hosted / cloud version of your payroll application. As your team considers options, it becomes apparent that a good long term approach is to modify the existing on-premise application to be multi-tenant. Modifying a single tenant application to be multi-tenant isn't a joke, but customers are demanding it, so you proceed.

One of the things your team realizes pretty quickly is that the RBAC model in the on-premise application has to change a bit. The core concept of mapping groups to roles to permissions appears to still be viable, but now there are multiple identity providers. Your application now has to be able to differentiate Bar Corporation Groups from Baz Corporation Groups.

Luckily most of the software vendors that sell identity providers have built versions of their identity providers that will expose groups and other identity attributes outside of the corporate LAN. I believe that Microsoft's offering in this area is outstanding (Geneva Server, Geneva Framework, Microsoft Services Connector and the Federation Gateway - see Kim Cameron's blog for fantastic details). Concretely, this means that the hosted, multi-tenant version of your application can federate with lots of different corporate identity providers.

The Access Control Service

There is still a problem, however. You'll have to add quite a bit of code to your application to accept and parse tokens from these identity providers. To top it off, you'll have to make it pretty flexible and configurable. This is where the Access Control Service shines. In a nutshell, it is a service that simplifies interactions with any standards based identity provider, and allows you to define rules that transform Groups to Application Roles to Application Permissions.

To put it another way, your application won't have to directly interact with any identity providers. It can trust tokens from the Access Control Service. The Access Control Service will handle the gory details of decrypting, verifying and parsing tokens, extracting Groups (or other identity attributes) from tokens, and mapping Groups to Application Roles to Permissions. The end result is a single sign-on experience for your customers, and a simplified code base.

Up next - the common interaction model of the Access Control Service & why claims disciples call it a claims transformer.