# Architecting a Cloud-Scale Identity Fabric

| Posted by Eric Olden 0 Followers on Jun 29, 2011. Estimated reading time: 25 minutes |

This article first appeared in Computer magazine and is brought to you by InfoQ & IEEE Computer Society.

The cloud has quickly become one of the most disruptive forces in recent IT memory. Offering greater reliability, improved flexibility, lower costs, and simpler deployment, the cloud has undeniable potential to benefit all users and businesses. Yet, for all of its promise, the cloud is relatively young. Many enterprises still express concern about adopt­ing the cloud full-scale for critical workloads. The most cited reason for not moving to the cloud is concern about security. In particular, managing user identity and access in the cloud is a tough problem to solve and a big security concern for organizations.

Identity management in the cloud is especially diffi­cult because of the cross-cutting nature of identity and its impact across architectural and organizational do­mains. Many businesses fear that using the cloud exposes them to possible attacks and data breaches. Additionally, many companies are not equipped to manage identities at enterprise-scale and in the cloud because they lack flexible identity management that encompasses both domains.

Identity management must evolve for the cloud to become a trusted computing platform. A revolutionary approach to identity management - a federated identity fabric - spans enterprise and cloud boundaries.

## Cloud Computing: Raising the Scalability Bar

Cloud computing provides convenient, on-demand net­work access to a shared pool of configurable computing resources - networks, servers, storage, applications, and services - that can be rapidly provisioned and released with minimal management effort or service provider interaction (see this link ). It offers organizations a way to increase capacity or add capabilities instantaneously without investing in new infrastructure, training new personnel, or licensing new software.

Cloud computing encompasses any subscription-based service that, in real time over the Internet, extends IT’s existing capabilities[1]. Public clouds generally refer to software-as-a-service (SaaS) apps like those provided by Salesforce.com and infrastructure-as-a-service (IaaS) platforms like Amazon Web Services. Private clouds are apps or platforms dedicated to a specific organization and deployed on-premises, usually behind the firewall.

### Performance scalability

When they consider scalability, many people immedi­ately think about how a system will handle large volumes of transactions, floating-point operations per second, and so on. A key characteristic of the cloud is its ability to offer elastic scalability by easily increasing or decreasing compute power to meet changing demand. For instance, scaling up an application using a larger virtual machine (VM) on Amazon Elastic Compute Cloud (EC2) can be a quick fix when large-scale computing power is needed right away. Taking this concept further, new cloud apps are architected to scale out linearly with an N+1 architec­ture to support almost unlimited expansion.

By being broadly available to developers and delivering impressive results, cloud computing has experienced re­markable growth. For instance, Force.com - the Salesforce.com cloud platform - now processes more than 10 bil­lion transactions per quarter, more than half of which are through its API (see this link), and Twitter handles more than 3 billion requests daily on its APIs[2]. Further, the In­ternet is expected to grow significantly in the near future: AT&T expects a 50× increase in Internet traffic by 2015[3].

### Integration and management scalability

A less obvious challenge with scale relates to the speed at which an organization can deploy, integrate, and administer a system over time. As the system incurs friction - in an administrative effort, for instance - this creates a drag on system scalability, particularly with respect to identity management. If infrastructure is defined as common hardware, software, and network­ing services leveraged across the enterprise to deliver IT capabilities, identity management infrastructure includes directory services, identity and access management ser­vices, network proxies, and authentication systems used enterprise-wide. Today, many enterprises are struggling to build an identity infrastructure that can work with the cloud architecture and scale in an elegant, cloud-like way.

In order to scale to meet the cloud’s architectural and growth demands, system architects must focus attention on optimizing the management and integration of identi­ties. Identity management is a key bottleneck to cloud adoption for many enterprises. Architects understand that they must look beyond the basic performance aspect of cloud scalability and devise a strategy to scale the manage­ment and integration of identities as well.

## A Cloud-Scale Identity Fabric

Various technologies, standards, and use cases enable the portability of identity information across otherwise autonomous security domains, letting users of one domain securely access data or systems of another seamlessly, without redundant user administration. Federated identity thus “weaves together” multiple elements and domains, much like a fabric.

In the past, companies stored network identities in directories and databases. With the Internet’s growth and the emergence of cloud apps, they recognized a need to manage identities outside the traditional network. Today, network administrators must manage multiple accounts for enterprise and new cloud apps. This duplication of effort has added to the workload and introduced new security concerns resulting from the many user identities and pass­words that administrators must manage. Collaboration with external partners and contractors has also required companies to open their network borders to outsiders.

