WSO2 SOA Enablement Server Web Services Security framework enables the developer to implement secure Web services. By "secure," we mean that the developer is provided with enough functionality to create Web services that use authentication, authorization, message integrity checks and other essentials. The WSO2 SOA Enablement Server for Java Security API is independent of the underlying security mechanism used.
This section provides a basic introduction to Security and the terminology used in the rest of this section. If you are already familiar with basic security principles, you might want to skip to the section WSO2 SOA Enablement Server Security Framework Overview.
Enterprises are increasingly dependent on information systems to support business activities. Compromise of these systems, either in terms of information loss and inaccuracy, or competitors and others gaining unauthorized access can be extremely costly.
With the emergence of new technologies like Web services, it is even more important to ensure that the use of these technologies, to extend the functionality of existing information systems, does not make the system more vulnerable to security breaches.
As there are more places where a system can be attacked, distributed systems are more vulnerable to security breaches than traditional single server deployments. As Web services can be viewed as a distributed system, it is necessary to emphasize security solutions which take into account the system's inherently distributed nature.
Security protects an information system from unauthorized attempts to access information or interfere with its operation. It is concerned with:
Confidentiality - Information is disclosed only to users authorized to access it.
Integrity - Information is modified only by users who have the right to do so, and only in authorized ways. Information is transferred only among intended users and in intended ways.
Accountability - Users are accountable for their security-relevant actions. A particular case of this is non-repudiation, where responsibility for an action cannot be denied.
Availability - Use of the system cannot be maliciously denied to authorized users.
Security is enforced using security services as described below. In addition, there are constraints on how the system is constructed. To offer one constraint example, this might mean ensuring adequate separation of objects so that they do not interfere with each other and separation of user duties so that the damage an individual user can do is limited.
Security concerns are pervasive, affecting many components of a system, including some that are not directly security-related. Also, specialist components, such as an authentication service, provide services that are security-specific.
The following list enumerates the most common threats encountered in a distributed information system:
An authorized user of the system gaining access to information that should be hidden from that user.
A user masquerading as someone else obtaining access to whatever that second user is authorized to do. This results in actions being attributed to the wrong person. In a distributed system, a user may delegate his rights to a service that might act on his behalf. This adds the threat of rights being delegated too widely, again causing a threat of unauthorized access.
Eavesdropping on a communication line to gain access to confidential data.
Tampering with communication between objects: modifying, inserting, and deleting items.
Lack of accountability due, for example, to inadequate identification of users.
Security breaches caused by analyzing the traffic between machines.
Denial of Service by curtailment or removal of system resources from authorized users; for example, network flooding.
To protect against computer and communication compromises, computer systems typically provide the following security services:
Authentication - Providing authentication of principals; required for authorization and accountability.
Authorization - Protecting system resources against unauthorized use.
Data Confidentiality - Protecting data from unauthorized disclosure.
Data Integrity - Protecting data from unauthorized modifications.
Non-Repudiation - Providing proof of message origin and delivery.
The WSO2 SOA Enablement Server Security Framework provides the following security functionality elements:
Identification and Authentication of principals (human users and objects that need to operate under their own rights) to verify they are who they claim to be.
Authorization and Access Control - deciding whether a principal can access an object. This is normally done by matching the identity and/or other privilege attributes of the principal to the control attributes of the target object. "Role", "Groups", and "Security Clearance" are all examples of principal privilege attributes. Target object control attributes specify the principals or principal attributes required for access.
Security of Communication (between Web services, which is often over insecure lower-layer channels) - Communications security requires that trust be established between the client and target, which may also require authentication of clients to targets and authentication of targets to clients. It also requires integrity protection and, optionally, confidentiality protection of messages in transit between objects.
Administration - of security information, a security policy, for example, is also needed.
This visible security functionality uses other security functionality such as cryptography, which supports many of the other functions, but is not visible outside of Security services. No direct use of cryptography by application code is necessary to use WSO2 SOA Enablement Server security and no cryptographic interfaces are defined.
The WSO2 SOA Enablement Server Security framework consists of many interconnected pieces, which can be divided into three main categories. WSO2 SOA Enablement Server Security Categories shows these categories and their relationships.
Web Services Security - Security features provided by Web services which are accessible using SOAP.
XML Security - Security features which are based on XML.
The following features belong to this category: Secure Assertions Markup Language (SAML ) library, XML Signature and XML Encryption, WS-Security and XML Key Management Specification (XKMS ).
Low-level Security - Security features and technologies necessary to the implementation of the other two categories. These form the foundation of the WSO2 SOA Enablement Server Security Framework.
The WSO2 SOA Enablement Server package currently makes available security providers for SSL, GSS-API, HTTP Basic and Digest Authentication in the context of the WSO2 SOA Enablement Server Security API. Other technologies in this category include Kerberos, JAAS, JCE, X.509 Certificates support (including support for CRLs, LDAP, PKI), Protected Store including Key Store and User Store and special WSO2 SOA Enablement Server Security API classes.
Figure 2 shows the overall architecture of the WSO2 SOA Enablement Server Security Framework.
The main goal of the WSO2 SOA Enablement Server Security API is to provide an easy-to-use and comprehensive API that covers the most important aspects of application-level security. This API is able to accommodate different security mechanisms without changes to the API or the application implementation code.
The org.idoox.wasp.WaspSecurity provides all necessary authentication and authorization operations that are related to Web services.
The API reuses many existing Java Security APIs. For example, it leverages the Java Authentication and Authorization Service (JAAS) and the Java authorization model.
From the security mechanism point of view, the Security API provides a way to implement additional security providers.
The main aspects of application security covered by the WSO2 SOA Enablement Server Security API are:
Authentication
a mechanism-independent way to obtain credentials
integration with JAAS
mapping of security mechanism-specific principals to WSO2 SOA Enablement Server principals means authorization is independent of the authentication mechanism
custom identity database, to leverage an existing authentication infrastructure backed up by Microsoft Active Directory, iPlanet Directory Server and Relational Databases
used within communication
Authorization
provide a consistent model to make authorization decisions (either using Java SecurityManager and AccessController or our own API provider)
custom authorization providers, to allow the creation of customized decision objects (for example, to leverage an existing authorization infrastructure)
Data Confidentiality and Integrity
provided by security providers, by leveraging WSO2 SOA Enablement Server header processors and transport interceptors
specified on a per-Web service basis with the possibility to set provider-specific parameters for each Web service endpoint or Web service client
Security Management
API for identity database management, including an API for mapping to WSO2 SOA Enablement Server principals from mechanism-dependent principals
API for management of Web service endpoint security requirements
API for security preferences
API for authorization policy modification
management of security messages