Print-friendly Version

Identities in a Service-Oriented World: Identity as a Service

Achim Reckeweg, November 2008

Contents

• Software as a Service
• Security Considerations
• Organizational Aspects
• Identity as a Service
• Conclusion
• Acknowledgments

This paper discusses current innovations within SOA and Web 2.0 environments. It tries to shed some light on the implications of the use of these environments in day to day life as well as ramifications in terms of legal regulations. In the conclusion, a concept implementing the requirements is discussed.

Software as a Service

If you browse through the current IT literature or IT-related magazines and newspapers the term Web 2.0 is ubiquitous. Apart from the giants of the industry like Google, Yahoo or Microsoft, a lot of smaller companies are working in this field. The community-focused aspect of these technologies gets a lot of acceptance, but also the availability of well-documented APIs to the web developers is a huge advantage. Evolutions like this enable the integration of available services into one's own web based applications: so-called Mashups. Examples for technologies like this are the frameworks of Facebook or the services API of Google Maps.

Figure 1: Web 2.0 Application
(Click to Enlarge)

Currently more and more services are developed and deployed in the context of Web 2.0. Many of these services can be used to implement web based applications that have not been possible before. If you look at applications like Google Docs or Adobe Web-Photoshop, even classic desktop applications are moving to the web. Some can be used even if they are not connected to each other, or the client system is temporarily disconnected from the Web. For a detailed discussion see a publication by the German Bundesamt für Sicherheit in der Imformationstechnik (BSI), Web 2.0 - Sicherheitsaspekte neuer Anwendungen und Nutzungsformen des Mediums World Wide Web und ihrer Implementierung (pdf), 2007, Chapter 3.

A different part of the industry requires the use of re-usable software. Such software components are developed relying completely on open standards. In the past, standard software products were self contained. They did not rely on open standards and were therefore too inflexible. Hardly integratable with software products from other vendors, they were sometimes hard to adopt to the established business processes. For more information, see Bundesamt für Sicherheit in der Informationstechnik (BSI), SOA-Security Kompendium - Sicherheit in Service-orientierten Architekturen (pdf), 2008, Chapter 2.2.

Add the short innovation cycles of current software products, where often the interfaces are changed or at least enhanced. The reason for the explosion of today's costs and/or development times in software projects is obvious. This problem is also addressed by the use of open standards. Industry tries to encapsulate the business logic and let the modules communicate utilizing standardized interfaces and protocols. So, complex applications can be composed of smaller components or services. This process is called orchestration, and the applications are loosely coupled. They are characterized by the fact that parts of the application can be very easily replaced by similar services.

The SOA vendors are in the same situation as the Web 2.0 vendors: The service can be hosted at the customer, but can equally well be hosted anywhere else. Integration is achieved by utilizing open standards and online communication.

Figure 2: The SOA Approach
(Click to Enlarge)

If you believe the stories told by various experts, in the very near future, software won't be sold anymore. It won't even be installed on a computer local to the customer, any more. Instead everything will be used online, integrated over the net, composed by various services from even more different service providers. In the Web 2.0 world the community is working on a unified standardized framework right now. Currently more than one framework is available, but it is only a matter of time before one establishes domination. Within the business related IT world, the development has already progressed further. The Web Services (WS-*) protocols are an established standard. XML based protocols enable the development of client-server applications in heterogeneous environments. This is nothing new, but XML deals with the drawbacks that for example have not been addressed by CORBA.

Service Aggregation

In the Web 2.0 world as well as in the Web Services world it's possible for you as an end user to compose your application according to your requirements. Do you really need all the functions available in the current standard office applications, or like most people, do you get confused about what function to use when or in what context? Wouldn't it be better to cut the applications down to the bare minimum and add just what is needed? The current trend is to start with the basic functionality which is often provided for free. Then, if really needed, additional functionality can be added. Some of these extra modules might be free, for others there might be a fee. Think about a model where the end user just rents a particular service for a one-time execution. With a paradigm like this the services don't have to be supplied by the original vendor of the specific application. Instead the end user has freedom of choice. In an environment like this, nobody can predict what run time environment is used, or in which programming language a particular service is developed. Actually there is no need to care, if everything relies exclusively on open standards.

Security Outsourcing

