In this chapter we will cover:
- Restricting a composite to authenticated users with HTTP Basic Security
- Creating a new, group-based authorization policy
- Restricting a composite to authorized users
- Adding keys to a credential store
- Invoking an HTTP Basic secured web service
In this chapter, we will examine recipes that allow us to secure composites or to invoke secured web services.
Oracle Web Services Manager (WSM) is the component that is used by SOA Suite to act as the policy manager and enforcement agent. WSM is installed as an integral part of SOA Suite.
When dealing with secured services, it is useful to know the terms that are used. The definitions that follow are those needed to understand how security works in SOA Suite. If this were a cookbook on identity management, then we would need to be more precise.
A user is a person or application program. Typically, the user and their associated attributes, such as credentials (see next section), are stored in an LDAP directory such as Oracle Internet Directory or Microsoft Active Directory. The default store is the internal WebLogic LDAP directory.
A credential is the token used for validating the identity of a user. This may be a password or the public certificate for a user.
A principal can be a user or a computer system. A principal is the combination of a user and a validated credential for that user, and the authenticated resource that is requesting access to a service.
A role is an abstract name given to a set of permissions required to access a resource. It is normally granted to a user or a group.
Authentication is the task of verifying the identity of a user to create a principal, and may be done in a variety of ways, including, but not limited to, a password, a client certificate, or a Kerberos token. Multiple methods of authentication (multifactor authentication) may be required for this.
A policy is a collection of security steps or assertions that are applied to an endpoint, which may be a service or a reference endpoint.
The basic security model goes through the following steps:
- A service request is constructed by a client.
- The client adds the user identifier (username) and credentials (a password for example, usually encoded).
- The service request is received by the service.
- The service validates the credentials against the provided user identifier, and if they are valid, creates a principal.
- The service validates that the principal is authorized to access the service, usually by checking that the principal has been granted the required role.
- After authenticating and authorizing the principal, the request is acted upon by the service.
Note, that in this sequence, we have not identified if SOA Suite is the client or if it is providing the service. If SOA Suite is providing the service, then security policies are enforced when the request is received and the policy was applied to a service. If SOA Suite is invoking a service, then the security policies are enforced when the request is sent and the policy is applied to a reference.
The identity store holds details of users and their associated credentials, groups, and roles. The identity store is provided through Oracle Platform Security Services (OPSS) and is usually an LDAP server, either the embedded LDAP in WebLogic or an external LDAP, such as Oracle Internet Directory or Microsoft Active Directory. The identity store is configured at the application server level. WebLogic may have multiple identity stores, but WSM just uses the first unless the Oracle Virtual Directory flag is set. The identity store is where the users, groups, and roles are stored.
The policy store holds the web service manager policies that may be applied to composites. At runtime, the policy store is maintained in the Meta-Data Repository (MDS). At design time, the policy store may be held in the filesystem locally to JDeveloper, or JDeveloper may reference MDS.
The credential store holds the credentials required to construct principals in systems that will be called by SOA Suite.
WSM is not required to provide basic message integrity and security by using SSL. SSL allows the communication between service and requestor to be protected from eavesdropping. At this level, SSL can be thought of as a secure communication channel. By default, a server-authenticated SSL only validates that the server has a certificate matching its hostname, and allows for encryption of all traffic between the client and the server. SSL with client authentication may be used to identify the requestor to the service. This requires client certificates to be kept in the identity store of the target service.
The use of client authentication in SSL can be taken advantage of by WSM, but it still does not identify whether the authenticated client has the right to access a particular service. For this, we require the WSM policies to be applied to the service.
SSL can be used to simplify security by ensuring that communication between machines is encrypted, potentially removing the need for encryption to occur at a higher level. However, there may be a performance penalty associated with this, although most modern processors have special instructions for the symmetric key portion of SSL communication, and the only significant cost these days is in the establishment of an SSL connection in the first place.