With so much IP and data at stake, enterprises must seamlessly adopt identity management to link to the cloud. To achieve a successful identity management solution for the cloud, the industry must ensure that identity meets the cloud’s unique architectural needs; view identity as a fabric that integrates, abstracts, and extends; and deliver identity as an IaaS in the same manner as the cloud platforms it is supporting.

## Identity Must Meet the Cloud’s Needs

Five areas of the identity stack must evolve to realize a cloud-scale identity fabric: access control and autho­rization; authentication, federation, and single sign-on (SSO); user account management and provisioning; auditing and compliance; and cloud platform architectural requirements.

### Access control and authorization

Managing access control to premises-based and cloud apps is a complex undertaking. In the cloud, outside the firewall, perimeter controls cannot be relied upon to con­trol even binary access. Today, many users are outside the private network and access SaaS apps over the Internet with no need to go through the company network. Autho­rization, therefore, must evolve to a distributed model to support users outside the network firewall.

The authorization in depth concept captures the vary­ing granularity of authorization policies across three levels. Level 1 is a coarse-grained access control policy that governs users’ access to an application or resource. Level 2 is more fine-grained, controlling access to the data level - typically the URL. Level 3 is the most fine-grained level, controlling access to functions or views, sometimes referred to as “entitlements.” Any scalable authorization model must reflect the need to address multiple degrees of granularity or depth. Tying this back to scalability - the greater the granularity, the greater the volume of authori­zation transactions. Another key to scaling access control is grouping access. The earliest forms of access control on the mainframe were based on manually maintained access control lists (ACLs). ACLs initially worked well because few people used the mainframe, but as user bases grew, they became un­wieldy, leading to the use of groups. Group access control scaled well but still required manually managing group memberships. This led to dynamic group management using rules to determine membership and therefore access. Today, organizations use role-based access control (RBAC) instead of groups to reflect the enterprise’s member­ship and attribute-based access control (ABAC) to handle dynamic permissions. In the cloud, these attributes and role memberships are decoupled from the operating system and can be distributed across systems via federation.

Authorization can be scaled by using a distributed, federated model. By breaking the authorization pro­cess down into its core policy elements - management, decision, and enforcement - it is possible to federate authorization across technical and organizational do­mains. Policy management points, policy decision points, and policy enforcement points must run in distributed locations, especially across the cloud.

Identity decision points provide identity data for autho­rization rule evaluation and can utilize Security Assertion Markup Language (SAML) assertions or HTTP headers today and OAuth 2.0 in the future. For example, OAuth leverages a delegated trust model to realize the benefits of abstracting user identity data from user credentials and supports tokenization of authorization. It does require an OAuth-aware architecture of entitlements enforcement. Regardless of the technology used, these authorization decisions must happen quickly and support high volumes of traffic.

### Authentication, federation, and SSO

The federation concept is familiar inside the firewall, perhaps best exemplified by the ubiquitous Microsoft Windows domain model. Enterprises can link multiple Windows domains by defining the trust model between different organizations within the firewall and allowing authentication to be delegated to the “local” domain and trusted by a remote domain using Kerberos, making login transparent to the end user.

Modern federation takes this model beyond the pro­prietary Microsoft approach to make seamless SSO work across the Internet using SAML, an XML-based open stan­dard for exchanging authentication and authorization data between security domains - that is, between an identity provider and a service provider - instead of Kerberos.

The problem with federation and SSO is that, after more than a decade, SAML adoption has not risen above 10 percent of enterprise apps - apparently due to the exces­sive costs of infrastructure software. There simply is not enough return on investment for most service providers to implement, expand, and manage a complex federation network. The industry must therefore go beyond SAML and focus on the core HTTP authentication standard. It requires no change to the target app and no coordination between users and the application. HTTP is the gold stan­dard in authentication, with nearly 100 percent of Web apps supporting it.

### User account management and provisioning

Today’s apps, even those that are federated, need a local account for user identity management. The challenge is managing data about users, especially routine changes like password resets and account registrations. With cloud-enabling user management, every app performs user management differently and usually does it internal to the application; user management APIs are neither con­sistent nor standardized.

Ideally, developers will use the SAML equivalent for provisioning, the Service Provisioning Markup Language (SPML), but there are only a handful of real-world SPML implementations. Without federated provisioning APIs to enable automated synching of local accounts, SAML adoption will remain limited. There is also a lack of sup­port for integrating SAML attributes for personalization, session context, or just-in-time provisioning. The absence of universal user schemas for directories makes building general-purpose management tools difficult.