Basically there are distributed services, developed in different programming languages, but using standardized interfaces to communicate. These services can be used by an arbitrary number of other services, building a completely new application, never conceived by the initial developer. In the past every single application implemented the subjects of authentication and authorization on its own. The gathered user data and credentials were stored in a local, isolated repository. Obviously this approach won't work in a distributed, highly dynamic world any more. Instead the security requirements of the single services increase dramatically.

Now, each service has to satisfy not only its own requirements, it has to satisfy the overall security requirements of the aggregated new application. The overall application is as secure as the least secure of its components. To fulfill these requirements, a unified approach with distributed security components, that are implemented as a service, is logical. The security aspects must be identified and isolated from the application's logic, and then it can be implemented as a service. These services can be provided by anybody and are not necessarily supplied by the implementor of the business logic. There are a large number of potential security services but the most common ones are Authentication, Authorization and Auditing.

Another crucial security aspect is the creation and the management of access rights. This is done very often in the form of role definitions. We can differentiate between technical or system roles and functional or organizational roles. The technical roles are used to aggregate the access rights on a system level. The functional roles are used to model the access rights from a business related point of view. The functional roles rely mostly on the technical roles. The technical roles use system specific approaches to implement the access rights. The functional roles aggregate the needed technical roles to satisfy the access rights discussed on a business level.

It is important to foster a global, distributed service for the subject of role management. The analysis of the role model currently in place, as well as the maintenance and advancement can be a real challenge. The use of supporting role mining and role management tools can ease the process significantly. If the assignment of roles and access rights can occur outside of the application, it is possible to aggregate them into policy sets. That means that the security aspects of a service can be configured at run-time. The security requirements of a service can be defined in its context, and a policy fulfilling these requirements can be implemented and applied subsequently. Thus, the same business logic can be used in different environments with different security requirements and still meet them without any programmatic changes. With a model like this business modules are easier to define, implement and maintain, and they are therefore better suited for audits.

Establishing Value-added Services

This concept enables service providing even for large user bases with very fine granular access rights, laying the base for personalized services. It enables you to sell value-added services to a broad end-user community. A service is only billable to a particular customer, if its consumption can be provably associated with his/her account. If one follows this idea to the very end, billable services mean accountability. Thus IT costs will be transparent, if this paradigm is implemented consequently. In this scenario an additional important security service is the logging/audit service, used as the base for billing.

Data Privacy Aspects

Every single service must have access to the data it needs, to fulfill its function. It should not have access to additional, unnecessary data. Data privacy is an important aspect in this environment. User data should only be stored, if it is really necessary and only for access by the service where it is used. Relations and links between these data pools should only be established were necessary. This concept is called data minimalization. With these demands in mind, it is obvious that a centralized approach won't work. A distributed, federated concept that allows different identities and their attributes to be kept separate, and only linked on demand and by exception, will work.

It Has Started Already...

Standard software vendors like SAP or Oracle already started to develop in this field. Their new products are based on these concepts. They utilize SOA architectures and incorporate established standards like Liberty or WS-*. In the Web 2.0 space companies like Google, MySpace, Facebook or Xing are developing frameworks and/or platforms that are used to implement more and more services, which can be used to replace current desktop applications. They are relatively easy to use, small and cheap. They work on any platform that has a Java-enabled browser installed. These applications can be used offline and are more than sufficient for most users. Currently they are not as mature as the established applications they aim to replace; they are still in the development phase, but development is proceeding very fast. At the moment there are a handful of different frameworks available and it's not clear which one will be the winner. But we can safely assume that it will be based on open standards.

Security Considerations

Analyzing the discussed paradigms in terms of security, they all have one thing in common: they rely on an established reliable platform security. All the security related best practices discussed over the last years are relevant and must be presupposed. The physical machines used for the services have to be configured as securely as possible. The operating system should be minimized and hardened. And of course the network must be developed and implemented according to the established security patterns. For detailed discussions on this topic, see BSI IT-Security Guidelines (pdf).

But there is a big difference to the architectures implemented in the past: the concept of a firewall protecting the perimeter, isolating and securing the internal network, is no longer valid. See BSI, Sicherheit von Webanwendungen (pdf), 2006. A firewall should still be used to protect the architecture as a whole, from people poking and probing around in areas beyond their authorization. But it is an avowed goal to let users connect to the internal systems. The services are built not only for employees. Partners, customers and external, unknown entities are invited to use them also.

