Illustration 1: The Party Pattern class diagram
Identity Management (IdM) needs change as an organization grows in size. For an example, I'll describe a fictional company, and take it from the smallest to largest stages. While, to some degree, the industry of this firm really doesn't matter, I am going to use a small import business started by a single individual and scale it up to a multinational corporation. As the organization grows in size, the technical needs will drive the scope and scale of the identity management solutions required.
Ms. N. Zappa has just come back from a masters degree program in Jakarta. While living in Indonesia, she established connections with several furniture producers, and she starts a small import/export business in the Boston area. She has contacts at a handful of stores already from previous experience. She moves back in with her folks, who have agreed that she can use a section of the garage for storage, and she outsources all technical issues to a small web services firm. They register the domain name ZappasImports.com for her, set up an account a large cloud provider who provide web and email services. Her information management needs are for tracking orders, suppliers, and customers, which she keeps in a set of spreadsheets that she backs up to the cloud on a nightly basis.
After a few months of operations, she realizes that she is having a much lower rate of return customers than she anticipated. She wants to communicate better with the people that have bought from here before to encourage repeat business, as well as to gauge the relative degree of satisfaction her customers have had with their purchases. She mentions this to the account manager at her firm, and they decide to start a more formalize customer database, to integrate this with the email system, and for Naomi to start blogging to explain more about the pieces that she has been importing, to generate a sense of community among her customers. Her customers fall into two categories: individuals purchasing for their homes or offices, and stores that are going to markup and resell her goods. She realizes that she needs to ensure the privacy of her end customers. In addition, she does not want any of them eliminating her as the middle-(wo)man in the supply chain, so she wants to segregate her customers from each other and her suppliers.
Her business grows and she gets an office manager. She rents space at a local warehouse and a small office nearby. They set up accounts with a handful of delivery companies and need to be able to integrate the tracking of packages. The international nature of the business dictates that they get an account that specializes in international trade. Zappas has sufficient business going direct to end consumers that they set up a web catalog and order placement system. This dictates that they have a content management system, and that they establish a relationship with professional photographers in the remote countries that can supply their catalog with high quality images. They have a handful of contractors on retainer that can deliver and assemble some of the more complex pieces. The organization grows a little further. The company is producing enough revenue that she has a full time sales manager. During the busy season, she also hires seasonal help.
Illustration
1: The Party Pattern class diagram
The IdM system manages three types of relationships. First, it manages the relationship between The cloud provider and Zappa's imports. Second, it manages relationships between the Zappa's imports employees. Finally, it manages the relationships between Zappas Imports and the people that do business with Zappas. From the partner's perspective, adding a new application and adding an additional employee are related tasks. At first, both are handled by Ms. Zappa. By the end, are performed by employees who have been delegated the authority to perform these tasks.
In Analysis Patterns, Martin Fowler described “The Party Pattern” as a reusable model of assignment of responsibility. To the left is a Class diagram that captures my interpretation of the heart of the party pattern. In English: a party is a person or group that is assigned a role in an organization that allows them to perform actions on a resource belonging to that organization. We use the term Party to encapsulate the concept that authority may reside in either a person or a group of people. Additionally, the organization allows the party to implement the composite design pattern: membership in a smaller group may imply membership in a larger group, and inheritance of authority delegated to that group.
The instance diagram below shows a subset of the object instances from the Zappas organization model. The Action “Hire temporary employees” encapsulates several smaller privileges: the ability to add someone to the IdM system, and then the ability to assign them a role within the sales organization. This is idealized, of course. An external application such as the point-of-sale system is going to have a set of pre-canned roles that it expects the user database to supply. But still, this is a domain model, an idealized representation of the concepts behind the implementation.
Illustration 2: Org Chart Instance Diagram
Probably the largest question in cloud IdM integration is who owns the information. The Zappas customer list and suppliers list are probably the single most valuable assets of the company. If the cloud provider wants to maintain its own customers, they need to provide sufficient reason to trust their Id solution. On the other hand, they need to protect their own assets. In their organization, Ms. Zappa is a client, and she can add and remove servers based on her contract and quality of service agreement with the cloud provider. As the organization grows, this is certainly one of the actions she will want to delegate to the CTO, who will later delegate it to the Operations Manager when Zappa's Imports grows to the size to hire one.
Should the Zappas IdM database and the Cloud providers database be one system or two? The simple answer is that a single, well architected IdM system with appropriate controls in place is going to provide a degree of control that a multi-part system will not. While it is tempting to think that by having two systems, you will firewall off one segment of your users from another, this thinking has a couple flaws in it. First, you usually want to segregate users from each other that fall into the most similar roles: Zappas wants to segregate her suppliers to keep them from colluding. The risk of a customer hacking into the cloud system in order to perform hackerish acts is much lower that the risk of a rogue junior admin that knows the system performing action reserved to someone higher up in the organization. If there are two systems, and one is deemed canonical, and information is pushed from one to the other, they are acting as a single system, and thus the potential for elevation of privileges is still there. If the Zappa's IdM system runs on a virtual machine in the Cloud providers datacenter, and those virtual machines are not properly secured, a system administrator from the cloud provider can copy those vital customer and supplier lists.
A better argument for segregating the user databases is vendor lock in. If the web development company has developed the virtual machines used to deploy to the cloud provider, they should have no dependencies on elements internal to the cloud provider that cannot be redirected to a different cloud provider. This is going to be more and more important as the company scales up. The ability to tune the software packages that your company uses will help determine how quickly the company can react to new business opportunities or deal with set backs. A larger organization has more contact points, more needs, and thus cannot as easily rewrite the configuration of their applications to deal with a different IdM solution. A Cloud provider can prove to be a poor fit for an organization for multiple reasons, and not all of those can be foreseen upfront. In the case of Zappas, technology is an enabler for business, but it is not the companies forte. By contracting with a decent internet services firm, she has offloaded some of the decisions. She shouldn't be locked in indefinitely to a technology decision made today that is secondary to the core of the business.
A few years down the road, Zappas is doing well, and has grown to a middle sized companies. N Zappa maintains her role as CEO and President, but is completely out of the software side of the company. Dealing with the relationships essential to her business must be supported by technology, not derailed by the management of technology. Zappas has all of the major subdivisions that one would expect to see in a middle sized company. Marketing and Sales are now distinct operations. Operations has a full time call center as well as full time employees for deliveries that require assembly. IT has also grown to support the needs of the organization. On the supply side, several employees have been hired in remote offices to handle the purchasing in several countries. The full time Human Resources manager has contracted to a small number of staffing firms for filling the variations the yearly cycle.
From a technology perspective, the information systems are now a mix of in-house, application service provider, and cloud hosted applications. Zappas works mainly with two cloud providers that offer differentiated offerings due to geographic location and international issues. Applications for supply, foreign tax and travel, and shipping are hosted in a company in Jakarta. The eCommerce web site and partner Business-to-Business portal is hosted stateside. Zappas has consolidated IdM in-house, and shares a subset of its user database with the various technology partners.
The load on the cloud providers systems has scaled up with the company. When orders were measured in single-digits per day, billing was likely at a flat rate. At scale, the daily variations and fluctuation are significant. Auditing the systems becomes a requirement for legal and financial reasons. Different portions of Zappas have different budgets, and pay for the usage of the cloud out of separate accounts.
For authentication of employees, Zappas has moved from a userid/password model to a cryptographically secure system, based on technologies like Kerberos, hardware tokens, smart-cards and so forth. Different systems require the ability to accept different authentication mechanisms: the corporate blog needs a HW token in order to post an article, but allow OpenID authentication for a customer to post a follow up comment. Some of the suppliers and partners have advanced technologically as well, and have their own authentication systems that they want to use when performing business with Zappas. The wide number of web sites in use have dictated a single sign on solution that needs to span across the public internet, and that works around the fact that some of the sites only allow network traffic on ports 443 and 80.
At this point it should become that a standardized mechanism for managing the IdM across all of these systems has become essential. Adding in a new application cannot force changes to the schema. Each additional application cannot silo its own user database. Centralized management is a must; replication to remote sites must be rapid. Elevation of privileges is a major risk and the IdM must have rock solid protections built in against it.
The cloud provider is an integral partner to Zappas. It has to provide seamless integration of Identity Management. Trust and audit are two sides of the same issue: Zappas needs to know what is going on at the Cloud provider. Access to the systems running as virtual machines in the cloud has to be tightly managed. At the same time, the cloud provider finds it seld in the same relationship with many other companies, some of which are competitors to Zappos. For legal and financial reasons, the cloud providers needs to provide segregation between its clients. The number of clients it is managing means that the system has to work completely automated.
This narrative has attempted to put the scale and scope of identity management issues in a cloud deployment into to perspective. The fictional company matches the needs of many real companies, as well as many non-corporate entities. The scope of the identity management solutions vary with the scope of the problem or number of problems that they attempt to solve. As our fictional company grew, its needs changed, as did the corresponding Identity Management Solution.