### Auditing and compliance

A key challenge in auditing in the cloud is overcoming the lack of visibility into user access of SaaS apps. Using the public Internet rather than connecting to a company network puts users beyond the scope of network monitor­ing tools.

Unlike most enterprise networks, the cloud is globally accessible. However, regulatory compliance require­ments vary by jurisdiction and are complex and often contradictory. The industry needs a framework to meet global jurisdictional challenges. Identity is central to such a framework because many regulations center on user privacy and access.

### Cloud platform architectural requirements

The cloud has brought with it new architectures and platforms that service providers have yet to make identity-aware. Specifically, many cloud service providers offer storage- or database-as-a-service via hosted hypervi­sors like KVM or those from VMware and Xen, but such IaaSs currently lack identity and access management as a service.

With their high utilization rates, virtualized platforms cannot handle the overhead associated with precloud Web access management (WAM) use of webserver plug-ins and agents. The tight coupling of WAM with plug-ins has proven to be brittle, and the “burstable,” elastic nature of virtualized cloud platforms makes the plug-in model infeasible. The industry requires a proxy-based approach that does not place load on the virtualized Web and ap­plication servers.

In the case of SaaS apps, the identity integration challenge of enforcing access control and supporting audits stems from multitenancy and the fact that the SaaS provider owns and operates the underlying infrastructure, making it impossible to install dedicated agents or plug-ins for each application instance. Also, with most SaaS apps, collecting audit logs is problematic because they are often comingled with other tenant data. In some cases, the audit details are insufficient for answering key forensic ques­tions. What is needed is a loosely coupled, noninvasive identity management platform that can enforce policy upstream from the SaaS apps themselves.

## Identity Must Integrate, Extend, and Abstract

Two core aspects of a cloud-scale identity fabric are a one-to-many integration model and the extension of ben­efits via the network effect. There is also a need to abstract identity through externalization and the ubiquitous adop­tion of open standards.

### Identity integration

Integrating identity infrastructure and apps requires evolving to a hub-and-spoke model. Today, each app requires a different user account. However, building fed­erated identity connections on a one-to-one basis does not scale. The only way to scale is to move to a one-to-many model that includes the number of user identities in each application.

The problem can be broken down mathematically. As Figure 1a shows, the one-to-one model of a user having individual credentials in an app can be represented as

number of credentials = (number of users × number of apps).

An organization’s integration of apps can be represented as

number of connections = (company × number of integrated apps).

When graphed, these equations scale linearly, mean­ing that for each new connection made or app deployed there is a direct corresponding increase in the amount of credentials or integration work required. Increasing the number of users and the number of apps simultaneously results in exponential growth.

Figure 1. Integrating identity infrastructure and apps requires evolving from (a) a one-to-one model, in which number of credentials = (number of users × number of apps), to (b) a one-to-many model, in which number of credentials = (number of users + number of apps).

For example, consider an enterprise with 10,000 users (customers, employees, and partners) that access 15 apps. In a one-to-one model, this requires 150,000 credentials (passwords). Resetting each credential once a year via a $30 help desk call would entail$4.5 million annually in management expense. Assuming licensing, deployment, integration, and maintenance costs of $50,000 per connec­tion for the same 15 apps, the integration expense would be$750,000.

While the one-to-one model may work on a small scale, it is not sustainable. Most complex systems that start with a one-to-one architecture evolve to a more scalable one-to-many alternative. For example, stock markets have exchanges and clearing houses that connect millions of users and transactions using a hub-and-spoke model; likewise, travel reservation systems like Expedia provide a one-to-many model to connect travelers with multiple airlines.

To scale the number of connections and limit the prolif­eration of credentials in a federated identity, cloud service providers must likewise move to a one-to-many model. They should not integrate directly with apps in the cloud for SSO and access, creating redundant accounts and credentials, but instead federate with a fabric pre-integrated with multiple apps.

As Figure 1b shows, a one-to-many model yields

number of credentials = (number of users + number of apps)

and

number of connections = (company + number of integrated apps).

Applying these formulas to the previous example of 10,000 users would produce only 10,000 credentials, a 93 percent reduction compared to the one-to-one model. This would result in a management cost of only $31,500 per year and, with just one connection from the organiza­tion to the fabric, an annual integration expense of only$50,000.