Thus, communication with the system providing services must be possible, potentially from anywhere. Therefore a significant hole must be punched into the perimeter firewall's rules. Web Services communicate using SOAP (an XML based protocol) over HTTP or HTTPS. The same communication channels that already have been established for the direction in to out, are now also used for out to in. From the perspective of firewall rules, this is not a major issue, but the traffic on these channels now includes business-critical data, as well as relatively uncritical data. The security levels are different on the same channel. The correct usage of protocols, and behavior of the communicating parties, must be checked. Contrary to the principles of traditional Layer 3 stateful-inspection firewalls, it is not sufficient to check who is communicating on which channel. Now the semantics of the data content must be checked and validated, at OSI Layer 7. It is necessary to establish a service that understands the XML protocols and can check if everything is used according to the contracts. A service like this is called an XML firewall. For reference, see BSI, SOA-Security Kompendium - Sicherheit in Service-orientierten Architekturen (pdf), 2008, Chapter 4.1. This new concept is necessary to enable end-to-end security not only for the services, but for the whole participant chain starting from the client and going all the way down to the service provider. A detailed discussion on this is available at BSI, SOA-Security Kompendium - Sicherheit in Service-orientierten Architekturen (pdf), 2008, Chapter 3.

Consistent Personalization

The foundation for the personalization of services is a complete and global Identity and Access Management. Every single service request must be trackable to the account that originally tried to access it. The use of group accounts or technical accounts is not acceptable, as the request is not traceable to an individual. Auditing is nearly impossible, if the audit logs only have a notion, that someone out of a group of people was responsible for a particular request. This is contrary to the demand of comprehensibility and makes it difficult to assign costs. Unfortunately, technical accounts are widely used today.

Federated Identity Management

If this requirement is accepted, absolutely no access is allowed without explicit authentication and authorization. This goal can usually be achieved with acceptable effort, inside a single organization. For example, you can utilize a central directory or even better, a full featured Identity Management System to implement automation and auditing of user provisioning, profile or role management, and de-provisioning. But what about decentralized network structures, where arbitrary partner or supplier organizations need to work together? Fortunately there are solutions around, like the one developed by the Liberty Alliance. The Liberty Alliance is an industry organization where numerous vendors worked jointly on the concept of federated identity. Companies like Sun Microsystems, Nokia, Oracle and American Express are significant influencers of this initiative. In principle the concept addresses the need for a protocol, where autonomous organizations can work jointly without a central arbitrating instance. This is achieved when the isolated user accounts of each organization's authentication silo are linked to each other, with the consent of the user.

Isolated Organizations

The whole process is called identity federation and is designed in a way to ensure that the involved parties don't have or acquire any knowledge about each other's data. The only thing they know for sure, is that they are dealing with the same entity, but even the name in the realm of the other party is unknown. Thus each party retains control over its own data. Authentication is outsourced to a reliable partner, but authorization and auditing are handled inside the organization.

Partnering

Each participating organization has its own Identity and Access Management in place, which is used to protect its own internal resources. It is responsible for all necessary aspects of the user accounts the company is in charge of. For external users the authentication is outsourced to a trusted third party. If an external user requests access to a protected resource, the authentication of the user is redirected to the organization the user came from in the first place. It is essential that the two parties have a trust relationship and have agreed on contractual terms and conditions. After authentication, the home organization signals the relying party that the user is known and that it is authenticated to a given level. If the level of authorization is sufficient for the access to the resource, the user requested initially, the local access management system will allow the user access. It is important that the enforcement and the logging is done locally in the sphere of control of the service's provider. For audit purposes it is crucial, that both parties are able to log every single step of the operation and accordingly make it auditable.

Different Approaches

