Identity-based service-oriented architecture: regulating business needs with Web services
Sekhar Sarukkai
* Service-oriented architectures (SOA) have become the de facto architecture of choice for enabling agile business processes via reuseable, coarse-grained business services. Business services are integrated via exposed technical interfaces that increasingly support Web services and XML standards. By adopting the loosely coupled business service model, IT is better able to support the evolving business needs of customers, partners, and employees, who access these services over multiple channels such as browsers, devices, or other applications.
In order to truly realize the promise of reuseable services, appropriate controls have to be put in place for protecting and ensuring service availability. Interestingly, while technologists are focused on XML intruders intercepting Web service messages, business people, who take this for granted, are focusing on tracking and controlling user and application accesses of these business services. These might otherwise expose businesses to significant risk, by exposing sensitive data to the wrong user, for example.
From a technical perspective, addressing this business need for protecting SOA assets is a complex cross-domain problem compounded by the loosely coupled nature of SOA. The solution to this problem necessitates the deployment of a new generation of SOA infrastructure domain services responsible for authoritative establishment and verification of identity. From a business perspective, this is critical to realizing the benefits of quicker application development and deployment, as well as increased system governance. These services should handle application, service, device, and other entity identities, just as user identities were managed in previous generation Web application deployments. It is also important that this service plug into an SOA-compliant federated architecture.
Today’s Solutions Don’t Deliver Intended Value
An SOA service is all about open protocols and hidden implementation, while today’s identity and access solutions are about exposed implementation (in the form of proprietary APIs) and hidden protocols, which usually do not rely on the standards that the SOA backbone relies on.
Solutions deployed today largely depend on proprietary or tightly coupled integrations to identity and access servers that support single sign-on (SSO) functionality and are integrated with portals or Web servers (see Figure 1). While this deployment does not address the issues around all participants in an SOA, this also breaks one of the fundamental premises of a loosely-coupled SOA by tightly coupling SSO solutions to applications that are protected. More importantly, not only is this non-compliant with standards, it also eradicates the value and corresponding technical and business benefits of adoption of an SOA.
[FIGURE 1 OMITTED]
In order to break this tight coupling, you need to rethink how Identity and Access services can be deployed as shared infrastructure services. Such an Identity service easily plugs into the adopted SOA service bus or messaging standards (such as XML or SOAP over JMS, HTTP, etc.); it is discoverable and addressable, just as is any other service in the enterprise.
Who Knows “Who is Who” in an SOA?
The establishment of the SOA-enabled Identity authority addresses the fundamental question of “who knows who is who” in the distributed network of applications, users, devices, and services. This authority acts as an authoritative SOA “system of record” that is not only an authority on all legitimate participants in the application network, but that can also manage and validate credentials associated with each of the participants in the SOA. This is the single logical authority that validates “who is who” in the SOA.
The legitimacy of each entity participating in an SOA is established by a Web service–enabled Domain Identity Service that supports authentication and authorization of services and users, while also acting as an attribute authority for all these entities. Existing SSO (Access) and IdM (Identity Management) solutions, put in place for securing Web applications, need to be enhanced with the following two SOA-induced enhancements:
1. Web service enablement of Identity in the form of a Domain Identity Service (DIS)
2. Identity enablement of Web services that seamlessly integrates with the DIS
Deployed in a standards-compliant manner, the shared domain-specific Identity Service becomes a ubiquitously available application-level Identity service analogous to DNS for Naming in the lower levels of the networking stack.
Web Service Enablement of Identity (DIS)
While establishing the security blueprint for SOAs, architects should explicitly address the following concerns:
1. How can IT directly address the business need of defining, tracking, and enforcing access to cross-domain business services?
2. How can IT help reduce business operational risk by eliminating vendor lock-ins via proprietary protocols in the enterprise backbone (especially for critical Identity-related services)?
3. How can IT architect better control, availability, and visibility into service-level access-related events that can be achieved only with standardization of interfaces to critical infrastructure services such as Identity and Access?
Web service enablement of Identity and its resultant deployment as Domain Identity Services is an approach that assess the above concerns.
DIS can have a significant impact on how securely and effectively applications, people, and devices can interact in an SOA by eliminating the otherwise proprietary protocol exceptions necessary to leverage the IdM and Access solutions. A loose, yet similar, analogy exists in the traditional world of systems networking, wherein an ubiquitous DNS service that is an authoritative naming authority significantly enhanced the value of the networked machines by simplifying addressability (as names rather than numbers), providing a scalable cross-domain architecture for addressing and increasing the value of networking these systems.
Similarly, in the DIS model, enterprises should view identity as a service that is ubiquitously available (as a shared infrastructure service necessary for application networking), rather than as being managed by a server (such as an Authentication or Access server). However, unlike a simple DNS-like naming authority, DIS acts at the application (or service) level and takes on a more complex role of not only being an attribute authority, but also supporting authoritative validation of named entities participating in an SOA, federation across domains, and token exchange.
DIS supports the following core interfaces:
* A SOAP/XML registration interface to manage entities (at a minimum, Web services and users) that are to participate in the SOA
* A SOAP/XML interface for querying attributes associated with entities
* A SOAP/XML interface for authentication and access queries
Plus:
* It should be deployable in a federated environment with support for SAML and WS-Federation
* It provides extensibility to support Security Token Service functionality (such as support for WS-Trust)
[FIGURE 2 OMITTED]
Each of the core interfaces of the DIS is available as services, via individually addressable Web services in a standards-compliant manner. These services should be part of the SOA infrastructure, having been established by enterprise architects, and should be securely reusable by any application or service connecting to the same domain. Cross-domain security is transparently handled by the local DIS through communication between multiple DISs via standards such as WS-Federation.
DIS Functionality
In order to support all of the requirements listed above, the DIS should support both an extensible data model that allows for the management of various types of identities beyond the identity of people, and a well-defined functional interface via a documented protocol utilization, which can be queried for decisions or actions on behalf of an identity.
Data Model
A DIS manages various entity types (such as users, services, applications, devices, etc.) that are all associated with the metadata required for validation of a claim of identity, the types of tokens associated with the identity, and the arbitrary metadata that is specific to the type of entity under management. In addition, a set of entities (such as a list of unique users, applications, devices, etc.), each of which belongs to one of the entity types, is stored and managed by the Identity Authority Service.
Functional Interface
The functional interface to this service exposes four types of operations:
1. Administration
2. Issuance
3. Validation
4. Exchange
Administration: Allows administrators to provision new Identity types and Identities supporting the complete life cycle, including all the customary CRUD (Create, Read, Update, Delete) functionality, in a delegated and federated manner (see Figure 3).
[FIGURE 3 OMITTED]
Issuance: Given a claim, the DIS service returns a token in some configurable form that can later be presented by the holder of the claim to gain access to services in the SOA network (see Figure 4).
[FIGURE 4 OMITTED]
Validation: Given a token, the DIS returns a decision on whether the owner of the token is allowed to perform a function in the SOA network–including continued access to the application, or authorization to specific operations in the network (see Figure 5).
[FIGURE 5 OMITTED]
Exchange: Given a token, the DIS returns a token of an alternate form, enabling the support for heterogeneity in token formats within and across SOA networks (see Figure 6).
[FIGURE 6 OMITTED]
Standards such as WS-Trust and SAML provide the ideal interfaces to expose DIS service functionality for the issuance, validation, and exchange of tokens. Standards around the administration of different identities do not exist, but can be exposed via customizable SOAP interfaces.
Identity Enablement of Web Services
Once the DIS is put in place, the deployment architecture should support a declarative mechanism to enforce the use of the DIS services without developer involvement. In this model, all inbound messages to a Web service are automatically intercepted and authentication and authorization rules are enforced by leveraging the DIS via standard protocols. This level of seamless use of Identity services constitutes Identity enablement of Web services.
As enterprises roll out Web services, they are often challenged by reasoning about the identities of applications or other Web services that are actually invoking the service via the published service interface; this is unlike the previous Web situation in which end users were typically involved in presenting credentials via browser forms in order to authenticate and get access to a URL. In the case of applications invoking services, the following issues need resolution:
1. How does a consuming application securely bind itself to its credentials?
2. How does this application communicate its credential for authentication to the Web service being consumed?
3. How does the recipient service validate the credentials and access rights of the application trying to invoke an operation on the service?
4. How do you support cross-domain Web service interactions?
Table 1 shows a simplified comparison between the process of protecting Web services in an SOA and the process that comprises traditional SSO solutions commonly deployed for protecting Web sites.
There are additional considerations that need to be incorporated into the solution. In many practical deployment situations, services do not always authenticate and authorize other services only. Instead, they may need to authenticate or authorize the end user, consuming application, or a combination of both.
As shown in Figure 7, Identity-enabled Web services can handle different types of subject credentials, depending on trust relationships. The three primary types of credentials used to validate access to a service are:
1. End-user credentials that are required for authentication of end users at the Web service. Independent of the path through which the user transaction indirectly reaches the service, the policy enforcers extract the credentials from configurable locations associated with the context of the message, and authenticate and authorize service access using the DIS.
2. If the service has a trust relationship with another application (such as a portal or a partner application) established via mutual trust based on X509 certificates, the service needs to only authenticate the application accessing the service, rather than the end user. End-user identity may be passed along in the message context (via SAML assertions, SSO cookies, etc.) for authorization purposes, but there is no need for user credentials to be propagated beyond the application that the user directly accesses.
3. In certain situations, the service may require both the consuming application and user credentials, and in this scenario, the policy enforcer is configured to both look for credentials and perform appropriate access controls.
[FIGURE 7 OMITTED]
In all these cases, if an SAML token or an SSO cookie is not already present, the policy enforcer may optionally insert such a token for future downstream use of the token for reduced sign-on needs. In certain other situations, fine-grained authorization needs may require communication with the DIS for querying subject attributes for further rule processing via pluggable entitlement engines.
By centrally managing both user and application identities in the DIS, the policy enforcers do not have to worry about separate infrastructures for allowing access based on user or application Identities, thus simplifying deployment and easing auditability of access to services.
Summary
Enterprises should view identity-enabling Web service and Web service–enabling identity as two sides of the same coin that forms the cornerstone on which to develop a strong security foundation for an SOA. By viewing Identity across the domain as a service that is ubiquitously available, enterprises can better handle the management of proliferating services in an SOA while meeting governance requirements and setting the right scalable architecture in place for the long-term reliance on identity as a core business asset.
Business Benefits of Service Enabling Identify
1. A greater level of business-process agility is achieved by providing a mechanism to more quickly and securely monetize new business services and processes without tight couplings
2. Operational risk is reduced due to the elimination of vendor-specific protocol in the integration backbone
3. Governance is improved due to better auditability of authentication and authorization of service interactions
IT Benefits of Service Enabling Identity
1. Provides the ability to leverage existing WSSO investment by simply SOA enabling Identity without mandating SAML
2. Allows for the coexistence of existing deployments (for existing applications) while providing a means to deploy and support a productized DIS
3. Offers standards compliance with out-of-the-box support for SAML and WS-Security
4. Allows for the easy customization of DIS to enterprise XML/SOAP standards without custom coding
Table 1 Protecting Web Services in an SOA versus traditional SSO
solutions
Web Sites Web Services/SOA
Entities (people) bind to All SOA components (services) are
a protected private secret associated with a unique Identity that
(in the form of a password) is also registered in the DIS. In the
and to a public identity absence of a DIS, a “ghost” user that
(in the form of a username represents the component is created in
or e-mail address, etc.) the same IdM solution used for managing
people identities. The private and
public information associated with the
application component is communicated to
the administrator of the service, who is
responsible for making it accessible to
the service–in many situations doing
so by further protecting the application
credentials with administrator
credentials (such as password protection
or encryption of the application
credentials)
Credentials are typically Credentials are inserted by a
communicated as username/ client-side agent or by the consuming
passwords, propagated as application into HTTP headers or
http headers over a secure preferably as tokens in the WS-Security
transport (such as SSL) headers (or occasionally custom SOAP
header variables), such as username
token, binary tokens (for X509 certs or
proprietary SSO tokens), or SAML
assertions, etc.
A Web server plug-in Credentials or claims are validated by a
extracts the credentials service-side policy enforcer (such as
from the header and invokes Gateway or an agent) that extracts the
an Access server that credentials/claims from con?gurable
validates the user header variables and queries the DIS for
credentials, and on success an authoritative response for
returns an SSO token for authentication or authorization
future use
Integrate with an SAML Integrate with an SAML service
service supporting browser supporting WS-Security profile.
and artifact profiles. Full-fledged federation via
Full-fledged federation via WS-Federation
WS-Federation
Sekhar Sarukkai is currently a technical architect at Oblix. He was the original founder and CTO of Confluent Software, a leading Web services management company, which was acquired by Oblix in 2004. Sekhar holds a PhD in computer science from Indiana University.
ssarukkai@oblix.com
COPYRIGHT 2005 Sys-Con Publications, Inc.
COPYRIGHT 2005 Gale Group
