Justin Smith's Blog

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

justinjsmith — Fri, 06 Nov 2009 00:17:05 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

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

Access Control Service (M7) released today!

justinjsmith — Thu, 05 Nov 2009 23:58:40 GMT

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

It is running on top of Azure (fabric and storage)
We incorporated a new community driven protocol and token format (Web Resource Authorization Protocol (WRAP) and Simple Web Tokens (SWT))
Relying Parties and Requestors can use ACS from any platform that is capable of HMACSHA256 calculations and HTTPs FORM POSTs
It integrates with AD FS v2 (strictly speaking this isn’t a change, but it is definitely worth mentioning
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.

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/

Access Control Service – Roadmap for PDC and Beyond

justinjsmith — Mon, 28 Sep 2009 18:48:46 GMT

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.

Client Certificate Credential Verification

justinjsmith — Fri, 31 Jul 2009 19:36:29 GMT

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.

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.

TokenClient (Mix) introduction

justinjsmith — Wed, 25 Mar 2009 08:53:31 GMT

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

Property Name	Description
LocalIssuerAddress	The value of the SAML issuer for the self-issued token. This address will need to be registered with ACS
LocalIssuerSigningCertificate	The X509Certificate2 object (with private key) that will be used to sign the self-issued token
Scope	The Scope URI that the token will be sent to (in an RST)
ScopeEncryptingCertificate	In cases where an ACS issued token will be decrypted, this certificate is used.
SolutionName	Your solution name. This is needed to direct the RST to the correct address.

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…

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

Setting up a solution in .NET Services

justinjsmith — Sat, 17 Jan 2009 01:35:26 GMT

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

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.

.NET Services - Launch at PDC 08

justinjsmith — Mon, 27 Oct 2008 18:39:03 GMT

Today we announced the CTP release of .NET Services! For quite a while now, I have been working on this project. It's great to see it announced and to have customers use our services. .NET Services consist of three services: the Service Bus, the Workflow Service, and my personal favorite: The Access Control Service.

My focus has almost exclusively been on the Access Control Service, so expect it to be the main topic of this blog for quite a while. The Service Bus, Workflow Service, and the portals use the Access Control Service so I will likely spend some time on those as well.

In a nutshell, the Access Control Service allows you factor access control code into a manageable collection of rules. Combined with Geneva Server and the Geneva Framework, you can do things like map groups to roles, and roles to permissions.

Access Control rule changes in BizTalk Services R12

justinjsmith — Wed, 16 Jul 2008 20:12:32 GMT

Yesterday we released a new version of BizTalk Services (R12). Over the next few weeks I'll be updating my blog with descriptions of the identity related features we added in this release. For now I'd like to describe one of the most obvious changes to the way you create, view, and manage access control rules.

To explain what these modes do, let me first describe the changes we made. Here are a few of the key concepts:

Every Identity Service account owns a Security Token Service (STS).
An STS is composed of one or more scopes.
A scope contains zero or more access control rules.
An STS owner can grant another Identity Service account permission to edit the access control rules in a scope

2-4 are new. The messaging (also called relay) service uses these concepts. It has no Identity Service special privileges. It is using the same core features available to everyone else. The Messaging Service owns an STS and it defines a root scope of http://connect.biztalk.net/services/. When you create a new account (newaccount) in the Identity Service, the messaging service creates a new scope http://connect.biztalk.net/services/newaccount. The Messaging Service then grants (newaccount) the permission to edit access control rules in (and only in) that scope. This new account provisioning is done in a provisioning agent that uses our public API.

Newaccount can also create a scope within that scope (like http://connect.biztalk.net/services/newaccount/newestscope). NewAccount can then grant another IdentityService account permission to edit access control rules within that scope.

The behavior here is functionally similar to what an ISV might want (allow one of their customers to define access control rules for their “chunk” of the service).

It is important to note that the access control rules that belong to the scope http://connect.biztalk.net/services/newaccount are owned by the Messaging Service. NewAccount does not own the rules, it has just been granted permission to edit rules within that scope.

When designing the UI we wanted the experience of editing access control rules in a scope owned by another account to be distinct from the experience of editing access control rules in scopes you own. Our first attempt at drawing this ownership boundary is to set the default UI mode to show only the scopes you own. We called the default mode “Basic”. The mode that provides visibility into scopes owned by other accounts is called “Advanced”. In short, if you want to work with the access control rules in the messaging service scope (or the workflow scope), you can switch the mode to “Advanced” (shown below).

In keeping with the traditions of BizTalk Services, we love feedback – let us know what you think…

BizTalk Services and "Add Service Reference"

justinjsmith — Wed, 09 Apr 2008 00:34:07 GMT

One of the little known features of BizTalk Services is it's support for metadata. There's a sample in the SDK (default path: C:\Program Files\Microsoft BizTalk Services SDK\Samples\Communication\ExploringFeatures\Metadata\MetadataExchange\CS30) that shows you how to listen for incoming metadata requests through the relay. It tracks with the WCF metadata story and is built on WCF extensibility points. In fact, if you open the machine.config file, you will see the policy importers and the WSDL extensions.

The end user experience is quite simple. At some point, you setup the service behavior

<behaviors>
  <serviceBehaviors>
     <!-- Application Behaviors -->
     <behavior name="serviceMetadata">
       <serviceMetadata />
     </behavior>
   </serviceBehaviors>
</behaviors>

Next you define an endpoint - (Notice the binding is the RelayBinding and not the normal metadata binding.)

<endpoint name="MexEndpoint"
          contract="IMetadataExchange"
          binding="relayBinding"
          bindingConfiguration="default" 
          address="mex" />

That's about all that's required to expose metadata.

Consuming it is just as easy. From a new VS project, all you have to do is right click the project and select "Add Service Reference" (VS 2008).

In the next window, enter the service bus URI (like sb://connect.biztalk.net/services/justinjsmith/Echo) and click Go:

When you click OK, the tooling (think svcutil) will generate the proxy code and config for you. In an empty project, literally the only two lines of code you have to write are:

EchoContractClient client = new EchoContractClient();
Console.WriteLine(client.Echo("hi there"));