Apart from the implementation of the Liberty Alliance there is a second approach: the WS-* protocol family, mainly developed by IBM and Microsoft. This implies that the developer of federated identity based Web Services must decide which family to use, before starting development. Furthermore it is not that easy to switch from one set of standards to the other. This is in contrast to the goals of the SOA architecture, which aims at enabling the developer to build and link services regardless of the underlying technology. Fortunately, divesting of the security-relevant functions into external services seems to solve the problem. Developers concentrate on the business logic and rely on external authentication, authorization and role management services supplied by the underlying runtime environment. The access management products serve as a broker between the protocol families; this can be considered as a special form of federated access. Apart from the authentication, the broker also performs the protocol transformation. If necessary the requestor will get an additional piece of data, which will identify him or her in the other protocol world. See OpenSSO as an example of such an implementation.

One of the basic goals of the Liberty Alliance has been to re-use existing protocols, advancing them if necessary. Therefore there are quite a lot of protocols used in the Liberty stack, which were originally developed by OASIS. Some of the protocols developed in the context of WS-* have also been given to OASIS for further development. For example WS-Security is already used in current Liberty protocols. A future protocol convergence can be expected.

Transport Security

It is possible to use other bindings than the pre-dominant HTTP for the SOA protocol family. The use of HTTPS should be mandatory because HTTP is clear text and most often sensitive information is traveling on the wire. Encryption on this level only ensures confidentiality between the directly communicating parties; unfortunately this can't be assured end-to-end. There can be an indefinite number of hubs in between. Data integrity and non-repudiation have not been discussed yet. In cases like this different cryptographic functions must be applied on different parts of the messages.

Message Security

The relevant parts of the message have to be either signed, encrypted or both. On its way from the originator to the recipient the message is wrapped at every hub and transferred to the next one in the communication chain. The next in the chain unwraps the message and acts accordingly. So it is possible to communicate over an indefinite chain of hubs without the necessity for the hub to know anything about the content of the message. The commonly used protocol for that is WS-Security, developed by the WS-* world, which is also now used within the Liberty world. WS-Security in turn relies on the more basic protocols XMLENC and XMLDSIG.

Certificates

A basic requirement for the use of these protocols is the existence of a PKI infrastructure. XMLENC and XMLDSIG define how XML messages are encrypted or signed, either partly or as a whole. The necessary certificates are acquired by a third protocol, XKMS (XML Key Management Specification). This protocol defines Web Services calls to a providing PKI. If the service to be implemented is a public one, a global certificate authority should be considered. If a certificate complying to the German signature law is used, the whole process is covenant. If the service is targeted for a closed user group, maybe inside a company, an o PKI with a self-signed root CA can be utilized.

Profile-based Security

Not every security requirement for a particular service can be known in advance. Requirements might change over time, because the service is re-used as part of a larger service with other requirements. Taking this into account it is reasonable to implement the security aspects in a configurable manner, abstracting them completely from the application itself. If this is done correctly, even the application development will be much easier, as the developer can concentrate completely on the business logic. Which parts of the communication must be secured, and to what degree, are defined afterwards and configured during deployment time. This security configuration can be aggregated into sets of profiles. The advantage is that there can be an arbitrary number of profiles for every single service. A service is thereby able to be adapted to the security needs of any particular instance. The use of a service in an insecure environment like the Internet, dictates other security requirements than use within a protected environment.

Organizational Aspects

Identity Management

The subject of Identity Management is foremost an organizational task. It is the process of management of all employees and related persons in a company. They must be known to human resources, they must have desk space and there must be access rights assigned to them. This includes the physical access to buildings as well as login information for getting to their desktops and IT applications. The basic business processes should already be in place. Very often the processes rely on a centralized role model, easing the process of relocating people to different positions, and implied access rights. This is a central task to every company. Contrary to former approaches the modern Identity Management system tries to span the process as a whole, regardless of what systems are incorporated. The term "Digital Identity" was formed for this kind of approach. The complete lifecycle from creation to withdrawal has to be covered not only for IT-related employees, but also temporary workers, partners, customers and blue collar workers or cleaning personnel. The whole management process must comply with appropriate laws and regulations. National laws must be covered, and international regulations also have to be taken into account.

Outsourcing

A current trend in industry is the outsourcing of tasks or complete parts of a company. Reasons for this are diverse. They start with cost reductions, proceed to process simplifications or try to circumvent possible problems with employees. To enable outsourcing, it is necessary to define and describe all tasks, so that Service Level Agreements and contracts between the service provider and the service consumer can be negotiated.

Web Services or Software as a Service

