Research

This post will discuss the architecture and deployment models for identity and access management for cloud services. This is obviously complex – we are covering three different cloud service models (SaaS, PaaS, & IaaS); in three different deployment options (public, private, & hybrid); with a variety of communication protocols to address authentication, authorization, and provisioning. The Cloud Security Alliance has cataloged many different identity ‘standards’, but the fact that we have dozens of standards to choose from illustrates how unresolved this whole field is. Worse, each cloud provider’s standards support is likely to vary (incompatibly) from others in the field – so you will likely need custom code to connect and share identity information. The point is that discussion of IAM ‘standards’ is often a starting point for companies considering cloud identity. But standards alone should not drive architecture – projects are much better driven by use cases and risk. Our goal is to define an overall architecture which fits your organization, and apply appropriate communication standards after that. To help disentangle design from implementation standards, we will introduce design patters to describe the architecture. A design pattern is a universal model that both abstracts and simplifies the structure from underlying environmental complexities. For each use case we will describe a design pattern that address the core challenges of propagating identity information across multiple services. Then we will discuss how IAM technology standards fit within those models. As previously discussed, there are three core cloud IAM use cases: Single Sign-on (SSO), Provisioning, and Attribute Exchange. Delivering on these use cases requires a number of architectural decisions and workarounds for various issues. SSO Architecture and Design: Learning from the Pin Factory One man draws out the wire, another straights it, a third cuts it, a fourth points it, a fifth grinds it at the top for receiving the head: to make the head requires two or three distinct operations: to put it on is a particular business, to whiten the pins is another … and the important business of making a pin is, in this manner, divided into about eighteen distinct operations, which in some manufactories are all performed by distinct hands, though in others the same man will sometime perform two or three of them.”- Adam Smith, 1776 SSO is often implemented using a ‘federation’ model, under which each user’s identity and associated attributes are stored across multiple distinct identity management systems. Which identity management repository within the larger federated group determines whether to validate a user is determined dynamically at request time. Federated identity is tailor-made for the cloud because it cleanly separates responsibilities between the enterprise and the cloud provider. As in Adam Smith’s pin factory, each participant can specialize in the areas they are best able handle, and the identity protocol establishes the mode of exchange between participants. SAML has been the dominant standard in this area, used by enterprises and cloud providers to coordinate SSO. SSO architectures implement one or more Identity Providers (IDPs) which act as authoritative sources for account information. The IDP is generally on the enterprise side, but may also be kept in a separate external IDP cloud. While SAML is the runtime identity protocol for SSO exchanges, the IDP is the linkage point between the service provider (the external application) and the provisioning services which manage the accounts (typically the HR database). The Relying Party (RP) is generally implemented on the cloud provider side; its task is to consume and verify identity assertions and ensure proper access rights to the cloud application. The agreement point between the IDP and the RP defines the identity protocol, how it is initiated (from enterprise the and/or cloud provider side), the schema, which attributes are sent, and any additional details. Federated Identity enables the enterprise, as the party with the freshest and most accurate user information, to control and manage accounts. The cloud provider controls the application side, and can consume and use assertions from the enterprise without the burden of user management. Federation enables Single Sign On for an open, interactive application architecture. The technologies that deliver these services place a premium on uptime (measured in “multiple 9s”) and robust performance because of the importance of timely and accurate information from trusted identity source. Given the heavily reliance of cloud services on high-bandwidth low-latency network access, integration with browsers and clients is necessary. Any standard used for federation must be resilient in the face of privacy and integrity attacks, at both browser and protocol layers. Provisioning Architecture and Design: Process Automation Provisioning systems are architected very differently than the SSO/federated systems discussed above. Provisioning is less about architecture and more about process, with a focus on how and when systems communicate. Provisioning systems don’t need real-time synchronization – they often run in batch mode, perhaps hourly or even daily. Provisioning systems are used as back-office support applications, so design requirements center around integration – largely having to do with the byzantine protocols necessary to communicate with directories and vendor packages. The good news in terms of security is that these services are less exposed than other systems, requiring neither browser integration nor direct exposure to users. Provisioning processes such as ‘onboarding’ new users, updating accounts, and managing users, are highly automated. The back-end processes to update and synchronize data are critical in traditional on-premise IAM systems, to ensure users don’t unwarranted access to data, and that former employees do not retain system access rights. Extending these functions beyond the corporate IT perimeter is inherently difficult. Like football referees, these systems are only visible to users when they fail. The unique aspect of provisioning cloud applications is its focus on process automation across a least two companies – the enterprise and the cloud provider. We don’t hear many success stories of process automation across multiple companies. Fortunately the handoff of accounts to the cloud provider is relatively simple. There are tree key architecture decisions for provisioning systems, but in the end they all come down to

