November 2008 Archives

I went to a training last week up at Microsoft on Azure. After chatting with a few of my colleagues after returning, however, I realized that I didn't understand the Access Control Service portion of it well enough to explain it to others. For this reason, I watched Justin Smith's screencast from PDC in which he drills down into the architecture, anatomy, and interaction pattern of the service and its consumers. This talk is very similar to the one he gave up in Redmond last week at the training that I attended. In the video, he says that "The service's sole role in life is to issues tokens. It receives claims, transforms those claims, and then packages them up in tokens and sends them back. That's all it does. Real simple. Claims in; transform; claims out. It's a claims transform." After watching this video and attending the training last week, I can say with confidence that the Access Control Service is

  • Not intended to be an identity provider;
  • Doesn't require a service registry in order to provide authentication and authorization for services;
  • Can be used independently of and without having to take a dependency on the ISB, Workflow Service, and other Azure-related offerings; and
  • The Access Control Service is a multi-tenant Resource Security Token Service (R-STS).

This video was very helpful in explaining the common interaction pattern that clients exhibit when communicating with the Access Control Service. I've annotated that one of Justin's slide in the following figure:

To interact with this service, the .NET Services SDK comes with a couple of DLLs dubbed the Geneva framework that make this communication easier. They hide the WS-Trust 1.3 gunk (like dealing with RSTs, RSTRs, etc.). They also include an HTTP module that makes it easier to save tokens in cookies and whatnot when doing ASP.NET development. You can also interact with the STS using any other WS-Trust-1.3-complaint stacks such as WCF (via its wsHttpFederationBinding) among others.

As Vittorio Bertocci recently said at Tech Ed, a claims transformer or R-STS running in the cloud "provides a natural point of trust brokering with customers and partners along with a natural point of authorisation [sic], evaluation and enforcement." I couldn't agree more and believe that the Access Control Service and competing, hosted STSs will be tapped more and more as businesses are forced to solve the complex problem of federated identity.

The other night, I logged into the Azure services portal to add a certificate to my solution, so that I could run one of the labs that used that credential type to authenticate to the Access Control Service. As you can see from the screenshot below, a Verification Code was needed to upload the certificate.

To create this, the lab manual instructed me to export the private portion of the certificate that I intended to use. After doing so, I was further instructed to input this private key portion of the certificate into a tool called RegCert.exe. The output of this was the necessary verification code.

The fact that I had to perform this task using the private portion of the cert really troubled me. The next day, I talked to Justin Smith of Microsoft about what the code was, the tool, and the process overall. He explained to me that the code was needed because of an underlying premise that guided the design of Access Control Service. In it, an identifier representing a user (e.g., a hotmail email address) is separate from the credential used to authenticate them (e.g., a cert). Because of this, there needs to be some way to marry the credential with the identifier. In the case of the certificate, this is done by hashing the private key, uploading the cert, and providing the hash.

I don't understand how this digest of the private half of the cert allows Microsoft to tie the public half to my Live ID though. However, these different aspects of a digital identity were clarified for me after reading Fernando Gebara Filho's recent article The Evolving Role of the Identity which was recently published in the Architect Journal. In it, he explains that a digital identity has four layers:

   

  1. Identifier,
  2. Credentials,
  3. Main profile, and
  4. Context-based profile

   

I can't say I fully understand the second and third, but examples of the first and second would be my hotmail email address and the certificate that I was trying to upload, respectively. He illustrated these different aspects of a digital identity with the following figure:

   

After playing around with the portal and labs a bit, reading this article, and talking with Justin Smith, I understand the Access Control Service enough to use it for toy applications, but not enough to launch a mission critical application. I feel very uncomfortable having to upload anything to Microsoft that is the product of a private key. I'm sure I'm not the only one that feels this way, and I wouldn't be surprised if a credential is tied to an identifier in a way that does not require the byproduct of private information by the time the Access Control Service RTMs.

In a lecture this afternoon presented by Microsoft Technical Fellow, John Shewchuk, on .NET Services, he said that the eventing protocol supported by the forth coming, cloud-based Internet Service Bus (ISB) would conform to a recognized standard.  When I inquired as to which specification was being implemented, he said that it was WS-Eventing.  I was surprised, thinking that it would be the converged protocol, WS-EventNotification (PDF), which was supposedly underway.  He explained to me that that effort was abandoned.  This was confirmed in a report I found from the EPTS Event Processing Symposium held in September where Chris Ferris of IBM said that the joint effort to merge the two competing standards had ended.

My questions after hearing this are these:

  1. Does this mean that the two standards will continue to compete?
  2. Will IBM support WS-Eventing in its products instead of or in addition to WS-Notification?
  3. Why was the convergence effort abandoned?

Eventing in a service bus, especially one of the Internet persuasion, is a major component.  Integrating on premises services with those running in the cloud via the ISB will require that they understand the eventing protocol of the bus.  This isn't a problem for WCF services, just switch to the *Relay*Binding and you're good to go.  But, what about existing non-WCF clients and services that want to get on the bus?  They will have to understand WS-Eventing to send/receive notifications.  This will mean that all applications using WS-Notification will have to be updated to or excluded from sending/receiving notifications via this new ISB.  This is a big deal since many Java-based and IBM-based services are using WS-Notification not WS-Eventing.       

Today I moved my site to a new hosting company, DreamHost, that provides tons more features and works better with MovableType for about the same price. If you notice any problems with the site, please do me a favor and add a comment to this post. TIA!