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 Bertoccirecently 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 articleThe Evolving Role of the Identity which was recently published in the Architect Journal. In it, he explains that a digital identity has four layers:

Identifier,

Credentials,

Main profile, and

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:

Does this mean that the two standards will continue to compete?

Will IBM support WS-Eventing in its products instead of or in addition to
WS-Notification?

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!