You have probably noticed some security issues with Java lately. Some vendors – including Apple – are blocking Java in order to close known and unforeseen security problems. And the claim that open source Java frameworks pose a business risk. But through this latest flame war, I have not seen an answer to the basic question: If not Java, what? If you’re going to get Java out of the enterprise to address a security risk and replace it with something else, what would you select? Do we really have evidence that platforms like Ruby, JSON, or Node.js are more secure? Clojure and Scala rely on a JVM and the same frameworks as Java, so they cannot be more secure than the shared JVM. And remember, Java also does a few things very well, which is why it has become so popular over the last 15 years. It has a very good object model. Cross-platform compatibility. Easy to learn syntax. Extensible. Tons of tools. Easy integration. All reasons why I think we have proven C++ and C# are not replacements. I really don’t have an answer for this question. But I think I can say, in the same way that we can’t go back and rewrite all insecure code because there is is not enough time or money to do it, we are not going to throw Java out because it’s insecure. We can make a decision to block it from the browser, but that does not address the myriad ways Java is used in the enterprise. In fact I don’t even see an alternative that would enable us to begin migrating off. Share:

Gartner’s Hype Cycle is one of my favorite market models. It very succinctly describes the ridiculous way PR and other external hype factors make more of a technology than it really is. When many of us show up at the RSA Conference at the end of the month, we will get our best view of the Hype Cycle in action. Most of the stuff very hyped at the show tends to be (roughly) 12 to 18 months from hitting, if it ever does. But as with any industry research, where something lands in the Hype Cycle is open to interpretation and opinion. It’s as squishy as can be – there are no real attributes that can pinpoint where in the hype cycle any technology fits. These factors may exist, but the Big G certainly doesn’t talk about them. And when I see someone saying an over-hyped technology like Big Data has hit the “trough of disillusionment”, I scratch my head. Gartner Inc. said that Big Data has fallen into a “trough of disillusionment,” due to its complexity. The research firm said current obstacles to adoption could be eliminated, though, as Big Data tools such as Hadoop are integrated into mainstream analytic applications. You can’t really disagree with that statement, but I’d still say Big Data is closer to the peak of inflated expectations than to the trough. It’s not like a zillion companies have tried and failed at their Big Data deployments. These folks are still trying to figure out what Hadoop and MapReduce are. This kind of pronouncement is meant to push the market along, facilitate the integration that needs to happen over time to provide more demonstrable and sustainable value to customers. But there is still something missing from this kind of analysis. It would be very helpful to overlay some kind of growth and/or market size numbers onto the Hype Cycle. So when a technology is climbing the cycle, market size is relatively small but growth is off the chart. As it descends into the trough the number of customers grows, but market growth slows as companies struggle to effectively institutionalize the technology. And then as it exits the trough into the plateau of productivity, revenues start to grow again significantly but at a more predictable rate. But public revenue and growth metrics for private companies are about as much hype as these technologies. But that’s the missing piece (IMO) to really understand where these markets are in their development. Or am I still hammered from yesterday’s Super Bowl festivities and talking nonsense? Photo credit: “Hype” originally uploaded by nouspique Share:

Evad3rs releases an iOS 6.1 jailbreak for all devices. Update: According to @drscjmm this will not work when a passcode is set, which means we are still in pretty good shape from a security standpoint. Untethered, which means you still need to plug the device into a computer, but the jailbreak lasts across reboots (this is not remotely executable at this time). This means all iOS devices are exposed to hands-on forensics, even with a passcode. Data protection still needs to be broken, but an attacker can jailbreak and install a back door to sniff your password if they have physical control of the device for long enough. if you lose your phone and recover it, wipe it and restore from a known unjailbroken backup. From the jailbreak notes: Please disable the lock passcode of your iOS device before using evasi0n. It can cause issues. I can’t test right now, but will be interesting if a passcode prevents the jailbreak, or is sometimes just an obstacle. Please leave comments if you know or find out. Update: As we said above, a passcode appears to block this jailbreak, which is good. (Hat tip to The Verge for the link). Share: