| Oracle® Containers for J2EE Security Guide 10g (10.1.3.5.0) Part Number E13977-01 |
|
|
View PDF |
| Oracle® Containers for J2EE Security Guide 10g (10.1.3.5.0) Part Number E13977-01 |
|
|
View PDF |
This chapter provides an overview of security concepts, focusing on the following areas:
These are two basic categories of security that can be independently configured but are often interrelated. The former mostly determines who can access data and what tasks they are allowed to perform; the latter mostly determines the security of data as it is transmitted.
Note that application-level configuration can include transport-level specifications, such as having an application-level constraint requiring Secure Sockets Layer (which is a transport-level feature, discussed later). And transport-level security can also involve authentication (limiting data access to appropriate users), such as when client certification is requested as part of the transport-level functionality.
Application-level security determines who can access an application or its data, and what tasks they can perform. The following topics discuss key areas of functionality:
Authentication deals with the question "Who is trying to access services?" In any system and application it is paramount to ensure that the identity of the entity or caller trying to access your application is identified in a secure manner. In a multitier application, the entity or caller can be a human user, a business application, a host, or one entity acting on behalf of (or impersonating) another entity.
Authentication information, such as user names and passwords, is stored in a user repository, such as an XML file, database, or directory service. When a subject attempts to access a J2EE application, such as by logging in, it is the role of a security provider to look up the subject in the user repository and verify the subject's identity. A security provider is a module that provides an implementation of a specific security service such as authentication or authorization. The Oracle Internet Directory is an example of a user repository.
Although each J2EE application determines which user can access it, it is the security provider that authenticates the user's identity through the user repository.
Authorization regards the question "Who can perform tasks on which resources offered by which components?" In a J2EE application, resources are typically expressed in terms of URL patterns for Web applications, and method permissions for EJBs. Authorization is on a per-role basis, with appropriate permissions being assigned to each defined role in an application.
The following sections discuss types of authorization, or access control, and related topics:
The capability and role-based models are complementary and often used together.
The capability model is a method for organizing authorization information. The Java 2 Security Model uses the capability model to control access permissions. With this model, access control information is associated with a resource, and authorization is associated with an entity (referred to as a "principal", defined in "Principals and Subjects"), such as a user named Amy.
An access control list (ACL) is associated with a protected target resource, such as a directory or file, and contains information about which access rights each user has for the particular resource. Each file in a file system may have an ACL, for example. And the capabilities (privileges) specified in an ACL are associated with particular users, specifying which users have what privileges for the file with which the ACL is associated.
When a user Amy logs in and is successfully authenticated, her permissions are retrieved and granted so that she is free to execute the actions permitted by these permissions—for example, to read from a File1 and write to a File2.
The capability model and access control look at the same information from different perspectives. While a capability is associated with a user attempting to access a resource, an access control list is associated with the resource that the user is trying to access.
Figure 1-1 shows the user Amy having permission to read File1 and write to File2, while a user Brian has permission to execute File1 and read File2. An access control list would come from the perspective of File1 and File2, specifying for each file what users have access and what their specific permissions are. The capability model comes from the perspective of Amy and Brian, specifying for each user what files they can access and what they have permission to do with respect to each file.
Figure 1-1 Access Control Approach Versus Capability Approach
A role is essentially a job function or title that defines an authority level. A role can have multiple users and multiple permissions. Roles are the identities that each application uses to indicate access rights to its different objects and functions. A user assumes a role to gain access to an appropriate set of these resources.
Role-based access control is a JAAS feature that simplifies the management problems created by direct assignment of permissions to users. Assigning permissions directly to multiple users is potentially a major management task. If multiple users no longer require access to a specific permission, you must individually remove that permission from each user.
Instead of directly assigning permissions to users, permissions are assigned to a role, and users are granted their permissions by being made members of that role. Multiple roles can be granted to a user. Figure 1-2 provides an example of role-based access control.
When a user's responsibilities change (for example, through a promotion), the user's authorization information is easily updated by assigning a different role to the user, instead of by updating all access control lists containing entries for that individual user.
For example, if multiple users no longer require write permissions on a file named salaries in the /home/user directory, those privileges are removed from the HR role. All members of the HR role then have their permissions and privileges automatically updated.
A role can also be granted to another role, thus forming a role hierarchy that provides administrators with a tool to model enterprise security policies.
See Also:
Independent of the previously discussed features for authentication and authorization are features for making data secure as it is transmitted. This section provides an overview of features intended to ensure that data transmitted over a network or the Internet cannot be intercepted and read or altered by a third party. OC4J supports secure communications using the HTTP protocol over the Secure Sockets Layer.
The following related topics are discussed here:
The Secure Sockets Layer (SSL) is the industry-standard point-to-point protocol which provides confidentiality through encryption, authentication, and data integrity. Although SSL is used by many protocols, it is most important for OC4J when used with the HTTP browser protocol and in the Apache JServ Protocol link between the Oracle HTTP Server and OC4J processes.
For convenience, this book uses "HTTPS" as shorthand when discussing HTTP running over SSL. Although there is an "https:" URL prefix, there is no HTTPS protocol as such.
Note that whether the server configures SSL communication is independent of whether the client configures SSL communication. In this document, Chapter 15, "SSL Communication with OC4J", covers information about enabling SSL at the OC4J end, and about SSL communication between Oracle HTTP Server and OC4J in an Oracle Application Server environment. Chapter 16, "Oracle Security for Client Connections", covers information about the OC4J implementation of HTTPS that provides SSL functionality to client HTTP connections.
With SSL communication, any of the following authentication scenarios are possible:
No SSL authentication (or null authentication): The server does not send a certificate and does not request a certificate from the client. From an SSL perspective, the server does not know who the remote client is, or accepts any certificate that may be presented by the client.
One-way SSL authentication: Either the server or the client, but not both, requires certificates. "Server authentication", for example, is one-way authentication where the server sends its certificate to the client but does not request a certificate from the client. Alternatively, the server may require a certificate, but does not send one and the client does not require one.
Two-way SSL authentication: This is "client and server authentication", where the server sends a certificate, required by the client, and also requires the client to send a certificate.
Configuring SSL authentication in the server is independent of configuring SSL authentication in the client.
Applications need to transmit authentication and authorization information over the network. A digital certificate, as specified by the X.509 v3 standard, contains data establishing a principal's authentication and authorization information. A certificate contains:
A public key, which is used in public key infrastructure (PKI) operations
Identity information (for example, name, company, and country)
Optional digital rights, which grant privileges to the owner of the certificate
Each certificate is digitally signed by a trust point. The trust point signing the certificate can be a certificate authority (CA) such as VeriSign, a corporation, or an individual.
In SSL communication between two entities, such as companies or individuals, the server has a public key and an associated private key. Each key is a number, with the private key of an entity being kept secret by that entity, and the public key of an entity being publicized to any other parties with which secure communication might be necessary. The security of the data exchanged is guaranteed by keeping the private key secret, and by the complex encryption algorithm. This system is known as asymmetric encryption, because the key used to encrypt data is not the same as the key used to decrypt data.
Asymmetric encryption has a performance cost due to its complexity. A much faster system is symmetric encryption, where the same key is used to encrypt and decrypt data. But the weakness of symmetric encryption is that the same key has to be known by both parties, and if anyone intercepts the exchange of the key, then the communication becomes insecure.
SSL typically uses a combination of asymmetric (public/private key) and symmetric key encryption to secure communications. The exchange of public keys is used for mutual authentication of the parties involved in the communication. This also allows the parties to securely cooperate in the creation of symmetric keys that will be used in further encryption and decryption of data in the session. The following is a basic example of the creation of an SSL session between a client and a server:
The client sends cipher suites, compression methods, highest protocol versions, and random bytes to the server. The server chooses the connection parameters from the choices offered by the client.
The public keys (X.509 certificates) are exchanged.
The server sends the client its public key, and the client sends the server its public key.
The keys are used for mutual authentication where each verifies the certificate of the other.
The symmetric keys are exchanged. Communications are secured in this step using the exchanged public keys.
A master secret is generated cooperatively between the server and client.
Session keys (bulk encryption keys) are then generated based on the master secret, such as a 128-bit RC4 key.
The client and server each sends a message that it will use the session key for further communication.
SSL traffic uses symmetric keys for encryption and decryption.
In SSL the public key of the server is sent to the client in a data structure known as an X.509 certificate. This certificate, created by a certificate authority, contains a public key, information concerning the owner of the certificate, and optionally some digital rights of the owner. Certificates are digitally signed by the CA which created them using that CA's digital certificate public key.
In SSL, the CA's signature is checked by the receiving process to ensure that it is on the approved list of CA signatures. This check is sometimes performed by analysis of certificate chains. This occurs if the receiving process does not have the signing CA's public key on the approved list. In that case the receiving process checks to see if the signer of the CA's certificate is on the approved list, or if the signer of the signer is on the approved list, and so on. This chain of certificate, signer of certificate, signer of signer of certificate, and so on, is a certificate chain. The highest certificate in the chain (the original signer) is called the root certificate of the certificate chain.
The root certificate is often on the approved list of the receiving process. Certificates in the approved list are considered to be trusted certificates. A root certificate can be signed by a CA or can be self-signed, meaning that the digital signature that verifies the root certificate is encrypted through the private key that corresponds with the public key that the certificate contains, rather than through the private key of a higher CA. (Note that certificates of the CAs themselves are always self-signed.)
Functionally, a certificate acts as a container for public keys and associated signatures. A single certificate file can contain one or multiple chained certificates, up to an entire chain. Private keys are normally kept separately to prevent them from being inadvertently revealed, although they can be included in a separate section of the certificate file for convenient portability between applications.
A keystore is used to store certificates, including the certificates of all trusted parties, for use by a program. Through its keystore, an entity such as OC4J can authenticate other parties as well as authenticate itself to other parties. The keystore password is obfuscated. Oracle HTTP Server has what is called a wallet for the same purpose. Sun's SSL implementation introduces the notion of a truststore, which is a keystore file that includes the trusted certificate authorities that a client will implicitly accept during an SSL handshake.
In Java, a keystore is a java.security.KeyStore instance that you can create and manipulate using the keytool utility that is provided with the Sun Microsystems JDK. The underlying physical manifestation of this object is a file.
|
 Copyright © 2003, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
