Results tagged “Cloud Computing”

Speaking at BYOD and API Events

I'll be heading up to Stockholm next week where I'll be presenting on BYOD. I'll be joined by others from StjärnaFyrkant, Ping Identity, PwC, Nokia, Sony, Telia, UnboundID, and my colleagues from Twobo. (I think some of the guys from Axiomatics will be around too.) You can find the full agenda here. My session is entitled "Turning your Organization into a Platform: Securely exposing data to apps running on employees' devices." During my talk, I'll present on how social media, mobile, cloud, and big data are having a "platformification effect" on organizations, forcing them to open up data and processes in new ways. I'll give a few examples of orgs who have done this, including my favorite, Pearson. As organizations undergo this shift, it is important that the APIs which they expose take into account the identity of the user who invokes them. Coupling this w/ information about the app/client, location, device, and other context, organizations can make calculated decisions about whether or not they should return the requested resources or not. In this way, BYOD and COPE are irrelevant. What's relevant is who the user is and what they are allowed to do in a given situation. I explained this in more detail in a whitepaper that you can find on Twobo's site (in English and Swedish). I also blogged about this on a few weeks ago, so check there for a bit more detail. The event is February 21, and it starts at 12:00 w/ lunch. So, come in time to grab a bite and talk about how BYOD is effecting Europe and beyond. Attendance is free, and you can find directions here.

Next month, at Nordic APIs in Stockholm, I'll also be giving a very exciting presentation about some innovative new things that we're doing at Twobo with the Janrain API. During my talk, I'll show how organizations can safely and securely use this service to integrate social media into their Web site as well as to publish back to them using a single API. I'll show how Janrain's service can be used with SiteMinder from CA to ensure that only authorized users gain access to sensitive parts of a Web site. What I'll demo allows Web site operators to uniformly consume anonymous, social and more trusted identities that are unaffected by the use or implementation of any particular upstream social network. I'll also show how Web site operators can combine Janrain's social media aggregation API and our integration with SiteMinder with other third-party tools, like Google Analytics, to use social more effectively. This event will be on March 21 at Jayway's office in downtown Stockholm. We'll be joined by presenters from Dopter, Jayway, Ping Identity, and Radio Sweden. We'll start w/ lunch at 12:00 and go till at least 16:00. (We might be joined by one or two more companies, so we may go till 17:00.) The event is free, and we are almost booked up, so RSVP today! More details on the agenda, speakers, etc. can be found on the Nordic APIs Web site.

[Disclosure: Twobo, my company, has a commercial relationship with Ping Identity, StjärnaFyrkant, UnboundID, Jayway, Dopter, CA, and Axiomatics; it also has an interest in both of these events.]
This fall, I'll be presenting at IDentity.Next on behalf of my company, Twobo Technologies. At this conference, which takes place November 20th and 21st in the Hague, I'll be diving into various scenarios and use cases for the emerging provisioning standard, System for Cross-domain Identity Management (SCIM). This will be a sequel of sorts to the talk I did at the Cloud Identity Summit in July where I gave an intro to the new protocol. If you're planning on attending and want to do your prep work, have a look through this slide deck:

Solving the provisioning problem is one thing we must do to benefit from this new IT delivery model. Next month, I'll be traveling down to Amsterdam to discuss this and other challenges with hundreds of other attendees of the Broadband Cloud Summit that's taking place as a part of this year's Broadband World Forum. From the 16th to 18th of October, I'll be joined by tens of thousands of speakers and delegates from tons of organizations who are seeking to find new ways of using digital identity, mobile computing, and the cloud to capitalize on emerging opportunities that they present to telcos and other service providers. Among these will be UnboundID, a partner of Twobo's, and hundreds of other exhibitors. 

So, if you're going to be in the Netherlands over the next couple of months, drop me a line. I'd love to connect w/ you while there. If you're not, keep an eye out here, on Twobo's blog, and on Twitter w/ the hash tags #BBWF and #idn12. As a speaker at IDentity.Next and an official blogger for the Broadband World Forum, I'll certainly have more to say about these events.

(This blog post was sponsored in part by Informa, organizers of the Broadband World Forum.)
Last Monday, AT&T announced that they have launched a new API platform. As I wrote about on Kin Lane's API Evangelist blog, the PaaS includes various components to help developers quickly build and launch new applications. One of these is an HTML5 SDK that simplifies what mobile Web application developers have to do to securely call the mobile network operator's new cloud services.

The carrier is securing their API with OAuth 2. They support both the authorization code and client credentials grant types defined by that spec. att-oauth2.gifThey also allow users to authenticate to the Authorization Server (AS) w/ a username/password, a MSISDN and a PIN, or by simply being connected to their network. Also, each of the services has a different scope. To get approval to use them, the app developer includes these when redirecting the subscriber to AT&T's AS.

The various authentication mechanisms are interesting, but what's even more intriguing to me is a Sencha Touch plug-in that is included w/ the SDK and how it works in tandem w/ a proxy. The plug-in exposes a JavaScript object model for the new cloud services that works naturally w/ this popular toolkit. Extending Sencha Touch like this allows developers who are already using that framework to quickly integrate the carrier's new services. For others that are not, it allows them to build UIs that look and feel like native apps on various mobile platforms while simultaneously simplifying the use of AT&T's API. To see how, let me explain how the Sencha Service Access Layer (SAL) works w/ the proxy.

att-paas-arch.pngAs shown in the following figure, all requests to the AT&T cloud go through an intermediary. This proxy is hosted by the same developer as the HTML5 app. The first time a user invokes the application, it will call the proxy which will find that it doesn't have an OAuth Access Token (AT) or Refresh Token (RT). For this reason, it will return an error rather than calling the carrier's cloud service. The Sencha plug-in will catch this and pop up an IFRAME displaying AT&T's OAuth AS. (The samples don't display the address, but I would.) The user will authenticate as described above, and the AS will redirect the IFRAME to the callback handler which is hosted on the same server as the proxy. It will exchange the Access Code (AC) provided on the query string for an AT and RT. These will be persisted in a session. Subsequently, when methods are called on the plug-in, a request will be made to the proxy, the session will be used to find the AT, and the proxy will tack it onto the request that it forwards to AT&T.

