Category Archives: Cloud Security

Harmonizing OAuth2, OIDC and SCIM

faucet trumpet

The Cloud Foundry blog recently published my post about how we combined OAuth2, OpenID Connect,  and SCIM in the User Account and Authentication (UAA) service. The UAA and those three protocols are now woven into the Cloud Foundry platform on many levels:

  • authentication and authorization of developers managing applications on the platform
  • single signon for developers with platform support sites
  • delegated authorization to partner applications and services
  • support for separation of duties for service to service access between platform components.

The UAA also allows us to seamlessly support external authentication services such SAML, OpenID2, — and, yes, even LDAP.

I’m pretty happy with how the harmonization turned out. Each protocol contributes specific, essential capabilities with very little overlap. The usefulness of the whole is greater than the sum of the parts. As we move forward, there are some areas of concern:

1. Schema

OAuth2, OpenID Connect, and SCIM have similar schema, but there are
a few odd quirks which require translation. Compare SCIM userName with OIDC preferred_username, or SCIM name.givenName and name.familyName with OIDC name, given_name, family_name. PhoneNumbers and emails have similar issues. It’s not just the minor variation in attribute naming styles — a little camelCase to snake_case translation code could handle that. The issue is that OIDC attribute names are case-sensitive with single values, whereas SCIM attribute names are case-insensitive and can be multi-valued with sub-attributes.

SoClose and yet_so_far.

2. Future Expansion

Each protocol currently provides fairly focused functionality and there is very little overlap. However, standard protocols tend to grow and expand in scope. One way that a working group can accept a current revision is by getting some members to agree to postponing features until a future revision — which implies that there will be expansion. For OAuth2 and OIDC some of the natural areas for expansion are management of client registrations and access to user information in non-interactive scenarios. The working groups have discussed adding both capabilities. Both are areas that we implemented with SCIM base or a SCIM extension. It would be very nice from an implementation standpoint for these protocols to remain complimentary rather than expanding until they overlap.

Managing how well identity protocols play together is not exciting stuff, but it needs to be done.


If you must have a password…

… make it easy to remember and hard to guess.

We spend so much time trying to reduce the need for passwords it’s easy to overlook that password management itself can be improved. Some months ago the Cloud Foundry identity team restructured our approach to password policy. Luke Taylor posted about it on the Cloud Foundry blog. The new approach is inspired by the famous xkcd cartoon which uses “correcthorsebatterystaple”.  We don’t require specific punctuation, case or length. No stupid rules. We dynamically check the password as you type and update a password strength score using an algorithm and open source project also inspired by the xkcd comic. The dynamic feedback is quite intuitive. I’ve quickly learned what makes a strong password — and it’s not an underscore or using a number that looks like a letter. My password lengths have greatly increased but they are much easier to remember. Sometimes small steps are good.

I was reminded of all this by a recent blog post by Sid Sidner. My favorite link (though they are all good) is this one by Don Friesen:

Please do yourself a favor and watch it. It’s my new favorite to show anyone who asks what I do for a living. I tell them that I’m trying to eliminate the stuff this video is talking about. We all hate it so much we can (so far) only laugh about it.

Turtles all the way down

turtles in vmware pond

Photo of turtles on the VMware campus courtesy of Yvonne Wong, recruiter extraordinaire.

Most of us on the Cloud Foundry identity team have been working together for just over a year. We work with a rather interesting group that leads the larger open source community that builds Cloud Foundry.

On the identity team we’ve been working to evolve Cloud Foundry’s user authentication and authorization system into a full suite of identity services — open source and built on open standards. We’ve built some cool stuff. We are now starting to publicize what we’ve built and more actively engage with the community. Our team consists of veteran SpringSource  leaders David Syer (@david_syer) and Luke Taylor in the UK, with Joel D’sa, Vidya Valmikinathan and me in Palo Alto.

Dave started us off with 3 solid blog posts for the blog explaining our use of OAuth2 here, here, and here. He is speaking at SpringOne this week about OAuth2 as well.

