Understanding IAM for Cloud Services: Architecture and Design

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

Read Post

If Not Java, What?

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:

Read Post

Improving the Hype Cycle

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:

Read Post

Prepare for an iOS update in 5… 4… 3…

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:

Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.