Recently in Cloud Computing Category

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.)

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.

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.