Also in the blog queue, Luke has a post that discusses our password management strategy and I have one that discusses how we integrate OAuth2, SCIM, & OpenID Connect into Cloud Foundry itself. Joel recently gave a presentation to the VMware Cloud Foundry engineers about our User Account and Authentication (UAA) service.

Joel, Vidya and I will be attending IIW next week. I suspect that Joel will propose a session there to discuss Cloud Foundry identity services, what we’ve built, and what we’ve learned from operational experience. We’ll be there to work with the identity community as we plan our next steps.

I’ll link to the blog posts and presentations here when they are published.

It’s great fun to finally be able to have this system in a position we can make some noise about it, and we all are. It’s turtles all the way down.

Password anti-pattern alive and well at a financial institution

Wow. I would have thought that after the years of publicity describing the evils of the password anti-pattern, it would not be seen in any current web site that is serious about security. Today, I tried to link an etrade account to a checking account at another institution. Here is part of the screen I got:
I wasn’t sure what it meant by “online login information”. I thought that perhaps they wanted me to reenter my etrade credentials for extra security at this step, but it seemed odd that they would do that in a box that says “powered by yodlee”. I wouldn’t want to give my etrade password to yodlee. So I checked the help bubble and got this:

“Please enter the login information for the bank your external account is at”.

REALLY! They actually want me to enter my username and password from my bank into yodlee via etrade!

So I looked at the “Instant Verification User Agreement”. Here is The fourth paragraph (with emphasis added by me):

THIRD PARTY ACCOUNTS. By using the service, you authorize E*TRADE Bank and/or E*TRADE Securities and Yodlee to access third party sites designated by you, on your behalf, to retrieve information requested by you. For all purposes hereof, you hereby grant E*TRADE Bank and/or E*TRADE Securities and Yodlee a limited power of attorney, and you hereby appoint E*TRADE Bank and/or E*TRADE Securities and Yodlee as your true and lawful attorney-in-fact and agent, with full power of substitution and resubstitution, for you and in your name, place and stead, in any and all capacities, to access third party internet sites, servers or documents, retrieve information, and use your information, all as described above, with the full power and authority to do and perform each and every act and thing requisite and necessary to be done in connection with such activities, as fully to all intents and purposes as you might or could do in person. YOU ACKNOWLEDGE AND AGREE THAT WHEN E*TRADE BANK AND/OR E*TRADE SECURITIES OR YODLEE ACCESSES AND RETRIEVES INFORMATION FROM THIRD PARTY SITES, E*TRADE BANK AND/OR E*TRADE SECURITIES AND YODLEE ARE ACTING AS YOUR AGENT, AND NOT THE AGENT OR ON BEHALF OF THE THIRD PARTY. You agree that third party account providers shall be entitled to rely on the foregoing authorization, agency and power of attorney granted by you. You understand and agree that the service is not endorsed or sponsored by any third party account providers accessible through the service.

It states that this would be really easy, that they have my privacy and security in mind, and I’d be able to transfer money right away. All I had to do was click the box that I agree to the terms of use, and give them the username and password for my bank account — and I give etrade and yodlee power of attorney:

“you hereby appoint E*TRADE Bank and/or E*TRADE Securities and Yodlee as your true and lawful attorney-in-fact and agent, with full power of substitution and resubstitution, for you and in your name, place and stead, in any and all capacities, to access third party internet sites,…”

They want me to give them the keys to my bank account and agree to let them act as me to any internet site, for any reason, and in the same agreement they say this (emphasis is mine):


Seems to me they want me to trust them with my finances more than they trust their own technology.

I declined to use the service.


NCSS Demo at Cloud Connect

Both of my regular readers have pointed out to me that my abysmally low blog posting frequency has recently sagged. That has been somewhat due to the state of my current project, Novell Cloud Security Services (NCSS). NCSS was released last August, and since then we have been working with current and prospective customers to make sure it’s what they need, and to enhance it as usage of the cloud evolves. That has meant a lot of travel and meetings for me — much of which I can’t blog about. However, sometimes I am involved in events that allow said loyal readers to see what I do. One such event was last week.

