In an earlier posting, I described, at a high level, the nature and purpose of BizTalk Services. BizTalk Services centre of a new ‘Internet Service Bus’ which Microsoft is currently developing on their WCF (Windows Communication Foundation) framework.
The technical aim of the ISB is to simplify connectivity between services and clients, even if those servers and clients exist behind different firewalls and NAT routers. By connectivity, however, Microsoft is thinking about much more than the basic routing of packets between endpoints. The ISB will provide several enabling services in the cloud in order to support various interaction models and application styles. For example, the current CTP offers a simple, name-based, form of pub/sub interaction that can be used to implement patterns such as multi-cast. Future releases will add workflow capabilities via a hosted WF environment and suitable tooling. This article looks at the Identity Service provided by the current CTP. This is a key ‘cloud’ service that supports secure communication via connectivity services such as Relay, and is central to the use of the ISB.
The Identity Service centres on a Secure Token Service (STS) used in conjunction with a membership and access control web site. The term STS is used here, as elsewhere, to refer to a web service that implements the WS-Trust specification (see http://specs.xmlsoap.org/ws/2005/02/trust/ws-trust.pdf), and which issues and renews claim-based tokens (generally using the SAML specification, though this is not obligatory) in order to enable secure messaging. WS-Trust extends the WS-Security specification. The core interactions supported by an STS are an RST ("Request Secure Token") and the corresponding RSTR ("Request Secure Token Response").
To understand the model, it is important first to discuss the way in which accounts and resources are managed via the web site. You must understand, though, that the following description applies to a very early version of this site, as at October 2007 (Release 9). Things will undoubtedly change, and the information that follows will become out of date. Another caveat is that, at the time of writing, there is little or no detailed documentation about several aspects of the security model. I will describe what I believe to be the case, but there is certainly a risk of inaccuracy. My aim in writing this article to really to enable people to more readily understand the CTP code and get started in evaluating its potential and providing feedback to Microsoft. I can make no guarantees, however, that I have properly or fully understood all the functionality I describe.
IBN (identity.biztalk.net) – The Identity Web Site
To log onto the web site, go to http://labs.biztalk.net/identity.aspx (Live environment) or http://labs-ppe.biztalk.net/identity.aspx (Pre-Production environment). You need to create one or more user accounts. To do this, you must provide a Microsoft Live ID in order to comply with the site's terms and conditions. You can then create as many user accounts as you wish, ensuring that each account has a unique name. Accounts in one environment are not visible in the other environment. Don’t forget to set the RELAYENV environment variable on your local machine to either ‘LIVE’ or ‘PPE’ in accordance with the target environment before running any code.
When hosting services in the cloud, it is important to deal with several multi-tenancy issues, including the ability to partition and isolate groups of accounts that belong, say, to a given organisation. However, this is not supported in the current implementation, which is hardly surprising given that this is such an early version of the code. I would expect to see this functionality introduced at some point in the coming months.
CardSpace Authentication
The web site is CardSpace enabled. CardSpace is a technology included in .NET 3.0 which embodies Kim Cameron's 'Laws of Identity' (see http://www.identityblog.com). It provides a client-side identity selector, a secure store for Information cards and a local lightweight identity provider. The identity selector uses this local identity provider in conjunction with 'self-issued' (personal) Information cards, but communicates with remote identity providers for 'managed' cards. An Information Card is a metadata document that does not carry any personal information, but references an identity provider and defines a claim set. When a user selects an Information Card, CardSpace communicates with the identity provider to authenticate the user and obtain a security token containing an appropriate set of claims. This token can then be submitted to 'relying parties'. A relying party can specify their requirements in terms of card issuers and claim sets via policy statements.
The web site supports CardSpace in two ways. First, Information Cards can be used to authenticate users to the web site as an alternative to using user names and passwords. Second, a user can associate one or more Information Cards with their account. If a user has multiple accounts, they can associate the same Information Card with multiple accounts. The site, therefore, supports many-to-many relationships between Information cards and accounts. Each card has a designated 'default' account. This setting makes no difference to the user experience when logging onto the site, but is important when setting up communication between clients and servers using the CardSpace token provider.
As I said before, there is currently no mechanism that allows partitioning of user accounts to support multi-tenancy scenarios, and hence the web site has no built-in concept of a local administration account to manage a set of accounts. This can be partly mitigated by using CardSpace. For example, a card can be created and associated with each account, and considered to be an 'administration' card. You can also associate a different 'user' card with each account. A 'user' card would typically allow access to a single account, whereas the 'administration' card allows access to many accounts. When a user logs in with the 'administration' card, they are presented with a list of all the accounts with which that card is associated, and allowed to select which account they want to log onto.
Another point to note is that the site currently supports self-issued Information Cards only. This is very restrictive, and something I would also expect to see change for a future commercial release. In real-world applications, I would expect that service providers will often want the ability to specify policy for each of their services in order to restrict access only to users who hold specific types of managed card. This would significantly extend the ability of the Identity Service to broker identities and support communities of service users. As it happens, the current version of CardSpace is very restricted in terms of policy. Specifically, it does not support policies that specify alternative issuers. About 18 months ago, I worked with Microsoft UK on a demonstrator to show how CardSpace (it was called 'InfoCard' at that time, and still at the CTP stage) can be used in conjunction with an identity broker sitting between multiple identity providers and relying parties. This restriction was a real problem for us, although fortunately we found ways to work around it for the purposes of the demonstrator. Hopefully, by the time BizTalk Services ships, we will see general improvements in handling sophisticated policy assertions using CardSpace. Indeed, Kim Cameron has confirmed that this problem is being addressed, hopefully in the next version (see http://www.identityblog.com/?p=777).
Groups, Resources and Operations
Once a user has created an account, they can create groups. Each group contains a list of users and groups. Group names, like user names, must be unique. Users can then define resources and operations, and create rules to govern access to resources as required. A resource is a service or set of services defined by a URI and optional wildcards. For any one user, the resources they manage must all have URIs that comply with a base URI for their own user name. Here is the default resource URI, with wildcard, for an account for UserX on the pre-production environment:
http://connect-ppe.biztalk.net/services/UserX/*
For each resource, the user can create a list of operations. By default, each user account sets up 'Listen' and 'Send' operations for all services. My first assumption was that these operations would be linked to the concept of operations in WSDL, and therefore to the service contract. However, although this can be true, it’s not quite as simple as this.
Operations relate to the issue of security tokens by the Identity Service STS. When a client or server wishes to use the Connectivity Services to in, it must first request a security token from the STS. The token provider used by a client or server performs an RST (Request Security Token), and asks for a claim set. The STS authenticates the client and decides if it can return a token containing the requested claim values.
Microsoft states that the Identity Service STS extends the WS-Trust specification, and it appears that it does this specifically by implementing support for the WS-Authorization specification. I think I am right in saying that this specification currently remains unpublished, and certainly failed to find the specification on the Internet. Using WS-Authorization, a client or server can request ‘action’ claims. The RST specifically asks for a given value for this claim. These values are the names of operations defined in the access control web site. In the current version of the SDK, the values of “Listen” and “Send” are hard-wired into the code and used by default. They do not relate directly to specific service contract operations, but have more general semantics.
The SDK comes with several sample projects, including two versions of the Calculator Service. Both examples show how you can extend the model to authorise access to individual service contract operations (one uses service-level certificates while the other uses transport-level certificates). All that is required is to provide a custom Token Provider to the client, and a corresponding custom Authorization Manager to the server. These are both well-defined WCF components, and it is a straightforward matter to implement the code. The Token Provider requests WS-Authorization ‘action’ claims for individual operations. The STS returns a token based on the operations listed in access rules. When the client later submits this token to the services, the Authorization Manager checks that the claims are expected, and allows runtime access to individual operations.
Access Rules
Armed with a set of defined resources and operations, the user can create access rules. These are simplicity themselves, and relate users and/or groups to operations for given resources. Hence, a rule might allow UserX to request 'Listen' authorisation for a given resource, and UserY to request 'Send' authorisation for the same resource. UserX can start the resource, and UserY can send requests to that resource.
Example Interactions
Let's follow through a typical set of interactions between a service and client. This is only an example, and many variations exist. It is specifically based on the interactions when using the EchoSample solution. Again, this comes with a caveat. It is based on observing interactions on the wire with a protocol analyser, and also some time spent with Reflector looking at the service bus code. This is what I believe is happening, but I can't guarantee 100% accuracy. Please note that I have skipped a lot of the fine detail in terms of certificate usage, checking digital signatures, etc.
· Server
a) UserX starts a service programme on a local machine
b) The service code instantiates the CardSpace Token Provider.
c) The service code invokes the GetUserName() method on the CardSpace Token Provider.
i) The CardSpace Identity Selector is displayed
ii) UserX selects the appropriate self-issued Information card and clicks 'Send'
iii) CardSpace obtains a SAML token representing the self-issued card from the local CardSpace identity provider
iv) The Token Provider performs a SOAP request to the 'issued_for_certificate' service on the identity service web site. In the current code the token is secured using a hard-wired certificate nd the WS-Security specification
v) The identity web site responds by returning the user name of the account with which the Information Card is associated. If the Information card is associated with multiple accounts, the identity site returns the user name of the designated 'default' account.
d) The service code plugs the user name into a URI. The URI uses the 'sb' scheme introduced with the Internet Service Bus.
e) The service code creates a WCF service host over the given service contract and the URI, and then opens the host.
f) The ISB performs an RST (Request Security Token) against the identity service web site. Again, this is a SAOP request. RSTs are standard interactions defined by the WS-Trust specification. The RST requests an 'action' claim for the 'Listen' operation.
g) If UserX is authorised for 'Listen' operations for the resource corresponding to the URI, the RSTR (Request Security Token Response) from the STS contains a security token (I assume this will be a SAML token, but have not checked this out). As far as I can see, this security token is not necessarily used for anything, once received, and I believe the RST/RSTR is just done as an authorisation check.
· Client
a) UserY starts a client programme on a local machine
b) UserY provides the client programme with the user name for UserX
c) The client programme uses the user name to create a URI for the required resource. Again, the URI uses the 'sb' (service bus) scheme.
d) The client programme creates a WCF channel over the service contract and the URI.
e) The Internet Service Bus uses the CardSpace token provider by default, and displays the identity selector.
f) UserY selects an Information card associated with their account
g) The ISB performs an RST (Request Security Token) against the identity service web site. The RST requests an 'action' claim for the 'Send' operation and (I assume) uses the SAML token provided by the local CardSpace identity provider to authenticate to the STS.
h) The RSTR responds with an access security token (again, I will assume this is a SAML token).
i) The ISB establishes a TCP connection with the Relay service (one of Connectivity Services offered by BizTalk Services) using the access security token.
j) The client programme sends a request to the Relay Service. If all goes well, it receives a reply indirectly from the service programme.
Token Providers
I have been emphasising the use of CardSpace all through this section. Indeed, this is the default approach used for token provision when using the SDK's RelayBinding class (the binding used for the Relay service), which is why, for example, the client programme in the EchoSample solution does not need to specify the an instance of the CardSpaceTokenProvider class as a behaviour. However, Release 9 of the CTP SDK contains two other token providers:
· UserNameTokenProvider
As you can guess, this uses a more traditional username/password pair to authenticate a user.
· AutomaticRenewalTokenProvider
This provider is designed to allow clients and servers to operate over long periods of time without interaction from users, except for an initial interaction in order to authenticate. Tokens expire, and hence long running services and clients that use the other token providers may require re-authentication after a period of time. The AutomaticRenewalTokenProvider uses CardSpace authentication initially to obtain a ticket granting ticket (TGT) security token from the STS. This security token can then be used repeatedly to renew the access security token.
Certificates
So far, I have not talked about the use of certificates. Certificates are, of course, an important component of managing security via the Identity Service. Currently, most of the sample code relies on the use of pre-defined certificates which are hard-wired into the SDK code. As I mentioned before, you select the necessary certificates using the RELAYENV environment variable. I don’t know what Microsoft plans for a future commercial release. It may well be that in future we will be able to download and install certificates from the Identity web site in order to enable easy connectivity.
Relying on Microsoft’s certificates would not be acceptable in a great many scenarios, and therefore, not surprisingly, there are alternative approaches. These require rather more complex configuration, and may also involve uploading certificates to the access web site. The web site allows certificates to be uploaded per resource.
The sample code provided by the SDK provides examples of two different approaches. These use two different WCF authentication modes. The first mode is ‘IssuedTokenForCertificate’. In this mode, the service is authenticated to the client by means of a certificate. Because the client communicates indirectly with the service via the Relay service, the certificate must be uploaded to the site and associated with the service resource. The SDK provides a version of the Calculator service that demonstrates this, and also uses the certificate locally to validate the token issuer.
The second mode is ‘IssuedTokenOverTransport’. In this mode, the service is not authenticated to the client. This represents a stronger trust relationship between the client, service and the relay server. In effect, the relay service authenticates itself to the service using a site certificate, just as is done in the SSL model.
One last point to note is that the Relay Service is a good example of federated security. In a federated scenario, a service trusts an external party to authenticate a client, and then grants access to the client based on proof that the client was authenticated by the trusted party. In this model, the identity service manages the authentication. Access tokens are used as proof of authentication.
Conclusions
I have skipped rather lightly over certain aspects of the identity service. This is partly because I have only had a limited time to spend looking at the technology, and partly because I feel I have only glimpsed the rich possibilities that it offers. I warmly recommend playing with the sample code and looking more deeply into the way this all hangs together. The important points to note are that the ISB provides basic authentication and authorisation mechanisms to the Connectivity services without requiring custom coding or complex configuration, but also supports more complex scenarios through the use of custom Token Providers, Authorization Managers and access rules. Coupled with the smart stuff behind the scenes that securely traverses firewalls and NATs with minimal pain, you can begin to see where Microsoft is going with this technology. Because the ISB is built on WCF, it is capable of tremendous flexibility with minimal coding. This really is a very exciting technology.