Chapter 1 Seeing the Big Picture

Sun OpenSSO Enterprise 8.0 provides secure and centralized access control and single sign-on (SSO) in a unified solution. OpenSSO Enterprise is one component of the Sun Identity Management infrastructure. The Sun Identity Management infrastructure enables your organization to manage secure access to web applications and other resources both within your enterprise and across business-to-business (B2B) value chains.

This chapter provides an introduction to the core OpenSSO Enterprise functions that will form your deployment. The information in this chapter is designed help you envision how OpenSSO Enterprise can meet your business needs. Topics contained in this chapter are:

• Understanding Identity and Access Management

• Leveraging Identity Federation

• Securing Web Services

• Using Identity as a Service

Understanding Identity and Access Management

The growing number of web-enabled applications and the changing roles of different user communities creates challenges for the modern enterprise. These challenges include controlling access to network resources, maintaining the consistency of user identity between different applications, and making new applications easy to manage.

Companies typically develop and implement network applications in individual silos. Each application is deployed with its own provisioning and identity-management interfaces, and with its own security systems. This method of deployment results in a heterogeneous environment with no centralized management systems and no flexibility to scale as the enterprise changes. The silo approach to deployment can negate the benefits of Internet applications, and instead increase the costs of deployment, administration, and ownership. The silo approach can also expose the enterprise to security risks.

As companies deploy electronic business applications and services, management costs for existing information technology systems escalate. Identity information and security policies are distributed across many applications, and repositories are controlled by a variety of internal and external groups. The need for more flexible access and stronger security is hampered by administration redundancies. Administration redundancies can result in inconsistent identity data across the enterprise, increased operating costs, and an ad hoc security strategy.

OpenSSO Enterprise can help to ease the problems associated with the silo approach to deployment.

Dealing with Widely Distributed Identity Information

Environments with disparate sources of identity information have different approaches for organizing user entries, security practices, access control, and other essential aspects of information architecture. As complicated as internal identity issues can be, identity management issues also extend outside the individual enterprise. Enterprises with affiliate business and consumer relationships potentially have user populations that reach into the tens or hundreds of millions. You can use OpenSSO Enterprise in a federated identity management model to manage your business affiliate's users, and to ensure efficient and secure operating policies between your company and its business partners. The enterprise must also extend privacy and ease of use to the consumer and must consider the scalability requirements necessary to effectively manage hundreds of millions of users

Eliminating Ad Hoc Security Strategies

When new applications are deployed without a common identity infrastructure, security decisions are often made in an ad hoc manner by developers and system administrators. Line-of-business managers cannot ensure that the right people see the right content at the right time. Managers must enforce security policies centrally and apply them locally. Security policies define how users are identified or authenticated, and also which users are authorized to access specific information.

Some services or transactions require stronger forms of authentication than others. For some applications, a name and password might be sufficient. Other applications, for example, those that enable high-value financial transactions, can require increased levels of security. These stronger levels of security can be in the form of a digital certificate and personal identification number (PIN), depending on the information and transactions involved.

Authorization to view certain uniform resource locators (URLs) should be restricted to different sets of users based on the users roles. When roles change, changes to privileges should be propagated across all systems. For example, when an employee changes departments or leaves the company, information about that user should be modified or deleted across all accounts immediately. Inconsistent processes for account deactivation is one of the major security risks that enterprises face every day. When you develop applications with your own individual security and access controls, OpenSSO Enterprise provides a centralized security policy and infrastructure to mitigate the risks from both internal users and external threats.

Reducing Operational Inefficiency

Scattered identity data, duplication of identity infrastructure functions across multiple applications, and random security contribute to operational inefficiencies across the enterprise. As companies bring new applications and services online, they often create a separate identity infrastructure for each one. This duplication of effort increases costs, delays time to market, and reduces revenues.

New applications must be able to leverage the identity infrastructure easily and quickly, without affecting how existing services or systems work. As your company delivers new products and services, you can count on OpenSSO Enterprise to update role definitions and access privileges across multiple partners, suppliers, and customers. OpenSSO Enterprise provides an integrated identity management infrastructure solution that delivers economies of scale that lead to better overall operational efficiencies.