The use of a Web Service hosted by a third party is nothing more than a special form of outsourcing. Application hosting is nothing new; for example, several providers host SAP platforms. During the Internet boom of the late 1990s this was called Application Service Providing and something similar is expected to be seen in the Web 2.0 space. In case of Web Services the situation is slightly different. The number of potential providers is indefinite. If the concept is adopted to its extreme, using for example dynamic service lookups and service routing at runtime, nobody will know who the currently used service provider is, without querying. At best, this can be determined by using a monitoring service. And if configured, it must be one from a preconfigured set.

Contracts

If you consider the situation as sketched out above, it is obvious that the legal implications are huge. If you use a few service providers, it is possible to agree on contracts with every company. But if the number of providers increases, the number of contracts also increases. Most companies already have contracts for outsourcers. It will become necessary to determine:

• If these regulations are sufficient, with the new parameters
• Which data source is considered definitive - for example, if a business is relying on federated identity and one of the business partners attempts to repudiate an access approval, it can be hard to prove the truth.
• Who is liable for the costs, if an audit finds that a company supplying a service is in conformance with a regulation, but the provider running some third party and minor services used by the company is not?
• What are the legal implications for a company, if a service provider breaches data privacy laws and sensitive information is leaked?
• If running a service can be bound to regulations or if the provider has to prove that it holds certain certifications. See also Statement on Auditing Standards (SAS) No. 70.
• What happens if the service provider loses such certifications? Will the contract be automatically terminated?

SLAs

Service Level Agreements define what the criteria to measure the service are. The question is, if it is possible to define a SLA for every single service; as a concept SLAs don't scale very well. A possible solution would be to concentrate on a few service providers with SLAs covering the whole offering. The use of other providers, if allowed at all, would be limited to minor, non-critical services. Who qualifies the services and keeps an overview of what is used from which applications? This process is cyclic and continuous, as the relevance of applications and services is constantly changing throughout day to day business.

Data Protection

Everything that has been discussed so far has to be achieved in compliance with legal regulations, data privacy and data protection laws. Identity Management Systems deal with personal, sensitive data. Unprivileged data access must be impossible, throughout the whole workflow. Furthermore every access, even administrative access, must be logged so it will be possible to prove who had access to what resource at what time. But keep in mind that even the log data includes sensitive data and therefore falls under the data protection laws. It must be enforced that only appropriately privileged persons have access to it. In principle, the data privacy regulations necessary for Web Services are not very different from the ones for outsourcing; the big challenge is the necessary number of contracts. One of the pre-requisites for running applications, which handle sensitive data, is the base security of the underlying infrastructure and strict compliance with security policies.

Compliance

