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 :)

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:

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).

1. 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).
2. 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.
3. 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.
4. 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();
    }
}

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…

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.

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.

Today is a big day for the Access Control Service team. M7 is now live. There are a few huge changes:

1. It is running on top of Azure (fabric and storage)
2. We incorporated a new community driven protocol and token format (Web Resource Authorization Protocol (WRAP) and Simple Web Tokens (SWT))
3. Relying Parties and Requestors can use ACS from any platform that is capable of HMACSHA256 calculations and HTTPs FORM POSTs
4. It integrates with AD FS v2 (strictly speaking this isn’t a change, but it is definitely worth mentioning
5. It also enables what I like to call Simple Delegation. In a nutshell, this allows requestors to grant others access to a relying party on their behalf.

To access the new services go to https://netservices.azure.com

The team worked unbelievably hard on this release. Special shout out to Cyrus Harvsef, Afshin Sepehri, Blaine Dockter, Dan Smiley, Ankit Patel, Arnab Ghosh, Hristina Popova,  Maciej Skierkowski, Yaron Golan, and many others for bringing this together.

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/

We are in the process of making some key design changes to the Access Control Service (ACS) for our PDC release this fall. I think these changes will bring tremendous benefits to ACS customers in the near-term, but the changes break all ACS-related code that exists today.

This post summarizes the planned changes and provides some guidance for early ACS adopters.

It expands on (and is a bit more unvarnished than) the announcement made here: http://blogs.msdn.com/netservices/archive/2009/09/18/update-on-the-next-microsoft-net-services-ctp.aspx

Summary of Changes

We have decided to focus our efforts on addressing the large, unmet need around access control for REST web services. In concrete terms, this means that the WS-* integration features we support today will be temporarily unavailable while we focus on delivering a robust infrastructure for REST web service authorization. Once this infrastructure is in place, we will work to bring back features like website single sign on and rich WS-* support.

Motivation and Scope

There’s no doubt that Microsoft has made significant, long-term investments in security and identity management using the WS-* protocols: WS-Trust, WS-Federation, WS-Security and others. These protocols are proven and secure, widely adopted by enterprises, and will continue to be a central focus for ACS and other Microsoft groups working on enterprise security and identity management.

At the same time, as REST web services have become very popular with both web and enterprise developers, a gap has emerged in the market place for identity and access control technology. Today, developers of REST web services lack an easy, accessible means to secure their services. They face a lack of consistency and common patterns for managing identity and access control in a way that is compatible with the REST focus on simplicity. As REST developers move towards the enterprise, they will have an increasing need for robust security. They will be required to address the more systematic security concerns of enterprise customers as well as the more complex identity management scenarios that enterprises present. They will need a way to address these requirements that is simple and that integrates well with REST.

Taking this problem as an opportunity to differentiate the ACS offering and serve an even broader range of developers, we have experimented over the past several months with a simplified approach to the way that ACS packages and transits security tokens. Although this simplified approach has been designed to meet the needs of REST web service developers, it will appeal to all developers that want an easy way to take advantage of our services or that wish to use the .NET Services from non-Microsoft platforms.

At MIX09 we exposed some of our thinking about this new approach as a way to gauge customer interest (See JohnShew’s presentation). In addition to talking about our goals for simplicity and broad interoperability, we demonstrated the ability to control access to SaaS web sites using a variety of different consumer identities. Consistent with our theme, we showed that this approach can radically simplify the REST developer experience. Response to the MIX09 presentations was overwhelmingly positive and confirmed our sense that we were on the right track.

From this and other customer feedback, we have come to the conclusion that the lack of tools for controlling access to REST web services is one of the major pain points faced by service developers today. We believe that ACS is well-positioned to address this need in a way that compliments other MSFT offerings in the security and identity management space. The combination of simplicity and support for key enterprise integration scenarios will ensure that ACS appeals to our enterprise customers, while simultaneously meeting the needs of an even broader developer audience. In future releases, we will reinstate full support for the WS-* protocols, web Single Sign On, and round out the ACS offering in a way that spans the REST/SOAP spectrum.

Roadmap

In light of these considerations, we have made significant changes to our product roadmap. The following is a summary of the current ACS roadmap that reflects these changes:

PDC 2009: Simple Web Trust – Authorization for REST Web Services and the Azure Service Bus

• Two token exchange endpoints: REST with symmetric key and REST with SAML Extension

• REST with symmetric key makes it trivially easy for developers on any platform to package claims for ACS
• REST with SAML Extension will work with tokens issued by ADFS V2
• Both endpoints will be addressable using standard HTTPs POST requests
• ACS will transform input claims to output claims using configurable rules
• ACS will package and transit output claims using REST tokens

The Road ahead: Authorization for Web Sites and WS-* Support

New feature development post-PDC will be organized into two streams.

Single Sign On and Authorization for Web Sites

• Web sites can automatically redirect users to ACS for authentication and authorization
• ACS will broker the authentication process with external identity providers, process resulting claims and return the user to the originating web site with the claims issued by ACS
• Web sites can allow users to login using a broad range of existing consumer or corporate identities
• Integrates with ADFS V2 and other directories that support WS-Federation Passive or OpenID

WS-* Support

• Web services and web sites can take advantage of enhanced security and integration capabilities offered by WS-Trust and WS-Federation
• Support CardSpace

To align with this roadmap and make it possible to efficiently support and extend our release, we have invested in extending the foundations of the ACS platform. As a consequence, we have had to constrain the features that are in scope for PDC and carefully identify the scenarios that we are targeting. The following section describes the two core scenarios that will be supported at PDC.

Target Application Scenarios

Both of our target application scenarios involve a SaaS web service that uses ACS to manage access to its on-line resources. In the following scenario descriptions, we will use Northwind Traders (NWT) as the emblematic ACS customer, and Fabrikam Flower Shop and Contoso Auto Corp as emblematic NWT customers. Fabrikam Flowers and Contoso Auto Corp have different needs and capabilities when it comes to integration with NWT’s access control architecture. ACS will enable NWT to serve them both.

Northwind Traders

Northwind Traders (NWT) is an ISV currently working on porting their on-premise software offering to a SaaS offering. Their SaaS offering consists of a REST programmatic endpoint and a website. NWT has decided to use ACS to protect their programmatic endpoint. Concretely, this means that a NWT customer application must first acquire a token from ACS before using the NWT REST service.

Fabrikam Flower Shop

Fabrikam Flowers is a micro-company that sells and delivers flowers. They have four employees and no IT department. They have, however, hired a local person to help them with their local network and to build their basic e-commerce website. Fabrikam Flowers has recently realized that they need to more closely track orders. JBM hears about NWT and their SaaS offering and decides to buy. After reading the NWT documentation, the website developer realizes that the integration is very simple.

Contoso Auto Corp

Contoso Auto Corp designs, builds, distributes, and sells automobiles. They have tens of thousands of employees and a sophisticated IT department. Contoso Auto Corp is in the processs of revamping their selling process. As a result, they need to acquire new sales software. NWT’s new SaaS offering happens to meet Contoso Auto Corp’s requirements, so Contoso Auto Corp decides to proceed with a proof of concept with NWT. Contoso Auto Corp requires that the NWT programmatic endpoint can work with an identity that Contoso Auto Corp owns. Since Contoso Auto Corp uses Active Directory, the Contoso Auto Corp application that integrates with NWT must be able to gain access to NWT using a SAML token generated by ADFS V2. Contoso Auto Corp has developers that understand ADFS and SAML technologies. In order for the NWT proof of concept to succeed, Contoso Auto Corp developers will need to quickly integrate NWT into the Contoso Auto Corp application.

ACS Value Propositions

1. By writing a small amount of code in whatever language it wishes to use, NWT can offload to ACS the cost and complexity of integrating with various customer identity models and technologies.

2. NWT’s customers will benefit from ACS documentation, samples and developer community in integrating their applications with NWT – thus further lowering NWT’s support costs for customer on-boarding.

3. By adopting ACS, NWT will gain access to a number of advanced features, including:

a. Role-based access control

b. Simple delegation

c. Increased protection from denial-of-service attacks

4. NWT can take advantage of ACS’s scale-out capacity to meet growth in demand or unexpected spikes in load.

5. With little or no change to its code, NWT can stay abreast of the rapid evolution in access control standards and technologies and benefit from new features and capabilities as they are added to ACS.

Generic ACS Interaction Model

In its most generic form, the interaction model for ACS involves three participants: the Requesting Application (Fabrikam Flowers App or Contoso Auto Corp App), the Relying Party (NWT) and ACS. The core pattern among these participants is as follows:

1. The Requesting Application (Fabrikam Flowers App or Contoso Auto Corp App) submits to ACS a security token containing input claims. This “inbound” token bears evidence—in the form of key material—that it was issued by a party (Fabrikam Flowers or Contoso Auto Corp) that the Relying Party (NWT) trusts.

2. ACS processes these claims according to rules configured by NWT (via the ACS portal and/or management API) and resolves output claims.

3. ACS packages these output claims into a new, ACS-issued security token and returns this token to the Requesting Application. We refer to this as the “outbound” token.

ACS Token-Exchange Endpoints

In the PDC release, ACS will expose two endpoints where requesting applications can obtain an ACS-issued security token.

ACS endpoints are optimized for REST and are designed to make it extremely easy for companies like Fabrikam Flowers to integrate with ACS. Companies like Contoso Auto Corp will also have a straight-forward integration path using our REST with SAML Extension, which will support inbound ADFS V2-generated SAML tokens.

ACS will also use REST to transit outbound tokens to the Requesting Application. Customers will find it a trivial matter to work with the outbound tokens that ACS produces, whether that involves consuming them or transforming them into other formats for downstream processing.

PDC 2009 Integration with other MSFT Identity Technologies

Windows Identity Foundation (WIF) and ADFS V2

At PDC there will be community samples that demonstrate how to use WIF and ADFS V2 with ACS. WIF will be used to acquire a SAML token from ADFS V2 and to extract the claims from an ACS-issued token. Note that extracting claims from an ACS-issued token will require custom extensions to WIF.

The WIF and ADFS teams are currently investigating native support for this type of REST token in the future versions of both WIF and ADFS.

Windows LiveID (WLID)

At PDC there will also be a community sample that demonstrates how to use WLID with ACS.

Post-PDC Integration Scenarios

After PDC, ACS will extend to natively support many different identity providers both on the web (e.g. WLID, Google, Yahoo, Open ID, Facebook) and the enterprise (e.g. Forefront Identity Manager, ADFS V2, Tivoli, CA SiteMinder, Oracle Identity Manager, and other WS-* compliant servers).

Additional Comments

We plan on going live with ACS on or before the PDC conference in November 2009. While we know that the changes to our roadmap will cause some customer pain as well as internal retooling, we are confident that they will also set us on the right footing to have a very successful offering at PDC and beyond.

If you have questions or comments about the changes we are making, please don’t hesitate to let me know.

Over the past few months, several people have asked me how to accept client certificates on a service. The scenario is something like the following:

• A web service owner wants to limit access to the service to authorized clients
• authorized clients identify themselves using a certificate
• the certificate may or may not be issued by a trusted root
• there may be lots and lots of client certificates
• clients and servers use WS-* compliant stack

This discussion was happening enough that I thought it beneficial to have a quick sample to point to. Here’s my approach to the scenario:

The trick is to check the certificate thumbprint in ServiceAuthorizationManager on the Service. This allows the service to trust a large number of certificates from lots of different issuers. You just lookup the certificate in your store (DB, Azure storage, etc.).

This isn’t the only way to tackle the problem, but I think it gets the job done.

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.

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.

This week at Mix I demonstrated a new experimental client API (TokenClient) for interacting with the Access Control Service (ACS). The purpose of this API is to simplify the developer interaction with the ACS Security Token Service. It still uses WS-Trust on the wire, but restricts the WS-Trust options to what I believe to be the bare minimum.

NOTE: this code requires the Geneva Fx (version released at PDC 08) in order to work. The assembly version # is 0.5.1.0.

NOTE NOTE: This code is highly experimental – I’ve written it to demonstrate a core capability of ACS. As a result, it hasn’t been rigorously tested, and I am absolutely certain that there are bugs.

Recalling earlier posts, remember that ACS simply accepts claims and uses access control rules to transform those input claims to output claims. Claims in, Claims out – all the live long day. The client API shown here reflects that simplicity.

ACS receives “claims in” if those claims are wrapped in a token. As a result, the TokenClient type has a method that will package claims into a signed and encrypted token. There are other methods that send that token to ACS, and still other methods that return the ACS issued claims in a couple of different handy formats.

First let’s discuss instantiation. In order to create a token, a TokenClient object needs to be able to sign and encrypt a token. This information is packaged in a TokenClientSettings object. The TokenClient type constructor accepts a TokenClientSettings object as shown below.

TokenClientSettings settings = new TokenClientSettings() {

  LocalIssuerAddress = new Uri("http://localhost/myissuer"),

  LocalIssuerSigningCertificate = new X509Certificate2("sign.pfx", "pwd"),

  Scope = new Uri("http://localhost/myservice"),

  ScopeEncryptingCertificate = new X509Certificate2(“enc.cer", "pwd"),

  SolutionName = "justindemoaccount"

};

TokenClient client = new TokenClient(settings);

Next, let’s instantiate an IEnumerable<Microsoft.IdentityModel.Claims.Claim> object.

Claim[] claims = new Claim[] { new Claim(@"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", 

                                                     "justin@calculatordemo.com") };

This claim value is completely made up. It’s just a value that I’ve decided to use. Similarly, the claim type is fairly arbitrary. I chose UPN out of convenience – you can choose any claim type you like (as long as you set that claim type up in your ACS scope).

Next, let’s send those claims to ACS and see what claims we get back:

IEnumerable<Claim> acsIssuedClaims = client.TransformForClaims(claims);

Next, we can dump these claims to the console:

foreach (Claim claim in acsIssuedClaims) {

if (claim.ClaimType != "http://schemas.microsoft.com/ws/2008/06/identity/claims/confirmationkey")

{

     Console.WriteLine("===================================");

     Console.WriteLine("Claim Value: {0}", claim.Value);

     Console.WriteLine("\tClaim Type: {0}", claim.ClaimType);

     Console.WriteLine("\tClaim Issuer: {0}", claim.Issuer);

     Console.WriteLine("===================================\n");

}

}

Before we compile and run this sample, we need to setup ACS. The steps below roughly approximate what to do:

1) Login to the http://portal.ex.azure.microsoft.com and browse to the ACS management portal

2) Create a new scope (http://localhost/myservice)

3) Setup a new Identity Issuer:

a. Name: SimpleClaimIssuer

b. Uri: (http://localhost/myissuer)

c. Certificate (the public key only version of sign.cer)

4) Setup the encryption preferences:

a. Certificate (the public key verision of enc.cer)

5) Add a rule:

a. Input: UPN justin@calculatordemo.com

b. Output: Action: Read

When you press F5 in the project, you will see the Action claim print to the console. In essence, the TokenClient will have created a token that contains a UPN claim, sent it to ACS for transformation, received the result, decrypted and verified the result, and printed the claims to the console.

A link to download the code is below. Enjoy and please let me know as you find bugs… Again – this code is highly experimental…

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

My co-worker Jenny Lo wrote a good post on how to get started with .NET Services. If you are wondering how to get started this should do the trick.

https://blogs.msdn.com/jennylo/archive/2008/11/04/a-step-by-step-guide-from-creating-a-net-services-solution-to-running-the-multicast-sample.aspx

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.