Enabling Effective Access Management

When you use OpenSSO Enterprise to extend your current infrastructure, you can bring together disparate identity data into a managed network identity to better serve customers, suppliers, employees, and partners.

• For the enterprise, network identity enables employees who have single sign-on (SSO) capability to access disparate applications, such as benefits registration and provisioning. At the same time, network identity simplifies integration between applications, and sets security levels across all of them.

• For customer management, network identity can assist in capturing customer interactions. This ensures tighter one-to-one relationships, including access to custom offerings, affinity marketing, and data mining.

• For the business partner, network identity helps provide integrated enterprise relationships with reduced risk of fraudulent transactions.

Common identity infrastructures enable administrators to consolidate redundant tasks that normally occur across many applications by multiple administrators. This consolidation of administration makes it possible to consistently delegate management tasks to partners, customers, and internal company departments based on business requirements. The result is an environment that is integrated, flexible, easy to manage, and secure. Security implementations and access control rules that are typically contained within each application can be consolidated to provide centralized authentication and authorization to resources.

The transition to an intelligent applications infrastructure requires you to implement a system that incorporates access management and user management. This implementation lets you centralize the administration or management of user identity and security policy information across multiple resources and enterprise applications. You can expect to respond to the ever-changing network environments and applications with an integrated, cost-effective solution.

Leveraging Identity Federation

Identity federation enables partner organizations to trust and share digital identities and attributes of employees, customers, and suppliers across domains. Identity federation is the means to providing single sign-on among partner sites.

Through identity federation, transactions involving multiple organizations can be managed and completed using a single identity. Customers or members can access a variety of online services through just one organization, using just one password. And employees of that organization and its partners can be given secure, as-needed access to selected information on partner sites. A federated identity allows a user from one federation partner to seamlessly access resources from another partner in a secure and trusted manner.

Why We Need It

Industries such as telecommunications or financial services are eager to meet customers' demands for online services. To meet these needs, companies seek partnerships with other companies to deliver the widest variety of services to customers. The growing customer demand for everything from ringtones to on-demand video, from online banking to investments, and much more requires partners to join forces to compete successfully.

How It Works

Service providers and other companies have agreed to a common set of rules for sharing identity information securely and privately. Identity federation is based on these standards. They allow multiple partners to access one personal identity on multiple sites at the same time and to authenticate that identity in order to deliver services securely. A common set of standards allows partnerships to repeat the same information-sharing processes with every partner. Otherwise, anytime a company wanted to create a partnership, it would have to create a whole new set of processes, based on the prospective partner's IT infrastructure, security policies, and other unique characteristics. This quickly becomes impossible as the number of partners increases. But with standards, the ability to partner is infinitely scalable. Using federation standards, organizations can create circles of trust in which a given provider at the center of the circle, such as an wireless provider, is surrounded by and connected to a multitude of other companies that offer value-added services the provider wants to deliver to customers.

How Identity Federation Can Benefit Your Business

The following are ways in which OpenSSO Enterprise identity federation can create a wide variety of new business opportunities for your company.

• Creates new revenue streams

  Identity federation means being able to create new sources of revenue by quickly meeting customers' ever-growing demand for online services. In addition to applying a standard set of protocols across partner domains, identity federation automates many manual processes within a secure identity framework, helping to deliver revenue-enhancing services to customers more quickly

• Improves allocation of resources

  Some organizations may want to outsource certain operations so that they can focus their resources on core competencies. Identity federation enables organizations to easily turn over such operations to partners without fear of breaching information security or privacy.

• Reduces operational cost and complexity

  Identity federation enables organizations to collaborate freely without the cost, complexity, and limitations of compiling and sharing manual lists of users or using proprietary web access management tools. It also makes it easier to ensure the security and privacy of shared information.

• Improves user experience

  Identity federation promotes loyalty by enabling users such as customers, employees, and suppliers to enjoy more services and products, more quickly and easily than ever before. In particular, single sign-on enables an exceptional online experience, eliminating the need to use multiple passwords for access to online services and products.

• Enhances enterprise security

  Identity federation enables employees of partner organizations use only one login. When a user has just one password to remember, he or she is less likely to have two write down that password, thus reducing the risk of the password being used by unauthorized entities.