Last week I attended the Cloud Connect conference in Santa Clara. As I arrived at the conference about an hour late, I got a message from my colleague Gary Ardito that a camera crew was there waiting to record an interview with me and a demo of NCSS. I assumed he was kidding. He wasn’t.

They were from InformationWeek. The interviewer was Fritz Nelson, with David Berlind and a quietly competent camera guy. As Fritz mentions in the interview, we did have a great time reminiscing about Novell history as I scrambled to set up for the demo. I didn’t get completely set up and there were some errors in the demo. It was a crowded space behind the counter and Fritz kept moving in and I kept moving away. At one point he stepped on my microphone cord and I couldn’t back up any more.

Nevertheless, these guys did a great job with the interview and editing the video. They only had one take on a very noisy, crowded show floor. They were quite kind to me and cut out a spot where I inadvertently showed the demo password screen, and glossed over one part where I couldn’t get the demo to work. The screen zooms they added are really good to show the context of various features. I didn’t know about Fritz’s closing comment about running NLMs at ring 0 until I saw the video. Right on. Writing NDS as an NLM on NetWare, man, that was real code.

Issues with Multi-tenant Cloud Services and Corporate Identity Providers

Updated 21 Jan 2011 to fix two broken links.

Recently I have been trying, yet again, to understand social networking and its tools. I figure that, if people like Ben Goodman and Paul Madsen find that stuff useful, there must be some value there that I just haven’t found yet. In my current efforts, I came across this tweet from Anil Saldhana. It points to my submission last month of a set of use cases that I’d like to see considered by the OASIS Identity in the Cloud technical committee. The use cases are some that we have encountered while developing and deploying Novell’s Cloud Security Service.

Not only did I think Anil’s tweet showed a positive use for twitter – I’d like to see more quick updates when standards documents are submitted or updated – but it also served as a reminder that I needed to update the use cases after I got some feedback from the committee. Which I have now done. I may even tweet about it.

Anil’s tweet also made me think to write this blog post. The revised use cases have been provided as input into the Identity Cloud Technical Committee in hopes that we can agree on some standard solutions. However, it’s only the beginning of the process and I’d appreciate your advice and input, so I’m going to post portions of the use cases here and ask for your input. These use cases describe problems we have seen in the interaction of enterprise federated identity systems with cloud services. We are not trying to solve the problems each use case describes (yet), we are seeking clear descriptions of the problems.

Do you see these as issues that need to be addressed in standard ways so that enterprises can securely use cloud services?

Use Case 1: Per Tenant Identity Provider Configuration

Description/User Story

Multi-tenant service providers, whether they are SaaS, PaaS, or IaaS vendors, benefit from quick and easy addition of new customers – anyone with a credit card can add themselves on demand. However, to benefit from federated authentication, SSO, and other mechanisms that can improve security for their users they need to configure how their users can authenticate to the system, where and what kind of IdP they use, exchange meta-data, etc. Currently this is commonly done by the administrator via web forms that are unique to each service. As adoption of cloud services increases, this will become a significant management burden.

Goal or Desired Outcome

A tenant can quickly and securely manage their use of many cloud services using automated tools rather than navigating and manually configuring each service individually.

Process Flow

  1. A departmental manager in an enterprise (a tenant administrator) wants to configure all of the SaaS applications In use by that department to authenticate users via the enterprise IdP.
  2. Using an automated tool to manager her SaaS usage, she enters the IdP information once.
  3. The tool contacts the IdP and each SaaS application and uses standard protocols to communicate the configuration.

Use Case 2: Delegated Identity Provider Configuration

Description/User Story

Enterprises are outsourcing more of their applications and management of their IT infrastructure – including their identity provider services – to managed service providers or identity-as-a-service vendors. This results in a situation where an enterprise administrator which owns the business relationship with the service provider (the tenant administrator) does not manage the identity provider service. The identity provider service is controlled and managed by another company (the IdP administrator). This becomes a significant management burden when the tenant administrator needs to manage the identity services configuration (such as the exchange of metadata) between the identity provider and many cloud services.

Goal or Desired Outcome

The tenant administrator should be able to delegate access to their identity services configuration within a multi-tenant cloud service to the identity provider service. The identity provider service should be able to manage configuration issues such as meta-data exchange to all connected cloud services on behalf of a tenant. This should not require the identity provider to had access to the tenant administrator’s authentication credentials.

Process Flow

  1. A tenant administrator pulls out a credit card and signs up for a new cloud service for her users. Her identity services are provided by a third party – an identity as a service provider.
  2. She notifies the identity provider that she wants her users to have access to the new services.
  3. The identity provider can exchange whatever configuration and meta-data is required with each new service on behalf of the tenant administrator without authenticating to each service as her.

Use Case 3: Association of a User and Tenant during Authentication

Description/User Story

NOTE: this is a rough idea of a use case. It’s a situation we have seen many times, but there may not be a discrete set of viable solutions. Perhaps guidance is the best possible outcome.

When a user accesses a multi-tenant cloud service, the service needs to be able to associate the user with a tenant account. This may or may not be the same as associating the user with an IdP – there are many efforts to try to solve that issue as well and this use case may in fact be a variant of it.

Currently applications handle this issue in a variety of ways. For example, each tenant may essentially get their own application service instance by embedding the tenant identifier in the domain name or path of the URI. Some applications pass it in as a parameter and some store it in a cookie.

This multitude of application variations further aggravates the problem of identity provider association, and makes it much more difficult to provide consistent federated identity services to multi-tenant systems.

A sample scenario:

A manager in the sales department of AcmeWidgets wants her team to have access to a new SaaS application, WidgetTracker. She opens a new account with her department credit card. She wants her team to use their corporate user accounts for authentication – so they are provisioned, deprovisioned, and application access can be audited by the IT department. However, she’s paying for the application from her departmental budget, so she only wants her team members to be able to use the service on her account. A manager in the design department has a similar need to sign up her team members for an account in WidgetTracker.

The problem is that tenant boundaries for cloud services are based on the pay-per-use model which often corresponds with departmental cost centers. In contrast, the corporate user accounts – the IdP – are usually built on corporate boundaries.

It has been suggested that this problem could be overcome by using attributes in the corporate directory to distinguish between departmental tenants. However, the explosive growth of SaaS applications is attributed in part to the low-friction, instantaneous addition of new tenants. Asking each department to submit a work order to the IT department for configuration changes in the corporate directory before they can access a new SaaS application would defeat this key characteristic.

Goal or Desired Outcome

That clear guidance be available from a respected authority (e.g. OASIS) to help cloud service providers provide multi-tenant capabilities in ways that can be more effectively integrated with federated identity services.

Process Flow

For developers:

  1. Read OASIS document
  2. Save time and produce better cloud service by structuring their application to associate users with tenant accounts in accordance with the document.
  3. Profit!

For users and administrators:

  1. Start to see consistency in service access
  2. more easily consume more services with less errors

Further into Identity as a Platform Play

A few weeks ago I had a great conversation with Matt Grant over at the Trusted Cloud Initiative. It was a lively conversation and Matt did a great job of turning it into a blog post.  I’m not sure if I ever stated the main point of our conversation as succinctly as Matt captured it in the title, but he nailed it: “Hosters Need to Think about Identity as a Platform Play”.

When I read it today I noticed one idea I’d like to clarify a bit. The post contains this paragraph:

You see, people can move an application from one host to another without much trouble. The hosters want to be able to hold on to relationships with specific SaaS customers and the idea of identity services is one of the stickiest things possible. Why? Because where people have their user accounts is a very sticky thing.

The point I’d like to clarify is that, while user accounts are certainly sticky, convincing enterprise customers to move the control of their identity management systems into the cloud would be very difficult  – and it’s unnecessary for hosters to get the sticky benefits. They can provide essential identity services such as secure authentication from enterprise accounts, and federated authentication, authorization and audit services to their application marketplace — all without physically holding the user accounts.

Such identity services are a key part of a platform on which application marketplaces can be built. They are a key part of any platform offered by hosters who want to build a SaaS marketplace.

