Web Services and Identity Management

Web Services technology is a collection of standards and protocols designed to

• reduce the amount of work it takes to accomplish integration (and thereby reduce cost and schedule), and

• provide flexible interfaces between systems that won't “break” when one system or the other is updated or revised.

IT departments are already using the Web services approach to integration because it has many advantages over previous approaches, and now physical security systems are beginning to use Web services to connect to other systems as well.

This is creating an interesting circular relationship between Web services and identity management systems. As companies integrate more business applications using Web services, they find that establishing identity management is a critical prerequisite. And if they decide to implement a fully integrated, central identity management system, they find that Web services is the best way to integrate it with their various business applications and systems.


More Integration Means More Complexity

Companies that use Web services to expand the integration of systems across the enterprise quickly realize that the integration brings with it a new layer of management requirements. First, they need to manage “who can do what” with the new business applications. That involves information security and a way to manage user identities and privileges. Second, now that computer systems can easily talk to each other, it is important for the systems to have a reliable way of identifying just who they are talking to (the identities of other computer systems).

Additionally, business managers need to establish which systems can or can't have particular kinds of conversations (managing privileges of computer systems). This is where identity management systems come into the picture. An identity management system (IDMS) can be used to manage the identities and privileges of computer systems as well as people. Thus most significant deployments of Web services for corporate information systems will sooner or later result in the deployment of an IDMS.


Why an IDMS?

The implementation of an enterprise-wide identity management system is of great interest to corporate security for several reasons.

• An IDMS will close IT security gaps related to enrolling and terminating employees.

• The deployment of an IDMS is typically accompanied by a role-based access control (RBAC) scheme for the information systems. Once roles are jointly defined by human resources and business managers, and once IT security privileges are assigned to the roles, security privileges can be automatically granted upon enrollment in the IDMS. Privileges are also automatically changed when an employee's position changes, and revoked automatically upon the employee's termination.

• Physical security can leverage the defined corporate roles by defining access control privileges to match, aligning physical security more tightly with the organization's job roles. This doesn't require the access control system to be integrated to any other system.

• Physical security can leverage the HR enrollment of employees by integrating the physical access control system (PACS) with the IDMS, so that access control privileges are managed automatically along with IT privileges as HR enrolls, re-assigns and terminates employees.

Using an IDMS as a common point of reference, physical and IT access control can be synchronized. And using role-based access control to establish privileges based upon job functions, both physical and IT access control can be policy-driven.

Even if no identity management system is used and the physical and IT access control systems are not integrated with each other, RBAC can be used in both physical and IT systems to provide a policy-driven access control approach that aligns with the organization. Maintaining this scheme requires more human attention than with integrated systems. On the other hand, it does strengthen security while making it very manageable and auditable.


Following in Federal Footsteps

The federal government recognized the importance of fully integrated identity management in its guidelines for the personal identity verification (PIV) systems mandated by Homeland Security Presidential Directive (HSPD) 12. HSPD 12 requires that a single smart card credential be used for both physical and IT security across federal agencies.

To help federal agencies roll out their PIV systems, the Federal Identity Credentialing Committee (FICC) recently developed a 194-page book entitled Federal Identity Management Handbook. The handbook states that authentication programs would be at their strongest if physical and logical security applications were integrated. “If the back-end databases that support the applications could be integrated, an agency could benefit from consolidated security management, faster response rates, improved detection and audit control, and uniform policies” (p125). Identity management systems available today can provide this kind of integration.

The handbook goes on to state that with the help of database partitioning, various departments “can retain their autonomy and still integrate their data by maintaining a common centralized identity management network” (p126). Figure 1, which is taken from the Federal Identity Management Handbook, diagrams the functional roles in such an integration for an identity management system, a PACS, an HR system and an information security system. The physical security system shown in Figure 1 could consist of a single manufacturer's integrated security system with badge production and access control capabilities, or it could be a combination of separate security products. Of course this architecture isn't restricted to government systems. Any medium or large organization could benefit from this approach.


Full Integration with Web Services