This new API and its SDK provide an innovative way of using OAuth that simplifies the work that mobile Web application must do. The docs were great, the samples were very helpful, and I quickly figured out how to use the toolkit. I also found it interesting that a helper was used here to aid in securely consuming services from mobile apps as I've talked about doing for other use cases.

If you have questions or thoughts about this or the other blog post I wrote about this new API, please feel free to lave a comment here or drop me a note.

As organizations begin using and deploying cloud applications, some of their services are left on-premises (for various reasons), resulting in a hybrid architecture. In such deployments, the on-prem services sometimes need to be invoked securely from the cloud. When doing so, an STS can be used to broker trust from the cloud into the organization. Unfortunately, the token issued by the IdP when authenticating end users isn't always available to the cloud-based caller due to restrictions/limitations of the cloud platform. In such cases, the on-prem STS can't be given a token asserted by a trusted issuer that it can validate and transform. As a result, the on-prem services do not have all the data needed to make authorization decisions, enforce licensing agreements, etc. One possible solution to this problem is to allow the cloud-based caller to specify in the message sent to the STS certain end-user-related data that should be put in the token that is minted. This will then be passed along to the on-prem services in a token asserted by the local STS. This idea is shown in the following figure:

At first, this may seem odd since the STS is the asserting party and it is being told what to assert. In cases where there is a trusted subsystem in place between the STS and the cloud app, however, it is safe IMO. Consider the alternative where the cloud app doesn't have the original security token. Since the interface of an STS is restricted to security tokens (by design), the client must create one using the identity attributes provided to it by the PaaS environment in which it's running. In other words, if the token asserted by the IdP isn't available, the cloud app has to cook one up. In this case, it is the asserter, resulting in the same sort of situation where it's the authority not the STS. The nice thing about passing the end user data in the message is that the caller needn't create a security token. There are tradeoffs w/ this approach, but there always are ;-)

The WS-Trust specification allows any XML to be included in the RST that the client sends to the STS. Ping Identity has used this extensibility point in the protocol to allow callers to include name/value pairs that PingFederate should include when minting security tokens. As a result, it is very easy using that STS to implement the sort of architecture described above. To do so, you would configure the STS w/ the attribute names that can be passed in the request, stipulate what to do if they are not (fault or do nothing), and include them in the RST. Totally simple.

To make this even simpler though, I extended WIF's RequestSecurityToken and WSTrustRequestSerializer classes to make the client-side programming model natural and easier for .NET developers. Using these, a cloud-based STS client could pass the end user's identity info in the request rather than having to create a security token. The result would look something like this:

private static RequestSecurityTokenResponse RequestSecurityToken(
UserData userData) { // Send a request parameter in the RST sent to the PingFederate // STS. These should be included in the security token that it
// mints and sends back in the RSTR. var factory = GetChannelFactory(); var requestParams = new RequestParameters("ShoeSize",
userData.ShoeSize, "HairColor", userData.HairColor); var rst = new TravisSpencer.IdentityModel.Protocols.
WSTrust.RequestSecurityToken {
RequestParameters = requestParams,
RequestType = WSTrust13Constants.RequestTypes.Issue, AppliesTo = new EndpointAddress(appliesTo), }; RequestSecurityTokenResponse rstr; var channel = factory.CreateChannel() as WSTrustChannel; var token = channel.Issue(rst, out rstr); return rstr; }

If you have questions about this or if you have this sort of problem and would like to talk, please let me know.

Now that I'm w/ Ping Identity in Sweden, it was only a matter of time before I bumped into the guys at Axiomatics. When I was in Stockholm the other day, we had fika and talked about federation, entitlement management, financial services, and the upcoming EIC conference. While we sipped our coffee, we discussed what it would look like to put our products, PingFederate and Axiomatics Policy Server (APS), together to form a best-of-breed solution that provides organizations like financial institutions with the ability to easily get prospects into the customer corridor by leveraging identities that they already have while simultaneously removing authentication and authorization from their line of business (LOB) applications.

Before our bullar were done, we had come up w/ an architecture that used PingFederate's Cloud Identity Connectors to reduce the number of steps prospective retail banking customers have to perform when deciding whether or not to do business with a particular financial institution. Using these, prospects can connect with Facebook, Google, Twitter, or other social networks to easily provide basic information about themselves (e.g., the country they live in). With this, a bank can show the prospect personalized and targeted information such as local contact phone numbers, state- or country-specific terms of service, local market news (e.g., exchange rates for the Krona if in Sweden or USD if in the States), and locations of nearby branches and ATMs. Using existing identities, organizations can provide Web surfers with more relevant information, helping them find what they need to decide to begin doing business with the provider.

In the banking scenario that we were chatting about as well as in many others, security in critical. In such cases, social sign-on, though helpful in reducing friction and increasing conversion rates, cannot provide a high enough level of assurance (LoA) that a person really is who they say they are. To overcome this, after someone signs up for an account, a bank would verify their physical identity and then provide them w/ a new digital identity. Using the new one and not a social network identity, the customer could gain access to higher value assets like online banking. This account would be stored in a directory maintained by the financial institution. Even with this and the support for all the different protocols used by the various social networks, our architecture was simple because PingFederate supports so many types of identity providers. The overall scheme we cooked up is shown in the following sketch:

When a prospect or customer accesses the banking Web site, they are given the opportunity to use a social login or an identity provided by the bank. Regardless, information about the requested page and how the user authenticated is sent to APS in a XACML message which renders a decision about whether or not access should be granted or denied. As a result, if a prospect has authenticated using a social networking account, APS will not allow them to access sensitive area of the Web site; instead it will redirect them back to the login page where they can login using a more trustworthy identity. If APS decides that access should be allowed to the page, which buttons, tabs, bank accounts, and other elements should be render will also be determined using claims asserted by PingFederate.

With an architecture like this, the application doesn't have to understand the numerous federation protocols and security tokens used by the various social networks. It also doesn't have to interface directly with the identity store where customers are kept which could be an LDAP directory, a RDBMS, a mainframe, and/or something else. The LOB application handles identities as claims asserted by PingFederate, giving it one normalized representation of the customer or prospect. Authorization rules that governs access to resources are also maintained outside of the application. Policies can be stored centrally and updated without recompiling or redeploying the application.

After finishing our coffee, we couldn't help ourselves; it seemed so simple, we had to try to implement it. Before I had to catch my train home, we had the basics working. It didn't require any custom coding whatsoever. (The only coding needed was for the online banking application because neither of us had one of those.)