In a typically fascinating post, Eric Norlin commented today on another application marketplace trend – in the enterprise. He was summarizing trends from the last Defrag Conference and the third trend is:

The Rise of the App Marketplace: This was one of the forward-looking things that really hit me, but may have slipped under the radar a bit. The meme of the app marketplace is coming to the enterprise. Installing collaborative, emergent environments is not enough. What we’re really driving toward is an opening up of the enterprise data layer — exposing APIs, if you will — and driving toward a world where the employee (or partner or customer) is not only consuming IT applications, but BUILDING them. The IT “app marketplace” is coming. Bank on it.

To support any such marketplace there must be a platform, whether it is in an enterprise or in the cloud, and a key part of that platform is identity services.

Identity and Security on the Cloud Train

I’ve had many conversations with Dave Kearns over the years in hallways, a few beer halls, and conference panel discussions at events like the Internet Identity Workshop and the European Identity Conference. The conversations have been lively and often pushed my thinking in new directions. We’ve followed a similar path from the directory services of the 90s to Internet identity systems, and now on to cloud computing as it accelerates the adoption of identity services and the identity provider model.

In a recent newsletter Dave riffs on my presentation at the European Identity Conference and then concludes with this paragraph:

“The cloud is a reality. Cloud-based computing is a reality. Platform-as-a-service, application-as-a-service and, yes, identity-as-a-service will soon be as pervasive as client-server computing became in the last century. This will mean fundamental changes in the ways we think about identity and security. Get on that train, or be left at the station.”

Dave, well said.

And the journey continues.

Security, Identity, and Business Drivers at EIC 2010

Earlier this month I attended the European Identity Conference in Munich. The conference is put together by Kuppinger Cole + Partner and they do a great job. As I’ve posted before each year it gets better, and this year was no exception.  This year there were great sessions with cutting edge content, really good food and beer, and vibrant interaction between vendors and customers. It all added up to a very productive week. Oh, and there was really good beer.

Last year, Martin Kuppinger and I led a workshop on cloud computing, and we did it again this year much more in depth – but that’s another post. This year, there was a whole content track devoted to the cloud. As I see it, cloud computing has evolved to become just “the cloud” and is a set of technologies and business models which have the requisite force to drive adoption of identity-based security.  So combining an identity conference with a cloud conference is a Very Good Idea.

I gave a keynote in the Cloud 2010 track. KCP were kind enough to post the video of the session . You can also download the presentation. One advantage of my occasionally-derided “Wall of Words” presentation style is that you can easily get the main points by scanning through the presentation. I took all the photos in the presentation in Munich a few days before the session, which made it more relevant and fun for me.

The concepts in the presentation have emerged in the last year while working on Novell’s Cloud Security Service . Supporting insights and statistics came from a survey initiated by our own Anita Moorthy. Basically the presentation covers how business drivers affect the security needs of enterprises, SaaS vendors and cloud providers.

Here’s a brief overview.

A survey of some current market forces and players:

  • We have seen many times how a disruptive force in information systems is departmental autonomy pulling in products and services under the enterprise IT radar. This is again a significant factor in the adoption of SaaS applications.
  • The adoption of SaaS applications is accelerating a shift by traditional hosting companies and telcos to IaaS and PaaS models, and they are increasingly moving to attract SaaS vendors in addition to enterprises.

The business and security interactions in the cloud involve enterprises, SaaS vendors, and cloud providers – each with different motivations. From this current cloudscape, I identified 3 trends and possible traps in each:

  • Identity-based security is increasing in importance. Cloud services are pushing enterprises to emphasize identity based security rather than network security
  • SaaS and IaaS are converging on PaaS. Infrastructure providers are moving up stack and applications need to be extensible… converging on platform services, including identity services.
  • Cloud providers are increasingly offering identity services – and becoming identity providers. Identity services provide much needed security, and stickiness. Application marketplaces are a powerful paradigm growing around identity provider hubs.

We concluded with some recommendations for enterprises, SaaS vendors and cloud providers.