Organizations that must adhere to legal regulations like Sarbanes-Oxley (SOX), Euro Sox (pdf), or KontraG must ensure that the compliance can be guaranteed for the complete process chain. This is true even if parts of the processing are outsourced to third parties. The initial service provider is responsible for compliance issues. A provider must make sure that all of its subcontractors comply with the regulations necessary. Therefore it will be a requirement, that all providers of Web Services work based on the accepted standards of IT security such as Information Technology Infrastructure Library (ITIL), Control Objectives for Information and related Technology (COBIT) (pdf), SAS 70, and American Institute of Certified Public Accountants (AICPA) Service Organizations: Applying SAS No. 70, as Amended - AICPA Audit Guide (note: the guide is available to members at http://www.aicpa.org/).

Where Are We Right Now?

It is more than likely that not all of the technical capabilities of the new service oriented world will be employed in practice. This opinion is mainly bound to organizational and legal implications. For business critical processes it is necessary to concentrate on well known providers. For non-critical services it might be possible to select others and simply try them out.

Identity as a Service

Having discussed the further evolution, the security considerations and organizational issues of identities in the new world of distributed, loosely coupled application development, the next paragraph will describe a possible architecture.

Data Virtualization

The foundation of everything, is still the full set of data in an enterprise. With data virtualization, no direct access to this layer is allowed anymore. So the place of storage, the access method and the attribute names and datatypes can be hidden from the services and applications; they can now act on a virtual layer. The configuration parameters necessary for a particular application/service can be aggregated again into a policy. With this approach, the data, accessible or even only "seen" by an application, can be filtered. This filtering can even be done based on the identity of a user who accesses the data, or the place from where someone does try to access the data. Naturally, this will greatly enhance the overall system security; data that can't be seen or accessed directly by a user, can't be stolen or attacked.

Figure 3: Identity as a Service - High-Level Architecture
(Click to Enlarge)

The services access the data utilizing the attribute names defined in the virtual layer. These names can be the physical names, but they don't have to be. Thus it is feasible to exchange or enhance the underlying databases and directories without changing anything in the business layer at all.

Base Services

As well as many other services, the base infrastructure supplies the most important ones: authentication, authorization and logging. The integration of federation or other authentication methods like OpenID or CardSpace is done here.

Authentication

The authentication layer is implemented as a framework, enabling the adding/modifying of arbitrary authentication modules. This spans userids and passwords as well as smartcards, for example, but can also cover biometrical methods. The huge advantage with a framework approach is that an authentication method has to be implemented only once, and can be re-used by any service in the overall architecture. The authentication module or (more correctly the quality of the authentication method) can be chosen, according to the need of the application. Therefore the selection of an authentication method is only bound to the security requirements of an application or service.

Authorization

Authorization is bound to the application and/or the platform of the application. The authorization method is usually tied to group or role memberships, profiles or to the content of special attributes. This layer abstracts the authorization methods from the underlying systems, make the whole process configurable. The authorization can be based on different attributes such as identity, time of day, location of access and many more.

Logging

The logging of every action in the overall system, in a unified, configurable format is a base requirement for enabling the reporting or audit of events. Storage of the log entries has to occur in a way that is tamper-proof. Any subsequent access or modification must be observable.

Security Services Infrastructure

This layer hosts the value-added security services that implement a level more abstract than authentication, authorization and audit. One of the most significant services of this level is the role management service. After investigating the pre-existing role hierarchy, using role mining as an add-on service, everything for creation, splitting and joining of roles is located here, along with the interface for interaction with the services/applications. Within the scope of the policy services, the application security requirements are defined and subsequently configured. As the security requirements of all services in use must be defined, it helps to keep track. Furthermore the repository can be used to track down the required authentication and authorization methods and to make sure that the implementations comply with the minimum defined crypto qualities. Approval and escalation services help to support workflows requiring this sort of interaction. Reporting and audit implement services that can be re-used in further custom-developed services, and enable the use of the same logging format as in the other parts of the system.

Application Infrastructure

This layer implements the standard services, such as run-time containers and high availability/clustering. Furthermore it covers new issues such as monitoring of Web Services or implementing a service repository. Applications or high level services will look for other services to incorporate based on the service repository. Also the graphical tools for service orchestration are located on this layer. Orchestration enables the composition of new applications based on the description of modular services and the graphical connection of input-output streams.

Conclusion

It can be concluded that SOA and Web 2.0 applications will evolve and converge. The new paradigm will ease the application development process significantly. The use of Identity and Access Management is a base requirement, in order to comply with regulations. The existing products must be further developed and their already existing functions must be exposed as services. The goal is to implement a business process oriented Identity and Access Management. All other large vendors are already discussing the paradigm or even have a roadmap. Smaller vendors must follow, otherwise they will vanish from the market. The pre-requirement for customers is a solid, sane identity base, which can be established with the tools already available. The next huge leap forward will be a consistent company-wide role model. Tools are already available on the market. This model will help to analyze what is already there and re-model it to meet future requirements. This is the base that audit and compliance services can be established on. Step-by-step, an Identity and Access Management environment will be developed, which will form the base for SOA and/or Web 2.0 based, business-oriented services.

For More Information

Here are links to other related resources:

• Identity Management section on Sun Developer Network
• BigAdmin Multilingual Hub
• BigAdmin Collection of Security Resources for System Administrators
• Documentation at http://docs.sun.com
• Sun training (http://www.sun.com/training/)
• Discussions such as Sun Developer Forums
• Support:
  • Sun resources:
    • Register your Sun gear
    • Services
    • SunSolve Online
  • Community system administration experts
• Events of interest to users of Sun products
  • Worldwide developer events and Sun Tech Days
  • Current events

Acknowledgments

The author would like to thank Dave Walker for reviewing this article.

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.