Udostępnij za pośrednictwem

Access Control rule changes in BizTalk Services R12

  • Artykuł

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:

  1. Every Identity Service account owns a Security Token Service (STS).
  2. An STS is composed of one or more scopes.
  3. A scope contains zero or more access control rules.
  4. 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 https://connect.biztalk.net/services/. When you create a new account (newaccount) in the Identity Service, the messaging service creates a new scope https://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  https://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 https://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).

clip_image001

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

Comments