For years, we have been working on standardizing, implementing, and deploying the identity provider model – which separates the sources of authentication and identity information from services that use identity information. It is clearly a better model for humans than separate accounts in every service. However, as Jeff Bohren succinctly said, “Change is hard. Passwords are easy.” More than ever I see trends in cloud computing that are finally providing the business model and incentives for enterprises, SaaS vendors, and cloud providers to move to the identity provider model. EIC 2010 further accelerated those trends.

I very much enjoyed the conference, working with the KCP team, and the interaction with customers, competitors and partners.

As always, I’d appreciate any feedback on the presentation, offers of presentation rewriting, coaching on public speaking, etc.

Cloud Computing Precipitates Identity-based Security

edge_of_cloudsNot for the first time, I have found a post by Gunnar Peterson to be very useful and insightful. This time, I followed his lead to a post by Chris Hoff.  It’s a piece called “Cloud Providers and Security ‘Edge’ Services – Where’s The Beef?“. I highly recommend the whole of both posts. Mr Hoff’s post is a discussion of what it might mean to integrate security services to the edge of the cloud, and his questioning about what the edge of the cloud could mean. The common answer is that it is securing from services in the cloud to the edge of an enterprise, location, or … something. Something inside a boundary that can be surrounded by some model of security that happens at the network level. Which leads to this statement:

None of the models are especially friendly to integrating network-based controls not otherwise supplied by the provider due to what should be pretty obvious reasons — the network is abstracted.

Chris Hoff, Gunnar and others have been decrying for years that network level security is insufficient. Sometimes the recognition that network level security is insufficient (and often counter productive) has pushed people to make a goal of ‘deperimeterization’, which is a cool word but certainly has not helped move the industry from it’s predilection for network level security. It is much more likely that the term that will finally precipitate a movement from network level security to identity-based security will be “Cloud Computing”.

In Mr Hoff’s post he emphasizes this point:

So here’s the rub, if MSSP’s/ISP’s/ASP’s-cum-Cloud operators want to woo mature enterprise customers to use their services, they are leaving money on the table and not fulfilling customer needs by failing to roll out complimentary security capabilities which lessen the compliance and security burdens of their prospective customers.

Gunnar’s commentary on Mr Hoff’s post makes some equally insightful points:

For access control purposes, security is fairly straightforward, its a game of subjects (like users, user agents, claims, and web services), objects (like resources, URIs, data, and service providers) and what Hoff calls metastructures (like identity and policy). Security is a word that is meaningless by itself, you always have to qualify it: data security, application security, network security and so on. So when people talk about “edge” security, what is it they propose to “secure” an edge device? That’s fine as far as it goes, but its important to note that providing security services to device on the edge doesn’t do much of anything to either side of the edge. Too often people assume that securing the edge means everything “inside” the edge is also “secure” but this is smoke and mirrors for auditors not security for your enterprise assets.

I think of that type of security (with subjects and objects) as identity-based security. An identity is what you apply policy to — it is the subject or object of an access control policy. It’s the base type of the concepts of subjects and objects. The metastractures are processes of authentication and authorization based on those identities. It’s much higher level than SSL and the network layer, but it’s much closer to what’s necessary for business processes and security needs in the cloud.

Gunnar concludes:

Whenever you evaluate security and especially Cloud security, its important to enumerate the subjects, objects and metastructures that you are extending security services to, instead of just describing some security service in the abstract. This problem is a pandemic in information security the whole point of SOAP is that it was a firewall friendly protocol designed to go through the firewall, that was 10 years ago, yet today information security still relies on SSL and network firewalls as primary protection mechanisms (what are they protecting?).

Indeed, what are they protecting? While network level security can enable a secure transmission of data from point A to point B, it does not prevent the vast leakages of passwords and personal information that have become common. Perhaps the growth of Cloud Computing will finally push the industry to systems in which users don’t have passwords, or at least systems which can securely serve their users without receiving their password or storing personal information. If a SaaS application doesn’t have the information, there’s one less place that it needs to be secured. Such identity services have been viable for some time, but have needed a push to get broader adoption. Cloud Computing.

We appear to be on the edge of a nervous breakthrough.