Given that we are both going to be at EIC, we thought we might show it off there. Stay tuned on that. In the meantime, if you have questions or thoughts about this, please drop me a line.
The final day of the Cloud Identity Summit was great. I missed Andrew Nash and Chuck Mortimore unfortunately, but I did get a chance to hear John Shewchuk talk about what he and his colleagues at Microsoft think identity may look like in 2020. In his talk, he listed some requirements to achieve the sort of identity-related scenarios they are envisioning for the next 10 years. Here's a summary:

  1. Support for rich identities
  2. Existence of a multifaceted federated profiles
  3. Flexible authentication that includes new factors (e.g., visual, voice, etc.)
  4. Flexible access control
With these, we may see, Shewchuk said, things like TVs that can recognize that a family is watching and recommend shows that are appropriate and preferred by both the parents and the children. When the kids go to bed, the TV will see that they are gone, and suggest shows that include more mature content.

This sounds very exciting, but this sort of technology has a lot of other applications that are not as exciting to me. The possibility of marketers using this rich identity data and profile information to target our society with tailored messages could radically alter our culture. Me and my colleague, Andy Phenix, talked about this in great depth on the way down the mountain. It was a thought provoking and stimulating conversation that was a great conclusion to the week-long identity dialogue.

Thanks to the sponsors, organizers, and, most of all, to the other attendees that made it such a wonderful time!
Day 2 of the Cloud Identity Summit kicked off w/ Ping Identity's CEO, Andre Durand, discussing the importance of identity and the need for us to come together as a community to discuss it in the context of cloud computing (similarly to what other thought leaders said at RSA). He handed it off to Gunnar Peterson who said that there are four fundamental technologies necessary to enable broad adoption of cloud computing:
  • Security Token Services (STSs),
  • Policy Enforcement Points (PEPs) and Policy Decision Points (PDPs),
  • Gateways, and
  • Monitoring.
I totally agree that STSs are a core component of this new architecture. They will one day be on par w/ DNS, DHCP and other infrastructure services that enterprises need to operate. While this technology helps answer the first fundamental question of who you are, it doesn't address the question that we're actually interesting in knowing the answer to: what are you allowed to do? This is where the PEPs and PDPs come in, and I completely agree that these are critical to the adoption of cloud computing.

