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.

“Identity folks are the plumbers of the Internet.” – security analyst.

— Andre Durand (@andredurand) February 26, 2013

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

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 cloudfoundry.org 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.

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

E*TRADE BANK AND/OR E*TRADE SECURITIES AND YODLEE MAKE NO WARRANTY THAT (i) THE SERVICE WILL MEET YOUR REQUIREMENTS, (ii) THE SERVICE WILL BE UNINTERRUPTED, TIMELY, SECURE, OR ERROR-FREE, (iii) THE RESULTS THAT MAY BE OBTAINED FROM THE USE OF THE SERVICE WILL BE ACCURATE OR RELIABLE, (iv) THE QUALITY OF ANY PRODUCTS, SERVICES, INFORMATION, OR OTHER MATERIAL PURCHASED OR OBTAINED BY YOU THROUGH THE SERVICE WILL MEET YOUR EXPECTATIONS, OR (V) ANY ERRORS IN THE TECHNOLOGY WILL BE CORRECTED.

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.

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.

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

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.