Beyond the cost savings, cutting credentials by more than 90 percent brings material security and risk ben­efits. In addition, moving to a hub-and-spoke architecture reduces the number of components that could fail, result­ing in greater reliability.

### Identity network effect

A network’s value increases as more people use it and it expands in reach. The classic example of this kind of posi­tive network effect is the telephone: the more people who owned one, the more valuable it became to each owner.

As more users and apps are integrated in the identity network, these benefits extend to other network members simply by virtue of their being connected. This is possible because the identity fabric serves as an identity integration broker, securely shared across the network. As the fabric is upgraded, the upgrade benefit is realized across the cloud.

Examples of the network effect can be found through­out the cloud. Consider Apple’s iTunes. When the company introduced its App Store on iTunes, millions of users already accustomed to buying music through iTunes could quickly acquire apps for any iPhone, iPod, or iPad on the network. Since its debut in July 2008, customers have downloaded more than 7 billion apps through the App Store (see this link), providing Apple with significant revenue. Moreover, the vast major­ity of purchases occur through self-services and without IT intervention, and developers contribute new apps rather than Apple building them.

Similarly, the network effect dramatically benefits cloud identity. As providers add new SaaS apps to the fabric through federated SSO and provisioning, any network member can leverage that integration without extra effort due to the one-to-many approach. By distributing integra­tion through self-service capabilities, the identity fabric becomes exponentially more valuable as more connections are made between the fabric and apps.

Another example of the network effect’s positive impact on identity management is Google’s implementation of strong two-factor authentication for Google Apps. In September 2010, Google let enterprises protect their accounts by delivering to users a one-time code on mobile phones (via SMS) as an additional authentication factor along with their password.

This was a great improvement in security intended to reduce phishing attacks and other password weaknesses, but on its own, it benefits only Google Apps users. When combined with the identity fabric, however, the benefit of strong authentication can expand across the network. Specifically, if users’ authentication to the identity fabric originates at Google with two-factor authentication, then this trusted session can be federated to other apps on the network, even those without a need for strong authentication. By integrating and leveraging the strong authentication capabilities of Google through federation with the identity fabric, cloud service providers save them­selves the cost and effort of deploying and managing a strong authentication infrastructure.

### Abstraction

Realizing a cloud-scale identity fabric requires abstract­ing identity into identity services. App developers have historically built identity into the app itself, maintain­ing a local user store for authentication. This results in redundant and often stale data, password proliferation, and greater help desk costs.

During the past 10 years, apps have begun to external­ize identity starting with leveraging external directories that use the Lightweight Directory Access Protocol (LDAP) to authenticate users centrally. This has been a great step forward for scaling identity management, but it must go further - LDAP password authentication is not enough. Enterprises must be able to use more than one type of authentication depending on the level of risk associated with an app.

Externalizing identity. By externalizing all key identity functions for Web apps in either public or private clouds, developers can focus on improving their apps, and enter­prises can manage identity across multiple apps more efficiently:

• Access control can be externalized to a network proxy instead of being performed within the local app.
• Federation and authentication can be externalized from the Web app to the webserver or proxy, where the app trusts the authentication service to hand it an authenticated user ID, usually through HTTP headers.
• Auditing can be externalized using a proxy to cen­trally log activity and aggregation tools to report activity.
• User management can be externalized by leverag­ing an external user directory like LDAP instead of an internal user database. This can also be done by exposing user management APIs to external man­agement systems, ideally using a standard interface like SPML. Also, using commonly defined directory/user schemas would streamline external identity management.
• With new cloud-designed apps, authorization and entitlements can be externalized using the emerg­ing claims-based model, wherein federated partners provide user and transaction attributes in HTTP head­ers or tokens for authorization.

Standards. The challenge in externalizing identity is the degree to which the existing app must be modified and whether changes would change its behavior. Change is expensive, and many developers have difficulty justifying “plumbing” improvements over features and enhance­ments customers are willing to buy. This underscores the need for standards that streamline how developers exter­nalize identity so that they need only do it once to work with many identity management technologies.

To see that open standards are the proven way to achieve ubiquity, we need only look at where HTML, IP, and SSL have taken the Internet. Identity is no stranger to standards, as evidenced by LDAP, x509, and HTTP au­thentication. Existing cloud identity standards are well designed and reference reliable implementations, including

• SAML for federated SSO,
• SPML for federated account management and provi­sioning, and
• XACML (Extensible Access Control Markup Language) for federated authorization and access control.