Eve Maler picked up on this theme in her talk on User Managed Access (UMA), a protocol for authorization that's being incubated by Kantara. In addition to birthing new standards, this organization, Pamela Dingle explained after Maler's talk, is also a Trust Framework Provider (TFP). This and similar organizations are essentially abstractions around IdPs. The US Government is defining profiles of certain protocols (e.g., Info Card, OpenID, etc.), and stipulating that TFPs must ensure that all IdPs that they vouch for conform to these profiles. (I imagine that attribute contracts are also specified, but I don't recall Dingle saying that.) The output of these TFPs is metadata which is analogous to a Certificate Revocation List (CRL) in PKI. Because the "CRL" can be traced from the TFPs back up to the US Government, RPs can pick and choose IdPs willy nilly knowing that they are all reputable and capable of asserting someone's identity.

This abstraction would have come in handy during Lee Hammond's talk that he did w/ Brian Kissel. In it, Hammond spoke about how his record label is using Janrain's Engage product (formerly RPX) to shield his Web apps from the assortment of protocols supported by the IdPs he relies on. Using Janrain's identity protocol mediation service, music fans are able to seamlessly login once to the Web sites of multiple musicians on his label. During his presentation, Hammond didn't want to give a live demo because Twitter was giving him a fail whale earlier in the day. If his protocol aggregator depended on the TFP instead of the actual IdP (Twitter in this case), it may actually (e.g., if Hammond configured it to do so), fail over to some other comparable IdP.

There were a lot of other great things discussed during the day. If you want to know more, drop me a line. Also, be sure to check back here tomorrow for the final report on what's happening in the cloud identity community. It's exciting stuff!
Today was the first day of the Cloud Identity Summit in Keystone, Colorado. The quality of the workshops and value of the interaction with other industry experts was only outdone by the breathtaking views of the mountains surrounding the conference hall. To give you a small idea of what it was like, here are some highlights from Gerry Gebel's workshop on XACML:

  • Version 3 of the spec will probably be released by the end of this year.
  • The new delegation model makes XACML especially pertinent to SaaS providers.
  • Gerry and Doron Grinstein, the CEO of BiTKOO, did not know of any production installations that use a PEP from one vendor and a PDP from another.
  • There's a new profile looming called the XACML Intellectual Control Profile (IPC) which is being shepherded through OASIS by Boeing.
  • BiTKOO is on the verge of open sourcing a PDP and a PEP. (No details given.)
  • Gerry didn't think the XACML technical committee was interested in defining the transport mechanism used by the different actors in the architecture, and everyone in the room seemed (from what I could sense) that the spec had limited value until they did.
  • Patrick Harding, CTO of Ping Identity, thought that the standardization of the client-side API used in PEPs would help speed adoption as was the case w/ LDAP.
If you're interested in other things that were said, ask in a comment below or let me know. Be sure to keep an eye on my Twitter stream for more updates, and check back tomorrow for day two.

RSA 2010 -- Day 2 Part 2


I attended three sessions this afternoon:  

  • One on cloud computing with a panelist from JPMorgan Chase,
  • One on authentication presented by the CIISP of Bradesco, a Brazilian bank, and
  • One that was a P2P discussion of identity facilitated by a SVP at Bank of America.

All of those are issues that I wrestle with all day long in the industry in which I work, so it was fantastic. Perhaps it's the marketing class I'm in ATM that has attuned my ears to the voice of the customer (VoC) because I heard them loud and clear. This is my interpretation of what they said about those topics.

What the Financial Institutions Said

My Interpretation

Cloud computing is a new name for things we've been doing for a long time.

Be careful and cautious about cloud computing. Scrutinize new cloud-based offerings using our established practices and procedures. Do not get sucked into the hype.

Once data gets out the door, it's gone forever.

You only get one chance. Cloud computing is still too new and unproven. Mistakes are bound to happen, and we can't afford for them to be made by us.

Everything is about risk management.

Be cautious and slow to adopt cloud computing. Let the early adopters go out of business trying to figure it out. Once they have worked out the technical, social, political, and legal kinks, consider it pursuant to our established practices, policies, and procedures.

The biggest risk is loss of reputation; the brand name must be upheld. You can't outsource your reputation.

Loosing the competitive advantage that a distinguishable and trustworthy brand offers is not worth the potential cost savings offered by cloud computing, especially considering that we have already invested in the computing infrastructure that IaaS and cloud computing offers.

Online banking will never be done in the cloud.

Public clouds such as Amazon's are not appropriate places to host online banking solutions. Host them on private or hybrid clouds instead.

Positively identifying legitimate users has been a long hard battle that has forced us to invest tons of money and effort; it has even forced us to do things we didn't want to do (e.g., biometry).

We are in an arms race. If you can help us make it cheaper and more cost effective, we're all ears.

Technology is not enough.

We need technological help in this war, but we will be especially interested if you can also help us with the people- and process-related problems.

Banks, governments/police, and customers must work together.

Your offerings need to be interoperable, UX tested, and compliant with government regulations.

We will constantly be confronted with new security challenges.

We need vendors who we can trust and that will continually provide products that are one step ahead of the fraudsters.

Users adopted biometrics much quicker and with less pushback then we expected.

We value solution providers that are willing to think outside the box; we know from past experience that it pays off.

Our customers love mobile devices.

We expect a whole host of new attacks and problems, so help, advice, and guidance is welcome.

Facebook can't be blown off.

Social networking Web sites represent a real opportunity given the mass adoption, but we're unsure how to capitalize on them.

If you disagree with my interpretations, are aware of other needs that these organizations have, or would like to ask me a question about other things they said about cloud computing, authentication, and digital identity, leave a comment here or let me know. Also, keep an eye on my Twitter stream for more frequent updates from the RSA Conference.

The keynotes this year at RSA were really good. The same guys that spoke last year spoke again this year:

  • Art Coviello, Executive Vice President of EMC Corp. and President of RSA, The Security Division of EMC
  • Scott Charney, Corporate Vice President for Trustworthy Computing, Microsoft Corp.
  • Enrique Salem, President and CEO, Symantec Corp.
The theme repeated over and over and over again in the address of all three was cloud computing. They said that cloud computing represents both a challenge and an opportunity.  As others said yesterday, cloud computing is a chance for the information security industry to redo the IT infrastructure with security at its core.  Even more so than last year, these men stressed the inevitability of cloud computing's adoption and Coviello said its transformative impact on society and business will be like that of the Internet itself.  It wasn't that they were crying uncle; it was more like they were saying if we (the information security community) can't deter them, let's lead them.  To this end, Coviello laid out a strategy for businesses:

  1. Begin moving non-critical services to the cloud
  2. Move critical business applications to the cloud
  3. Build internal clouds
  4. Combine your internal and external cloud infrastructures to create a hybrid cloud
In making that first step, he advised attendees to ensure that SaaS providers are able to address GRC, SLA, policy, identity, and multitenancy needs (the last being the hardest he said).  Through these, the cloud goes from being a nebulous black box to a transparent one:


Which seems like something your business wants to invest in? Startups looking to attract enterprise customers and acquisition should ensure that their offerings are like the later, something that I imagine will be hard for many of them due to a lack of experience working in and with large enterprises.

Coviello closed with a helpful analogy in which he compared cloud computing to the finical system.  Initially, we traded chickens for grain; then we used coins; then we "virtualized" our finances and began using paper money -- an act that places trust on the issuer of the notes; then, we created stocks and bonds to allow us to distribute wealth in a more "elastic" manner.

To make this happen, Charney picked up after him, identity is going to be a fundamental obstacle that we must overcome.  Including wording on his slides, Charney said identity over 25 times in his short address.  Microsoft, all the other speakers, and myself believe that identity is key in the adoption of cloud computing which is the future of all organizations.  To this end, Microsoft just released a public beta of U-Prove, a technology that is built on top of WIF, ADFS, and CardSpace; it provides the least amount of information necessary to conducting one's business online in the cloud.  I've had early access to an alpha of this software and talked to Christian Paquin, one of its creators, last year at RSA.  It is a really compeling technology and the release of the public beta, free use of its crypto, and open source reference code is an important step in overcome the identity barrier.

There's a lot more to see and here today, so I'll post again this evening if I have time.  Keep an eye on my Twitter stream for real-time updates and drop me a line if you have any questions/comments about the keynotes or U-Prove.
As Eugenio Pace mentioned on his blog, the new book A Guide to Claims-Based Identity and Access Control has been released in its entirety online.  The published version will be out some time this spring IINM.  I served as a technical editor on this book, and I certainly recommend it.  It was really great working with Eugenio and the group.

BTW, I got involved in this this project by engaging with Matias Woloski on Twitter. He forwarded my contact info to Eugenio, and the rest is history.  I have had similar experiences due to my use of other social media such as LinkedIn, Facebook, and blogging.  So, if you're not using on-line social networking, I encourage you to begin. It is a fun way to connect with your peers.

RSA Conference -- Day 3


I went to some good sessions yesterday during the third day of the RSA Conference. Three things jumped out at me during the lectures and chats that I had with other delegates:

  1. Building an identity management system is largely a political thing not a technical one (a reoccurring theme)
  2. The cloud isn't all roses and not everyone is looking at it positively
  3. Kantara

The fist is a theme I've been hearing over and over again this week in the various identity-related sessions I've attended. The most obvious mention of it yesterday was in a lecture given by Kevin Kampman and Alice Wang of the Burton Group about role-based access and entitlements management. They said at various points in their presentation that the creation of such a system required a sponsor/advocate in the non-IT side of the business that would fight the political battles. They stressed the importance of this citing various reasons. For example, such a system is needed, after all, for the sole purpose of solving the issues confronting the business, so product will have a huge stake in its capabilities, features, timelines, etc. Balancing these with those of IT and security will be a difficult people-centric journey.

This theme is especially important to security professionals (even for those that identity-management isn't their primary focus) if what Microsoft's John "JG" Chirapurath said later that day is correct that security is rapidly become an identity problem. I don't know for sure (because I'm relatively new to the information security space), but I would imagine that security experts and business people have a relatively hard time getting along; I know IT and business do. So, we have a serious problem: IT and security aren't getting along with business and vice versa, and the successful collaboration of all three is fundamental if organizations are going to meet their objectives without falling prey to the tireless forces of competition and cyber crime. What needs to change for us all to get along better? Humility, commitment to the objectives of the organization by all parties, trust, openness and avoidance of group think, and accountability to name a few.

I talked with more of my fellow attendees yesterday than I did on Monday and Tuesday. Robert McMillian (@bobmcmillan on Twitter) of IDG News Service warned that many vendors are recasting themselves as cloud service providers in hopes of capitalizing on the buzz. I heard this from Jay Chaudhry of Zscaler on Tuesday as well. This isn't a new ploy, but it is one to watch out for of course. I also talked with a gentleman at the VeriSign party I was at last night who's name I didn't catch; he said that he thought cloud computing would have a moderate impact on our society and our businesses but it would not be as profound as some (myself included) are predicting. Who knows how cloud computing will pan out? None of us do, so let's be passionate and excited about technology and its possibilities while simultaneously thinking critically about it. If we all do this, it won't matter how and what cloud computing becomes ;-)

The third big take away from the RSA Conference yesterday for me was a new project called Kantara. This initiative, led by representatives from the OpenID, Information Card, and SAML communities, is seeking to create a digital identity system by conflating the three technologies (i.e., creating an intersection of them as shown in the Venn of Identity). Identity is a really hard problem especially at the Internet-scale and considering what I just mentioned about it being largely a political/people issue. The fact that this project has no barrier for entry indicates to me that the folks behind Kantara get this and understand that the brightest minds must be brought to bear on the problem not just those that work for companies willing to put some cash on the line. This grassroots, bottom-up effort is a tact that I think has a lot of potential to go farther faster, and I support and thank those pioneers who stepped up to the challenge by collaborating on the problem in this way.

If you want to learn more about Kantara, join the mailing list, visit the project's Web site, follow @KantaraNews on Twitter, join the group discussions, watch some videos describing the effort, and become a member. I know I'm going to!

RSA Conference -- Day 2


I learned a lot today during day two of the RSA Conference.  A lot of it was from one-on-one conversations I had with helpful, inspiring gentlemen, but I also learned a lot from the keynotes, panel discussions, and sessions that I attended.  There was too much to go into it all here, but there was one red thread that I heard over and over today.  It was a theme I did not expected to be so dominant and so positive at a conference full of security buffs, C-level execs, and enterprise architects: cloud computing represents a tremendous opportunity that is there for the taking.

I heard it described today by one panelist as the technology of the gods.  The president of RSA, Art Coviello, said in his keynote that cloud computing is bringing our society to a tipping point.  After teetering over it, humankind will be complexly revolutionized.  This sentiment was echoed by Microsoft's Scott Charney.  Symantec's CEO, Enrique Salem, said that the interfaces of some cloud-based software that will be implemented by many different vendors should be standardized in a collaborative, open manner.  During a panel discussion that included some of the world's leading cryptographers (Whitfield Diffie, Martin Hellman, Ronald Rivest, Bruce Schneier, and Adi Shamir), two of the five said that cloud computing is one of the most compelling and interesting areas that is occupying a large part of their time, research, and thoughts. Another panel included Eva Chen, co-founder of TrendMicro, who's been in the security industry for 21 years and said that cloud computing is the most interesting development that she has ever seen. The co-founder of America's Growth Capital investment banking group said that the SaaS market is currently 1.3B in size and is growing by 17% annually according to an IDC study recently published.  Kim Cameron said that the claims-based model would help support the need to identify users both in the cloud and on-prem. 

Some at the conference are voicing their counter views, however.  I've heard some say that they are board with cloud computing as it's just the resurgence of the mainframe.  Others have said that cloud computing coupled with SSO increases a user's attack surfaces tremendously should they happen to get infect by a virus that uses SSO to connect to remote cloud services to perform unbeknownst and undesired operations as them.  Some participants have said during open mic sessions that they would never store their data in the cloud.

In every keynote, panel, and session, cloud computing came up and usually with a positive tone.

MarkLogic in the Cloud


Anyone who knows me or reads this blog regularly can tell you that I'm a totally sold on cloud computing. Recently, I wrote a little about MarkLogic, blogged about IaaS, and I got to thinking: MarkLogic should build an infrastructure service that runs in the Amazon's cloud, scales to Internet levels, and comes with a pay-per-use sales model.

MarkLogic's native XML database is proven, mature, and has been deployed to many companies with household names; however, they aren't cheap. They are competitively priced, but still prohibitively expensive for many companies. The product is licensed by CPU sockets (IIRC), and for a license to run on a one-CPU-socket machine is something like $10,000. That's a lot of zeros for small and medium businesses, especially when relational products that are trusted and better known like MySQL, PostgreSQL, and SQL Server are available at no cost or for pennies on the dollar compared to MarkLogic. Switching from a tried and true relational database to an unknown database product from a less known source sounds really risky to many purse-string holders. If MarkLogic provided its wares as a service that organizations could consume over the Internet on a pay-per-use basis, reluctant companies would be able to utilize MarkLogic's product in an actual program that goes to production, allowing naysayers to see that this alternative has a lot of benefits and that the risks are not as great as they fear.

As the software's creator, who better to create this infrastructure service? They have already used it to build a highly scalable and highly available system called MarkMail that is currently indexing and searching over 7,000 news groups. For example, they know the problems they had with caching and proxying caused by Squid which they used in their early release of the use group indexing service. They solved it, made it scale, and could do the same with a general purpose data storage service, I'm sure.

If you survey the landscape of infrastructure services running in the cloud today, you're choices are few. You have Amazon's SimpleDB, Microsoft's SQL Data Services (eventually), or Google's App Engine datastore. (There might be others, but I don't know of them.) These services all have different and proprietary interfaces. If MarkLogic were to create an alternative to these, its interface would be standard XQuery 1.0. I don't know about you, but I would find a standardized API more appealing from a business and development point of view. From the former perspective, it would assure me that I'm not writing code that is locking me into one vendor's service; from the later, it would allow me to use existing knowledge, libraries, and tools rather than forcing me to use what is provided by the vendors or forcing me to create my own.

Considering some of the recent partnerships that MarkLogic's competitors IBM and Oracle have made with Amazon, I wonder if MarkLogic can afford not to, at the very least, offer a cloud-compatible license and a pricing model that allows for elastic scalability. While this would be a great first step, I'm convinced that a full blown data storage service would be adopted by many companies trying to store large amounts of semi-structured content with Internet-sized demands. If MarkLogic does go after this market, running it in Amazon's cloud rather than someone else's would be beneficial to others running in Amazon's data centers because the transfer rate of data sent within their private network is free. If MarkLogic does not provide a data storage service that is powered by a native XML datastore, supports a standardized query interface, scales to Internet levels, and is highly available, redundant, and performant, then someone else should using an open source alternative. I would be very interested in such a service regardless of who provides it.

I was talking with Darrell Johnsrud the other day about cloud computing, and he shared an insight about Platform as a Service (PaaS) that he had that I think is spot on.  He said that the current services that the different cloud vendors are providing are very generic and cater to a wide array of problem domains.  If you think about Amazon's, Google's, and Microsoft's services, they are very universal.  Broadly speaking, you have data storage (SimpleDB, SQL Services), computational capacity (EC2, GAE, Azure Compute Services), storage (S3, GAE, and Azure Storage Service), queuing (SQS), service bus, workflow, access control (Microsoft's .NET Services), and others.  All of these types of services are needed by many, many systems in various domains.  The capabilities provided by these services are necessary for almost all enterprise caliber solutions. 

That said, however, the platform that you need to support the applications of specific domains are a lot more specialized.  Yes, TV stations and financial institutions need data storage, compute capacity, and storage, but they also need low-level services that are specific to their business arena.  For example, the platforms build to support TV stations and financial institutions will each include a transfer service.  The platform that solves the problems of broadcasters will need to include such a service that transfers digital files (e.g., movie clips, audio files, teleprompter script documents, etc.).  On the other hand, however, the transfer service included in any platform built to meet the needs of banks will move money from one account to another using various means (e.g., wire, ACH, etc.).

As cloud computing takes shape, I believe that companies will come along with specialized platform services like these transfer services to support the applications of specific domains, scale to Internet levels, and have a pay-per-use business model.  Because of this, I think that it is important for practitioners to begin differentiating between these and the lower-level ones provided by cloud vendors.  These base services are what constitutes Infrastructure as a Service (IaaS) and the market-specific ones form for a PaaS offering.  Using this distinction, we can clearly say that services that cater to various domains are (in the cloud computing context) infrastructure services and those that support a wide array of applications tailored to meet the needs of a particular market are platform services.  This specialization, Darrell said, and I agree, will naturally come about over time.

Many companies are just coming to grips with Web 2.0. This "upgrade" has been costly for many organizations in terms of training, realignment to changing market demands, associated hardware and software upgrade requirements, as well as other related impacts. Despite the recent growing pains, however, organizations must begin preparing for the fast approaching third version of the Web. Currently, there are many predictions about what this next major release will entail, but most agree that it will center on cloud computing, mobile devices, increased bandwidth capabilities, and something called the semantic Web. Though the features included in Web 3.0 are important, the actions that businesses take in preparation for its inevitability are just as critical if not more so. As Marshall (2007) of Search Engine Journal claimed, the eventual ability of computer programs to sift through mountains of data and intelligently present pertinent results to their users will require businesses "to have a better understanding of who their target audience is, what they want, and how they think about what they want." The impending incantation of the Web will dramatically affect businesses' spending, strategies, markets, resources, and day to day operations; it will even render some businesses obsolete. If organizations fail to plan or postpone preparations, when the third version of the Web is fully realized, they may be too late to satisfy unmet customer needs, capitalize on emerging trends, and seize new opportunities. 

Many are predicting that we will eventually be surrounded by computer terminals of all sizes and shapes. These portals will grant us access to the Web where we will use it to do many of the same things that we use it for today. We will do some of these things differently, however, and will utilize this new version of the Web to perform currently unthinkable activities. These conduits to the Web might be things like flat screen displays built into tables, car stereos that learn your tastes by connecting to on-line databases and stream the results to your auto, and cameras built into amusement park rides that send photos of riders to email addresses encoded in their admission bracelets. Enabling these types of things will require these "dumb terminals" to connect to some larger machine with sufficient computing power and storage. This model is reminiscent of the mainframe era except that, as Kelly (2007) prophetically pointed out, the reinvented mainframe is a single computer that spans the entire earth. This gargantuan super computer is the result, Kelly said, of connecting so many PCs, handhelds, cell phones, notebooks, and servers. Using these interconnected machines as a single super computer will provide computational capabilities necessary to enable currently unimaginable applications. This radical, sci-fi-sounding notion is referred to by mainstream media and techno-bloggers as cloud computing because the interconnection of computers is done via the Internet which is often described as a cloud.


Though Web 3.0 is only here today in nascent form, this fundamental part of it is already available from an increasing number of service providers including Amazon, Google, GoGrid, IBM, Microsoft, and others. These businesses have created data centers of machines and sell access to them. Most use a per-use payment model where consumers are only billed for the minutes that computers are allocated to them. These armies of worker machines are available to anyone via the Internet. The availability of an almost limitless amount of storage and computing power available on a pay-per-use basis is a phenomenal game changer. As Nelson (2009) suggested, "[u]sing the network as your business platform is really interesting in terms of helping to level the playing field between large and small businesses" (as cited in Chan, p. 18). Startups no longer require capital investments to purchase the computers necessary to compete with larger, established market leaders. By taking advantage of this new paradigm, organizations can be "more effective and efficient" in many aspects compared to those who use established approaches to IT Nelson goes on to say.


Many large established corporations are leery of cloud computing though. With a lot to lose, they are reluctant to accept the associated risks. The advantages are significant; however, the fall from grace is far. As large enterprises seek to remain relevant though, they must take this paradigm shift seriously; they need to begin investing in R&D, training, and pilot projects to overcome the inherent risks associated with cloud computing. They need "to examine [themselves] closely, measuring the risk against when and where cloud computing can be effective," Schwartz suggested (2008, p. 11). Everything, he predicted, "will eventually be available as a cloud service" though not every resource a business has to offer "will be accessed from the cloud" (p. 11). Now is the time for large enterprises to begin determining which of their assets should be accessible from the cloud and which should not. Nelson suggested that this new computing phenomenon will be utilized by "the large enterprises, even with the regulatory concerns in the equation" (as cited in Chan, p. 18). If their acceptance comes too late or not at all, however, smaller companies enabled by the leveling quality of cloud computing could potentially uproot them from their current positions of dominance.


Though these cloud terminals will be pervasive, there will be times when we do not have immediate access to them. Unable to tolerate even the briefest moments of interrupted access, consumers will drive the invention of innovative mobile technologies that will keep them constantly connected. These handheld computers will form a major component of Web 3.0. Devices of unimaginable sizes, shapes, and designs will connect us to the cloud, allowing us to do amazing acts that will further revolutionize our culture and way of life. The transformative impact of Web 1.0 and 2.0, as profound as they were, will be dwarfed, I believe, by the impending tsunami of portable devices that is about to wash over humanity.


By connecting to the cloud, devices will have enhanced capabilities far beyond what they have been able to do thus far. This tie will allow them to combine the Web's data with real life. The information and computational power of the Web will be coupled with the telephones, cameras, camcorders, microphones, GPS receivers, compasses, keyboards, and styluses embed in mobile devices. "Forward-thinking brands have to come to appreciate that more [people] will consume digital content via mobiles" insisted Woods (2008, p. 37). It is imperative, he urged, that companies "start thinking beyond the PC-based internet experience" (p. 36-37). This marriage of mobility and the Net will result, as Kelly said, in an embodiment of the Web. Many "artifacts" in the natural world, he predicted, will have some form of "webness" in them. This combined with a further proliferation of cloud-connected handheld devices will create a 4th dimension of sorts wherein the physical world is combined with the Internet to create a new reality. Two examples of this today are Enkin for Google Android mobile phones and Microsoft Tag.


As Web 3.0 approaches, we will see a dramatic increase in broadband speeds. By many reports, the average American downstream broadband speeds today are less than one megabyte/sec. For example, a company called In-Stat polled 700 high speed Internet customers at the beginning of last year and reported that the average download speed was 3.8 megabits/sec or 0.475 megabytes/sec. Reid (2008) said that the Web's next version will include "connection speeds comfortably in excess of 10" megabytes/sec (p. 14). This one order of magnitude increase will have a revelatory effect on what and how originations are able to conduct their businesses. This speedup will allow companies to transmit large datasets like video and voice as never before. This phenomenon may allow consumers to perform searches verbally via mobile devices, participate in video conferences using portable tablets, or watch HDTV on cell phones.


The last aspect of Web 3.0 (covered in this paper at least) is its ability to be mined by computer programs for information that can be presented to users in a more intelligent manner. This capability will be made possible by the reprogramming of Web sites to include standardized data that can be read and interpreted by machines. Using this additional code, machines will be able to understand not only what the page's content is (as in Web 1.0 and 2.0) but what that content means. This additional level of interpretation is why this aspect of Web 3.0 is referred to as the semantic Web. All search engines to date have used what van Harmelen (2007) refers to as "location finding rather than information retrieval." Current, mainstream search engines find places on the Web and organize them based on "keyword matching, keyword density, and ranking," says Marshall. Given a query, the search engine presents the user with a list of locations that it believes best satisfies the search. It leaves the last and most critical step to the researcher: determining which of these locations actually have the pertinent information being sought.


The semantic Web will change all this. It will dramatically reduce the amount of time we spend performing "location finding" and also change how we search for information. The amount of time we spend researching as we do today will be reduced, and autonomous search agents will perform queries for us, presenting results in various contexts. These programs, Woods predicted, "will make the internet seem more intelligent [by] extracting knowledge that other people put into it in a way that looks intelligent" (2008, p. 35). As Marshall foretold, the result will allow researchers, consumers, and businesses to "more easily find products and services that provide precisely what they need." This will force brands, as Marshall also said, to know exactly who their customers are and what they want.


As we move into this era of increased technological sophistication, businesses will be confronted with immense challenges and opportunities. Thriving will require advanced hi-tech abilities; however, it will also demand that every organization clearly define its mission and vision by continuously answering the following questions posed by Drucker (1967): "What is our business;" who and where is our customer; what is he buying; and what does he consider value (p. 77, 80, 82, 83)? By continuously answering these questions and planning early, businesses will ensure that they remain relevance and successful in the era of Web 3.0.





  • Chan, C. S. (2009). Cloud computing - levelling the land. Enterprise Innovation, 4 (6), 18, Retrieved from Business Source Complete database.
  • Drucker, P. (1967). The effective executive. New York: HaperCollins Publishers.
  • In-Stat (2008, March 5). US consumers eyeing "high speed" broadband more closely. Retrieved February 18, 2009, from
  • Kelly, K. (Speaker). (2007, December). Predicting the next 5,000 days of the web. TED Talks. [Webcast]. Retrieved February 18, 2009, from
  • Marshall, M. (2007). The semantic web and its implications on search marketing. Search Engine Journal. Retrieved February 18, 2009, from
  • Reid, A. (2008). The evolution of the internet. Campaign (UK). 19, 14, Retrieved from Business Source Complete database.
  • Schwartz, E. (2008). The dangers of cloud computing. NetworkWorld Asia, 4 (7), 10-12, Retrieved from Business Source Complete database.
  • Van Harmelen (2007). Knowledge management with the WWW. Retrieved February 18, 2009, from
  • Woods, A. (2008). Is web 3.0 a load of !#*!? No, read on.... Revolution, Retrieved from Business Source Complete database.

Keeping up on Cloud Computing News

There's a lot happening related to cloud computing these days.  To help stay on top of it all, check out Alltop's virtual cloud computing magazine rack.  What other sources of current events are others finding useful?

[Updated Jan. 27, 2009] Since posting this entry, I don't think that I've looked at Alltop's cloud computing "magazine" once.  It's just too far beyond my peripheral vision.  However, I was stuck by the human-compiled list of top bloggers and knew that there was a lot of good info in those blogs.  What to do?  I could copy and paste all them into Google Reader, but that would take a lot of time and then I'd be swamped by all the new info.  Instead, I exported Alltop's list of blogs as an OPML document by appending /opml to the URL of the cloud computing section of their site.  Then, I imported that XML document into PostRank, and configured it to include only the greatest entries from them all.  This reduced the noice a lot.  The final result is one feed that contains the greatest entries on all the blogs that a group of folks over in Hawaii have deemed the very best in cloud computing.  If you would like to subscribe to it, point your feed reader over here.

Now, I just need to find or build a service that will automatically keep Alltop and PostRank in sync.  Anyone know of such a service?
I have been really reluctant to start using Twitter because of what happen when I discovered IRC years ago: I wasted hours and hours chatting with strangers about absolutely nothing.  I was at a Web Innovators meeting the other day, and the speaker, Rick Turoczy, asked who in the room was not using Twitter yet. Of the fifty or so attendees, only one other soul besides me raised their hand.  So, despite the potential waste, I felt compelled to contribute some noise of my own.

A few weeks after signing up, it was starting to seem worthless.  But then, an entrepreneur friend sent me a link to some various Twitter tools, and she got me thinking about the potential utility of this social networking phenomenon.  Inspired by these tools and Kevin Kelly's talk on about what is in store from the Web over the next 5,000 days, I thought I would create a Twitter robot that connected a few different Web services to do something interesting.  The result demonstrates the marvel of cloud and utility computing.

One system that I wanted to use was a new service called Twilio that allowed you automatically make phone calls using a text to speech interface.  This service runs in Amazon's cloud, and allows you to initiate phone calls using a RESTful API.  I decided to use this service from the bot as follows: Any time one of the bot's followers sends it a direct message with their phone number, it would call them.  It would ask them to record a greeting, and then it would update its status with a URL to the recorded greeting.


Before I talk about all the technical details of how I implemented this, let me describe the big picture:

  • Followers of the bot send it a direct message of the form "callme NNN-NNN-NNNN", the N's being the Twitter user's American phone number. (I don't know if Twilio works with non-American numbers.)
  • Twitter sends an email to the address of the bot with some special headers and the direct message in the body of the mail.
  • Procmail is configured to pipe all emails with these Twitter-specific headers to a script.
  • This script initiates a call with Twilio.
  • Twilio makes a phone call and records the message that the recipient leaves.
  • Twilio invokes a callback script and provides a URL to the recording.
  • This callback handler updates the bot's status with this URL, so that followers can click on it and hear the greeting.
This sequence of actions is illustrated in the following diagram:


This figure isn't accurate in a few different respects, but it gives the general idea.

Technical Details

To begin with, I needed to create a new Twitter account for the bot. I chose @tweetybot.  (While creating this new account, I found that Twitter doesn't allow multiple accounts to reuse the same email.  You can work around this using sub-addressing.)  I configured the account such that an email would be sent to [email protected] every time someone sent a direct message.  On the email server, I added the following procmail recipe:

* X-Twitterrecipientname: tweetybot
* X-Twitteremailtype: direct_message
This results in an email being piped into the script with the direct message in the body.  What about the sub-address?  It isn't being used.  I included it, so that I could reuse my PSU email address. However, if I create another bot, I could update the recipe like this (IINM):

ARG = $1

* X-Twitterrecipientname: tweetybot
* X-Twitteremailtype: direct_message
* ARG ?? ^^tweetybot^^

* X-Twitterrecipientname: bot2
* X-Twitteremailtype: direct_message
* ARG ?? ^^bot2^^

By doing this, the lines in blue could be omitted, or they could be left and the sub-addressing-related stuff (in yellow) could be removed.  Either way would work (I think).

Initiating the Call

Once the email is piped into the Python script,, its contents are parsed for the command, callme, and the phone number to call.  If the command isn't found the email is dropped on the floor.  (As I've written it, the bot only handles one command; however, typical bots support multiple commands, so parsing would have to be beefed up in most scenarios.)  If the command is found, a new call is initiated with Twilio using their REST API.  The twilorest library that's imported can be found on the Twilio Web site.  For posterity, you can download the complete script from my site.  The part that initiates the call is this:

d = {
    'Caller' : CALLER_ID,
    'Called' : phoneNumber,
    'Url' : '',
account.request('/%s/Accounts/%s/Calls' % (API_VERSION, ACCOUNT_SID), 'POST', d)

Note that no additional data can be provided when initiating calls.  If the service's interface allowed for this and returned it later when invoking the callback (a common idiom in asynchronous APIs), the user name of the follower who sent the direct message could be included in the eventual status update.

The TwiML Document

As you can see from the snipped above (in yellow), one of the arguments passed to Twilio is a URL.  This refers to an XML document in a markup language called TwiML which contains instructions directing Twilio to record the call that initiated (in blue above) using a Record element like this:

<Record action="" maxLength="55"/>
This element contains an action attribute which informs Twilio of the URL to send the notification to once the phone call has been made, recorded, and transcoded.

The need for this document and the way that the URL for it is provided when initiating a call makes for an awkward API (IMHO).  I say this because Twilio will immediately pull down the XML document after initiating the phone call.  Requiring this data when initiating the call would make interacting with the service less complex and more performant (by avoiding a round-trip).  Apparently, this extra request/response might not be necessary in future versions of the API.

The Callback Script

After Twilio does its work, it sends an HTTP POST request to the callback handler, playback.cgi, provided in the TwiML.  This message will contain a parameter called RecordingUrl, which points to the transcoded MP3 version of the phone call (in yellow below).  Given this, it then uses the Twitter JSON API to update the bot's status (in blue below) to let the world know that someone recorded a greeting and where they can go to listen to it:

my $ua = LWP::UserAgent->new();
my $recording_url = uri_escape(param('RecordingUrl'));
my $request = HTTP::Request->new("POST", "", undef, "status=Someone has recording a greeting. Click here to play it back: $recording_url");

$request->authorization_basic('tweetybot', 'PASSWORD');
One thing to note about this call and the one to Twilio is that the respective credentials are being sent in the clear!  Neither service from what I could find supports HTTPS or a more secure method of authentication.  This is really bad, and limits their applicability and usage.

Also note that the name of the follower who record the message can't be included in the status update, as mentioned above, because Twilio doesn't allow opaque data to be passed in and out with the current API.


In just two hours with no prior understanding of Twitter's API or Twilio's, I was able to create a bot that uses these innovative Web services to respond to an IM, call an arbitrary phone number, record the user's message, transcode the resulting audio clip, and update the bot's status with a URL pointing to the follower's actual voice.  Isn't cloud computing incredible?!  Kevin Kelly was right: We have created just one machine, the Internet, and our phones, laptops, servers, and other devices are just ways to interface with it.  Considering that we can do this today, it's mind boggling to imagine what we'll be able to do in the next 5,000 days.  I can't wait!

(Note: You can get all of the scripts and artifacts from my stash and they are licensed under the GNU GPL v. 2.)

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.