Web services will be the easiest and most affordable way to integrate one or more PACS to an IDMS, enabling enterprise-wide, policy-driven access management. While Web services technologies and standards are still evolving, most of the challenges that remain are in the realm of Internet-based services intended for widespread general use and business-to-business e-commerce. Web services can be used now for integrations that are narrow in scope, such as those depicted in Figure 1.

Even though only a few access control systems today offer Web services integration, the Web services approach can still be used as illustrated in Figure 2. A Web services “wrapper” can be used as appropriate for the various access control system interface capabilities. (A wrapper is software code that changes an existing interface to an application without substantially increasing its functionality.)

Table 1 lists the currently available interfaces from many of the access control system manufacturers. Not shown in the table are future interfaces and the specific types of APIs. Most of the manufacturers who have XML interfaces but don't yet have Web service interfaces currently have them under development. Several manufacturers who don't currently have XML or OPC interfaces have them under development. Some have multiple API interfaces for specific functions such as HR, payroll and ERP systems. A checkmark in the API column usually represents more than one interface.


Need-to-Know Terms and Concepts

While it is not necessary for security practitioners to delve into the technical details of Web services, some technical aspects of Web services are likely to come up when the conversation turns to that subject. Here are a few basics that may be helpful to know.

Web services technology is being used to address business needs in following ways:

• Enterprise Application Integration (this is the category for PACS and IDMS integration)

• Improved Application Development Efficiency Business Partner Integration (suppliers, distributors, channels, etc.)

• Web Portal Integration, Business Activity Monitoring

• Extended Functionality for Web Applications

The case studies most commonly published fall into the last three categories.


Web Services vs. Web Service

So far in this article we've referred to “Web services” (plural), a set of standards and protocols that eases integration between systems and applications. “Web service” (singular), on the other hand, refers to (a) an interface to an application that is presented using these standards and protocols, where the application has other types of interfaces also; or (b) to an application itself whose sole interface is a Web services interface. A Web service:

• is implemented using XML (eXtensible Markup Language), which is the data format for passing messages between applications. This is a basic element that won't change.

• uses a Web services description language (WSDL, pronounced “wisdel”). This allows Web service applications to publish to each other what information they can provide and how to request that information.

• typically uses Simple Object Access Protocol (SOAP) to package messages sent between applications—but could use other technologies. (This is important primarily to the programmers integrating the systems.)

• is typically implemented using Microsoft's .NET (pronounced “dot net”) technology or Java 2 Enterprise Edition (J2EE). The decision about which of these to use depends upon who is doing the integration and the requirements of the applications.

• uses the relatively new Universal Description, Discovery and Integration (UDDI) standard, which is a specification for using XML to provide a registry that lists available Web services and how to interact with them. (This is very helpful in the integration of a large number of systems.)

• provides a high degree of interoperability because XML is a universal language, enabling a wide variety of systems to communicate easily, whether based on Windows, Unix, Linux or another operating system.


Planning is the Key

Identity management system initiatives require significant planning. Planned well and run well, they take two to three years to execute for medium and large enterprises. It is wise to incorporate the physical security elements when initial budget and resource allocation estimates are made. This will usually be one or two years prior to the physical security system integration.

In such planning, it is important to include not only the physical security integration but the physical security strategy, policy and procedure development, which should be done in concert with the IT security planning actions along the same lines. These elements are much more important than any detailed discussions about Web services or other technical issues.

Physical security practitioners who hear or read that an identity management initiative is on its way should recognize that if discussions aren't already underway, it's time to begin a dialog with their IT security counterpart and the CSO, if the organization has one. Together you can determine how best to take advantage of the convergence opportunity that Web services and an identity management initiative provide.


Ray Bernard, PSP is the principal consultant for Ray Bernard Consulting Services (RBCS), a firm that provides high-security consulting services for public and private facilities. He is a technical consultant and writer who has provided pivotal direction and technical advice in the security and building automation industries for more than 17 years. This article is based upon material in Mr. Bernard's upcoming book, Shifting Sands: The Convergence of Physical Security and IT. For more information about Ray Bernard and RBCS go to www.go-rbcs.com or call 949-831-6788.