Securing Web Services

Your enterprise solution must include a means for securing your web services from unauthorized use. OpenSSO Enterprise supports web services security using the Identity Web Services Framework (ID-WSF), part of the Liberty Specification. OpenSSO Enterprise also supports web services security using the Secure Token Service, which is defined in the WS-* Specification.

Web services are self-contained, modular applications that can be described, published, located, and invoked over a network. Web services perform encapsulated business functions, ranging from a simple request-reply to complete business process interactions. Web services based on the following allow data and applications to interact without manual intervention:

• eXtensible Markup Language (XML), SOAP (previously known as Simple Object Access Protocol), and related open standards

• Service Oriented Architectures (SOA)

A typical Web services application consists of a service consumer, a service provider, and optionally a registry for storing the Web services definitions. Web services are accessible over standard Internet protocols that are independent of platforms and programming languages. Web services technology can be implemented in a wide variety of architectures, can co-exist with other technologies and software design approaches, and can be adopted in an evolutionary manner without requiring major transformations to legacy applications and databases.

A number of technologies such as Remote Procedure Call (RPC) Common Object Requesting Broker Architecture (CORBA), Microsoft Distributed Component Object Model (DCOM) have been developed for application integration. However, the web services technology based on XML, SOAP and HTTP(S) has been accepted as an industry standard and has seen wide industry adoption. Interoperability has been a key reason for the success of web services because it is based on open standards. Enhancements to web services should preserve the interoperability and should be based on open standards.

Many of the features that make Web services attractive, including greater accessibility of data, dynamic application-to-application connections, and relative autonomy or lack of human intervention are at odds with traditional security models and controls. Network security technologies such as firewalls are inadequate to protect SOAs for the following reasons:

• SOAs are dynamic and can seldom be fully constrained to the physical boundaries of a single network.

• SOAP is transmitted over HyperText Transfer Protocol (HTTP), which is allowed to flow without restriction through most firewalls.

• Transport Layer Security technologies (like SSL/TLS) and Network Layer Security technologies (like TLS), which are used to authenticate and encrypt Web-based messages, are inadequate for protecting SOAP messages because they are designed to operate between two endpoints.

• SSL/TLS cannot accommodate Web services' inherent ability to forward messages to multiple other Web services simultaneously.

The Web service processing model requires the ability to secure SOAP messages and XML documents as they are forwarded along potentially long and complex chains of consumer, provider, and intermediary services. The nature of Web services processing makes those services subject to unique attacks, as well as variations on familiar attacks. According to WS-I, the top threats facing Web services are:

• Message alteration

  An attacker inserts, removes or modifies information within a message to deceive the receiver.

• Loss of confidentiality

  Information within a message is disclosed to an unauthorized individual

• Falsified messages

  Fictitious messages that an attacker intends the receiver to believe are sent from a valid sender.

• Man in the middle

  A third party sits between the sender and provider and forwards messages such that the two participants are unaware, allowing the attacker to view and modify all messages

• Principal spoofing

  An attacker constructs and sends a message with credentials such that it appears to be from a different, authorized principal

• Forged claims

  An attacker constructs a message with false credentials that appear valid to the receiver.

• Replay of message

  An attacker resends a previously sent message

• Replay of message parts

  An attacker includes portions of one or more previously sent messages in a new message

• Denial of service.

  An attacker causes the system to expend resources disproportionately such that valid requests cannot be met.

The importance of these threats varies depending upon your company's needs and purpose. For most companies, internal messages must be kept confidential and loss of confidentiality is a primary concern. However, many companies offer web services to the public at large. For some services, identity authentication is not a significant concern. For example, a web service provider that serves information about the current weather forecast need not be concerned if a request is from a falsified sender. Regardless, it is important to understand these threats and what technologies are available to mitigate them.

Web Services Security Industry Specifications

OpenSSO Enterprise is based upon the following industry-recognized specifications:

• Confidentiality of Web Service Messages Using XML Encryption

  Produced by the World Wide Web Consortium (W3C). Describes a mechanism to encrypt XML documents.

• Web Service Authentication and Authorization Using XML Signature

  Describes Secure Assertion Markup Language (SAML) and eXtensible Access Control Markup Language (XACML) as proposed by the Organization for Advancement of Structured Information Standards (OASIS) group. SAML and XACML provide mechanisms for authentication and authorization in a Web services environment.

• Integrity of Web Service Messages Using XML SignatureProduced jointly by the W3C and the Internet Engineering Task Force (IETF). The power of XML Signature is in it ability to selective sign XML data.

• Web Services (WS)-Security

  Produced by OASIS. Defines a set of SOAP header extensions for end-to-end SOAP messaging security. WS-Security supports message integrity and confidentiality by allowing communicating partners to exchange signed encrypted messages in a web services environment.

• Security for Universal Description, Discovery and Integration (UDDI)

  Produced by OASIS. UDDI enables web services to be easily located and subsequently invoked. Security for UDDI enables publishers, inquirers and subscribers to authenticate themselves and to authorize the information published in the directory.

Security Infrastructure Requirements

In a simple web service transaction, a request is sent from the Web Service Client to a Web Service Provider through intermediaries such as load balancers and firewalls. Similarly, the response from the Web Service Provider to the Web Service Client is also sent through the same intermediaries. In order to protect the web service request, application-level end-to-end security must be enabled in addition to transport-level security.

The following diagram shows a simple web service call between the Web Service Client and Web Service Provider.

Figure 1–1 Simple Web Service Call

In order to secure the message, the Web Service Client must determine which security mechanisms are required by the Web Service Provider. One solution is to pre-configure the Web Service Client with the security requirements for Web Service Provider. Although simple, this approach would not scale and could lead to other misconfigured Web Service Clients.

An alternative architecture for web service security is an architecture based on Security Token Service (STS). The Liberty Alliance Discovery Service and WS-Trust are examples. A security token service that coordinates security-based interactions between a Web Service Client and Web Service Provider.

First, the Web Service Provider registers its acceptable security mechanisms with the security token service. Then, before making a call to the Web Service Provider, the Web Service Client connects with the Security Token Service to determine the required security mechanisms. The Web Service Client might also obtain the security tokens required by the Web Service Provider. Before validating the incoming SOAP request, Web Service Provider checks with the security token service to determine its security mechanisms. The following figure illustrates interactions between the Web Service Client, Web Service Provider, and Security Token Service.

Figure 1–2 Web Service Call with Security Token Service Enabled

Although this security model requires the security token service, it helps in coordinating security mechanisms between the Web Service Client and Web Service Provider. Additionally, it enables runtime decisions for both Web Service Client and Web Service Provider. This makes the configuration dynamic and more responsive than a static configuration. However it does introduce the extra overhead of the Web Service Client and the Web Service Provider to communicating with the security token service. It also introduces the complexities of notification mechanisms when the Web Service Provider changes its security mechanisms. Your decision to either the static or dynamic configuration of Web Service Clients must be based on your deployment environment. The architecture proposed in this document addresses both the scenarios.

Security Token Service

The purpose of the security token service is to orchestrate secure communications between the Web Service Client and Web Service Provider with minimal performance penalties. The following are required for a security token service:

• Interfaces that enable the Web Service Provider to manage its entry, or resource offering. This includes interfaces that enable the Web Service Provider to store supported security mechanisms, and optionally the service end points.

• Interfaces that enable the Web Service Client to query for security mechanisms supported by a Web Service Provider.

• Interfaces that enable a Web Service Client to obtain security tokens for communicating with the Web Service Provider.

Liberty Alliance's Discovery Service and WS-Trust are the emerging standards specifications, and either one can play the role of the security token service. Both the specifications define the wire protocols for the Web Service Client to query and obtain the security tokens to communicate with the Web Service Provider. One important difference exists between the two. The Liberty Alliance Discovery Service provides the interfaces for the Web Service Provider to manage its entry in the secure token service. In WS-Trust specification, the WS-Trust entry is managed by the Web Service Provider itself. The WS-Trust entry is provided to the Web Service Client through a WS-Trust Meta-Data Exchange (MEX) Protocol.

Web Service Client