The problem with these and other cloud-scale identity standards relates to prioritization and adoption. Consider buying a computer with an electrical plug that you can only use in 5-10 percent of outlets - this is the rate of SAML adoption today. SPML and XACML are even further behind. To be relied upon, adoption of standards must be ubiquitous.

Fewer users will ask for federated SAML SSO than for a new feature or a mobile version of a particular app. In addi­tion, recovering the cost of implementing SAML federation software, which can exceed \$100,000, is difficult. It is thus not surprising that improvements in identity infrastructure lag. The adoption solution is twofold: first, leverage open source tools like Fedlet to lower the cost of implementing a standard; and second, leverage the identity fabric to pro­vide these identity services in an easily consumable way, minimizing effort and cost.

## Identity Infrastructure as a Service

According to Nicholas Carr’s analysis of IT’s evolution into a utility[4], infrastructure-like power generation began with a dedicated model: only organizations with large amounts of capital could afford to build and operate their own waterwheels and, later, electrical generators. This infrastructure gradually became centralized at a utility - a power plant or telephone company, for instance - due to economic forces and democratization. Finally, the estab­lishment of distribution standards and a delivery network led to wide adoption of a utility service, resulting in econo­mies of scale, cost reductions, and new capabilities.

Identity management for the cloud must also evolve to the point of being standardized and accessible by multiple applications and users. Why must it be built differently than conventional single-tenant, behind-the-firewall identity management software? Nobody has success­fully retrofitted cloud constructs and models onto legacy software, which was created with a different set of assump­tions. To be successful in the cloud era, organizations and vendors must fundamentally rethink how they manage, deliver, and consume identity.

The concept of identity infrastructure as a service fol­lows two major trends: the evolution of IT from capital infrastructure to a service, and the consumerization of IT.

### Identity as a service

Rather than investing heavily in identity when developing or using an app, it makes more sense for an organization to utilize a service for its identity needs. Iden­tity as an infrastructure presents an on-demand model that delivers the right amount of capability at the right time. Companies need to think less about identity technology and focus instead on service-level agreements and ser­vice management, not infrastructure. This means moving from a company-owned to a service-provider-owned and -operated identity management approach.

An identity management solution that requires making a capital investment to use a cloud service does not reflect this shift. If each person had to buy a cell phone tower just to use a mobile phone, how many people would have mobile phones? Mobile phones are ubiquitous because users do not have to buy any infrastructure to use the net­work. They simply pay a subscription for the service and get access to the entire shared cellular infrastructure.

Consider the Internet’s Domain Name System (DNS) backbone. Major DNS name services provide these services transparently and reliably. How the provider actually runs the name servers is irrelevant. All that matters is that name services are readily available and perform as expected. Identity services must be as transparent and reliable as DNS services.

### Consumerization

Each of us uses sophisticated, consumer-based Web apps every day in our personal lives. For example, millions of users access Amazon to search for and purchase items; hundreds of millions of people connect via Facebook; and iTunes offers millions of songs and thousands of TV shows, movies, podcasts, and audiobooks for downloading. Our experience with such sites leads us to expect enterprise systems to be just as simple, effortless, and reliable. More­over, we all prefer a “freemium” model that lets us try out a service without a commitment or investment.

We also like to do things ourselves. We generally want to use apps without IT’s help and with a minimum of administration, and we buy technology like smartphones and laptops at the grassroots level, not centrally from a company. Anyone can set up a rented development envi­ronment with a credit card and the same Amazon account they use to buy books and other goods. The same goes for identity—the line between professional and personal per­sonas has blurred. When you use Twitter or Facebook for work, for example, are you an employee or a consumer? It is often very difficult to distinguish between the two.

Cloud service providers will deliver better identity solu­tions to their customers by utilizing a specialist’s expertise rather than building it themselves. They must build scal­ability into every design decision from the beginning. Too often, scalability is an afterthought or a reaction to an overloaded system. Developers set performance ex­pectations when they build an app, and if it meets those expectations, it is deemed scalable. But problems arise when expectations change, as is the case with an unex­pectedly successful viral adoption or when porting an app server to the cloud. Using a hypervisor to abstract compute power from the app is a simple way to scale up, but most apps are not architected to readily leverage the N+1 scale that clouds offer.

By consolidating identity infrastructure, service pro­viders can achieve economies of scale. As with solid-state drives, the number of moving parts is reduced, resulting in greater uptime and reliability. Each identity integration point becomes a stress point, and each credential creates a broader attack surface and potential help desk expense.