The Web Service Client which makes the web service call provides support for securing the outgoing communication, and also validates the incoming response for Web Service Provider. The Web Service Client security infrastructure requires the following:

• Configurations to determine STS and credentials to authenticate and obtain WSP resource offerings.

  Optionally there should be provision to statically configure the resource offering locally

• Interfaces to obtain WSP resource offering either from STS or optionally from the local configuration

• Interfaces to secure the request. This could be accomplished by calling the STS for the security token or should be locally generated. The security token generated could be either that of the WSC itself or it could be that of the authenticated entity (impersonalization)

• In addition to adding the security token it should be possible to add additional attributes of the identity, for example roles and memberships

• Interface to validate the response received from WSP.

Two kinds of interfaces are needed at the Web Service Client. One interface is needed for configuration and administration. One interface is used at run time for securing requests and validating responses.

Web Service Provider

The Web Service Provider provides support for validating the incoming request, and also secures the outgoing responses. The Web Service Provider security infrastructure requires the following:

• Configuration for its supported security mechanisms. This configuration can be optionally stored in STS, thereby providing dynamic discovery for WSCs. This is supported by Liberty Alliance's Discovery Service, but it in the case of WS-Trust this would have to locally configured for WS-Trust MEX calls.

• Interfaces to authenticate the incoming request from the Web Service Client

• After authentication, if configured, the Web Service Provider should also authorize the request for the web service operation by calling the policy component.

• Interfaces to secure the response back to the Web Service Client

Similar to interfaces needed by Web Service Client, the Web Service Provider also requires two kinds of interfaces. One interface is needed for configuration, and another interface is needed for validating requests and securing responses. Supporting a Web Service Client and Web Service Provider security infrastructure should be accomplished in either a pluggable manner such that it does not require reconfiguring the existing web services framework. Or it can be accomplished programmatically by calling well-defined interfaces to secure requests and validate responses. Additionally, the infrastructure should enable customers to easily build and configure interoperable solutions using heterogeneous systems.

Using Identity as a Service

OpenSSO Enterprise enables you to use Identity as a Service in your environment. Identity as a Service is a set of reusable, standardized services that provide applications with identity management. Typically based on the service-oriented architecture (SOA), Identity as a Service is system of discrete functional components of identity management. It is derived from the traditional set of functionally overlapping applications such as authentication, authorization, work flow, policy management, attribute management, provisioning, and password management.

The Identity As A Service environment contains these simplified services and makes them openly available to systems and applications. The services exist independently of one another, but together comprise a foundation of identity services upon which the overall IT environment relies. The primary advantage of Identity as a Service model is that the components can work in an independent fashion, or can be coupled together in the manner of an Enterprise Service Bus. Examples of Identity As a Service include:

• Authentication and Authorization Services

• Provisioning Services

• Taskflow/Workflow Services

• Role Management Services

• Audit Services

Simplifying Deployment and System Administration

Identity As a Service provides both IT and business benefits to enterprises. The IT benefits include:

• Easier Administration

  Performing administrative tasks and adding newer tasks is simplified as appropriate modular components can be invoked with ease.

• Flexible Deployment Architecture

  Allows deployments to effectively unify duplicate code and services and put forth a flexible and unified services.

• Simplified Outsourced and Federated Identity and Access Management

  Allows enterprises to leverage and outsource identity management services to system integrators and partners with core competency in the area.

Business benefits of Identity as a Service include:

• Reduced Operational risk and Maintenance Cost

  The Identity services layer is useful when adding new applications or services to an existing deployment, reconciling different identity management solutions acquired through mergers and acquisitions. It also allows you to centralize various Identity Management functions such as access management, resulting in reduced operational risk.

• Increased compliance

  With all applications using the same set of auditing services, audit log aggregation, and detection of violations of regulatory compliance, rules become easier to manage. With a common policy framework that spans applications, Identity as a Service simplify the management and improves the enforcement of complex segregation of duties policies.

• More Business Insight into Identity Management

  The traditional developer centric nomenclature used in identity management products has long been found hard by common users. With prevalent use of Identity As A Service and easy to use available interfaces, the deployments will be simpler to manage.