Many large-scale identity ecosystems have the disrup­tive potential to accelerate change in cloud identity. Google Apps, which launched in March 2010, acquired more than 27 million users in its first month[5]; obviously, that number is much higher today. Other examples of such systems in­clude Twitter, which has 106 million registered users and is adding more than 300,000 per day[6], and Google Gmail, which boasts more than 170 million monthly users[7].

Facebook has exploded in popularity, with more than 550 million users—more identities than the combined populations of the US, Canada, the UK, and Italy[8]. This massive number of identities can be integrated with the identity fabric en masse due to the walled-garden aspect of Facebook’s platform and user community. When Face­book introduced support for identity sharing via OpenID in 2009, hundreds of millions of people suddenly had OpenID credentials.

When Google decided to support OpenID a year earlier, it brought more than 100 million users into the market overnight. The implication for cloud identity is that con­sumer authentication models that have been proven to scale to hundreds of millions will be part of the identity fabric and give it critical mass and scale. These examples clearly indicate that an identity access fabric linking enter­prises to the cloud is not only relevant but also necessary.

Cloud growth can be compared to a city that builds homes at an explosive pace without building the infrastructure of roadways needed to support the influx of traffic. In the case of identity management, the cloud has not kept pace with the enormous volume of user identities that network administrators must manage and secure.

To realize the cloud’s benefits, enterprises must have an identity infrastructure in place that can overcome the limitations of precloud identity architectures. This means using an identity fabric that links many apps to a single identity. The proliferation of identities demands a better identity management solution, not only to ease the burden on IT administrators’ time to manage them but also to address security and privacy concerns.

An identity fabric that provides a secure linkage be­tween the enterprise and the cloud, while reducing the number of identities, is the clear answer to enabling full-scale cloud adoption. Cloud-based identity management delivered as an infrastructure service with on-demand dial-tone quality benefits users, network administrators, application vendors, and service providers in dramatic ways. The cloud, with all its ubiquitous technology, must also make the identity management fabric ubiquitous, as its growth and acceptance depend on it.

Eric Olden is founder, CEO, and chairman of Symplified, a cloud security provider based in Boulder, Colorado, that is working to build an on-demand trust fabric that helps secure and facilitate adoption of the cloud. Olden is a gradu­ate of the University of California, Berkeley. Contact him at eolden@symplified.com.

Computer, the flagship publication of the IEEE Computer Society, publishes highly acclaimed peer-reviewed articles written for and by professionals representing the full spectrum of computing technology from hardware to software and from current research to new applications. Providing more technical substance than trade magazines and more practical ideas than research journals. Computer delivers useful information that is applicable to everyday work environments.

[1] E. Knorr and G. Gruman, “What Cloud Computing Really Means,” InfoWorld, 7 Apr. 2008;

[2]Twitter User Statistics Revealed,” The Huffington Post, 14 Apr. 2010;

[3] Morgan Stanley Research, The Mobile Internet Report, 15 Dec. 2009, Morgan Stanley & Co.;

[4] N. Carr, The Big Switch: Rewiring the World, from Edison to Google, W.W. Norton & Co., 2008.

[5] C. Boulton, “Google Apps Marketplace Stats Ex­pected to Show Platform Success,” eWeek.com, 8 Apr.2010;

[6]Twitter User Statistics Revealed,” The Huffington Post, 14 Apr. 2010;

[8] Central Intelligence Agency, The World Factbook 2009

Style

## Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

## Get the most out of the InfoQ experience.

### Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

It's not that easy

Be vary scared of anyone who tells you that you just need to do a couple simple thing and you'll have a secure identity, authentication and authorization system. The specs cited have complexity because the problems they try to address are complex. Yes, you can come up with degenerate cases that are not, themselves, complex but such toy cases rarely cover real-world use cases. And yes, in hindsight there are probably ways to streamline certain bits of the spec.

In addition, the article makes various claims that simply aren't true. For example, HTTP is not the "gold standard" in authentication. It's a total joke if what you're after is security. And it certainly isn't a scalable, distribution, identity fabric.

In addition, if the statement that "nearly 100 percent" of web applications already support HTTP authentication were true then nearly 100 percent of web applications would also support SAML (or OpenID or Kerberos) since these are just (when implemented properly) another authentication plugin in the web server.

As some one who works in this area I always cringe when I see these types of articles because too many clueless people will read it think they have the problem licked.
Close

#### by

on

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss