|
Oracle® Containers for J2EE Security Guide
10g Release 3 (10.1.3) B14429-01 |
|
 Previous |
 Next |
|
Oracle® Containers for J2EE Security Guide
10g Release 3 (10.1.3) B14429-01 |
|
|
Previous |
Next |
This chapter provides an overview of the Java 2 security model, Java Authentication and Authorization Service (JAAS), and related security concepts. The following topics are covered:
The Java 2 Security Model is fundamental to the Oracle Application Server security implementation. The Java 2 Security Model enables configuration of security at all levels of restriction. This provides developers and administrators with increased control over many aspects of enterprise applet, component, servlet, and application security. The Java 2 Security Model is capability-based and enables you to establish protection domains and to set security policies for these domains.
The Java 2 Security Model by itself, however, has certain limitations. It is code-based only, as opposed to being declarative in deployment descriptors. It also has no policy management API, and uses a file-based implementation that does not scale well.
The Java Authentication and Authorization Service (JAAS) is a Java package that enables applications to authenticate and enforce access controls upon users. It is designed to complement the existing code-based Java 2 security. JAAS implements a Java version of the standard Pluggable Authentication Module (PAM) framework. This enables an application to remain independent from the authentication service.
JAAS extends the access control architecture of the Java 2 Security Model to support principal-based authorization. It also supports declarative security settings, in deployment descriptors, instead of being limited to code-based security settings.
|
See Also:
|
This section covers the following topics regarding authentication and authorization.
Software security depends on two fundamental concepts: authentication and authorization.
Authentication deals with the question "Who is trying to access my 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 (OID) is an example of a user repository.
|
See Also:
|
Although each J2EE application determines which user can use the application, it is the security provider that authenticates the user's identity through the user repository.
OC4J supports several different authentication methods, both standard and Oracle-specific. For details, see "Authentication in the OC4J Environment".
Authorization regards the question "Who can access what 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. This is further discussed in "Role-Based Access Control: Roles and Role Hierarchy".
Developers specify authorization for subjects in the application deployment descriptors.
The capability model is a method for organizing authorization information. The Java 2 Security Model uses the capability model to control access to permissions. With this model, authorization is associated with an entity (referred to as a principal, defined shortly), such as a user named frank in the following example. Table 1-1 shows the permissions that user frank is authorized to use:
Table 1-1 User Permissions
| User | Has These File Permissions |
|---|---|
|
|
Read and write permissions on a file named |
When user frank logs in and is successfully authenticated, the permissions described in Table 1-1 are retrieved and granted to user frank. User frank is then free to execute the actions permitted by these permissions.
An access control list (ACL) is a table with information about which access rights each user has for a particular protected resource, such as a directory or individual file. Each resource has a security attribute that identifies its access control list. The list has an entry for each system user with access privileges.
J2EE defines a declarative authorization model for container-managed security that decouples applications from the underlying security infrastructure. Authorization policy is expressed statically in the application deployment descriptors, rather than in application code. Authorization is role-based and is granted at access-level, typically protecting resources such as a Web URL or an EJB method. Once access is granted, any functionality of the resource is available. This model is relatively coarse-grained, but suffices for many purposes.
By contrast, JAAS supports customized authentication and has an authorization model that is more dynamic and relatively fine-grained, where authorization is according to an adaptable security policy. The JAAS model is more customizable and extensible than the J2EE model, with features such as custom permission types.
For example, while J2EE security is sufficient for general protection of a Web URL or EJB method, JAAS security would be required to control who may access a file in the file system, or who may access security policy, create a user, or change a password.
As appropriate and necessary, you can use either model or both with an application. Both models are fully supported in OC4J. It is advisable to limit yourself to the J2EE authorization model whenever it meets your needs, given that the JAAS authorization model is more complicated to deploy and administer. Table 1-2 and Table 1-3 summarize the pros and cons.
Table 1-2 J2EE Security Pros and Cons
| J2EE Security: Pros | J2EE Security: Cons |
|---|---|
|
|
Table 1-3 JAAS Security Pros and Cons
| JAAS Security: Pros | JAAS Security: Cons |
|---|---|
|
|
A principal is a specific identity, such as a user named frank or a role named hr. A principal is represented by an instance of a class that implements the java.security.Principal interface. A principal class must define a namespace that contains a unique name for each instance of the class.
A subject represents a grouping of related information for a single user of a computing service, such as a person, computer, or process. This related information includes the subject's identities and security-related attributes such as passwords and cryptographic keys or other credentials. A subject is represented by an instance of the javax.security.auth.Subject class.
A subject can contain multiple identities, each represented by a principal. For example, a subject that represents a person, user frank, may have two principals:
One binds frank doe (name on his driver license) to the subject.
Another binds 999-99-9999 (number on his student identification card) to the subject.
After authentication of a user, a Subject instance represents the authenticated user, and then appropriate Principal instances are added to the Subject instance. The Principal instances are used in authorizing the authenticated user to perform specific privileged actions.
This section provides an overview of permissions, policies, and related topics, covering the following:
Permissions are the basis of the Java 2 Security Model. All Java classes (whether run locally or downloaded remotely) are subject to a configured security policy that defines the set of permissions available for those classes. Each permission represents a specific access to a particular resource.
The java.security.Permission class is an abstract class that represents access to a given resource, and optionally a specified action on that resource. A key method of this class is implies(Permission permission), which checks if the actions of the specified permission are implied by the actions of the permission instance upon which the method is called.
Here are common types of permissions and the classes that represent them (all extending Permission, either directly or indirectly):
java.security.AllPermission
java.lang.RuntimePermission (includes only a resource target)
java.io.FilePermission (includes a resource and actions)
Table 1-4 identifies the elements that comprise a Java permission instance.
Table 1-4 Java Permission Instance Elements
| Element | Description | Example |
|---|---|---|
|
Class name |
Permission class |
|
|
Target |
Target name (resource) to which this permission applies |
Directory |
|
Actions |
Actions associated with this target |
Read, write, and execute permissions on directory |
A policy is an association between resources and users or roles. More specifically, a policy is a repository of JAAS authorization rules, containing information that answers the question: Given a grantee, what are the granted permissions of the grantee?
A policy is represented in Java by a Policy object (java.security.Policy or javax.security.auth.Policy); a policy object stores a set of permissions.
Policies are declared in .policy files, such as java.policy or java2.policy. A policy contains a collection of permission grants to principals, and may contain a reference to a keystore (described in "Key Encryption and Exchange"). The following are typical locations for policy files:
JAVA_HOME/lib/security/java.policy
USER_HOME/java.policy
ORACLE_HOME/j2ee/home/config/java2.policy
Table 1-5 describes the Sun Microsystems implementation of policy file parameters. A codesource is represented by a java.security.CodeSource instance.
Table 1-5 Policy File Parameters
| Parameter | Definition | Examples |
|---|---|---|
|
Subject |
One or more principal(s) |
|
|
Codesource |
A URL location (codebase) and optionally an array of certificates (stored in a Java keystore |
|
A protection domain groups permissions with a codesource, essentially representing the permissions granted to the codesource. (The policy currently in effect is what determines protection domains. In the default implementation of the Policy class, a protection domain is one grant entry in the file.)
Each Java class is associated with a protection domain when it is loaded. Specifically, each class being loaded is associated with a java.security.ProtectionDomain instance. The permissions granted to this protection domain may be statically bound or dynamically determined when an access control check is performed. Each protection domain is assigned a set of permissions based on a configured security policy when the JVM is started.
A ProtectionDomain instance contains a codesource (described in the preceding section). It may also contain a Principal array describing who is executing the code, a classloader reference, and a permission collection (java.security.PermissionCollection instance) representing a collection of Permission objects.
The permission collection is effectively defined as the intersection of all permission sets assigned to protection domains at the moment of the security check.
Figure 1-1 shows how protection domains fit into the basic model for authorization checking at runtime.
A security manager (java.lang.SecurityManager instance) allows an application to implement security policies. For any given operation that is attempted, the security manager allows the application to determine what the operation is and whether it should be allowed in the current security context. The SecurityManager class has a number of checkXxx() methods, each of which checks whether the operation Xxx is allowed, and throws an exception if it is not. This includes the instance method checkPermission(Permission), which throws an exception if a requested access, specified by the given permission, is not permitted by the security policy currently in effect.
An access controller (java.security.AccessController instance) is also involved in access-control operations and decisions. The default implementation of the SecurityManager method checkPermission(Permission) actually calls the AccessController static method checkPermission(Permission).
Basically, an access controller is used to do the following:
Decide whether access to a system resource should be allowed or denied, based on the security policy currently in effect.
Mark code as being privileged, thus affecting subsequent access determinations.
Obtain a snapshot of the current calling context so access-control decisions from a different context can be made with respect to the saved context.
Any application that controls access to system resources should invoke AccessController methods if it is to use the specific security model and access control algorithm utilized by these methods. If, on the other hand, the application wishes to defer the security model to that of the SecurityManager installed at runtime, then it should instead invoke corresponding methods in the SecurityManager class.
In comparison, SecurityManager represents the concept of a central point of access control, while AccessController implements a particular access control algorithm, with special features such as the doPrivileged() method, which performs a specified privileged action with privileges enabled.
|
See Also:
|
The JAAS framework does not explicitly define user communities. However, J2EE has the concept of user communities called realms.
A realm is a collection of users and roles that are controlled by the same authentication policy. In other words, a realm is a protection domain, or security domain, that defines a set of permissions for authenticated users.
Each realm includes a set of configured users, roles, and policies. (In OC4J configuration, users, roles, and policies can all be configured within a realm definition.) At runtime, a realm defines an enterprise scope over which certain identity management policies (such as those corresponding to users and roles) are enforced.
Within the JAAS pluggable authentication framework, an application server and any underlying authentication services remain independent from each other. Authentication services can be plugged in through JAAS login modules without requiring modifications to the application server or application code. A login module is primarily responsible for authenticating a user based on supplied credentials (such as a password), and adding the proper principals (such as roles) to the subject. Possible types of JAAS login modules include a principal-mapping JAAS module, a credential-mapping JAAS module, or a Kerberos JAAS module.
A login module is an instance of a class that implements the javax.security.auth.spi.LoginModule interface, and is plugged in under an application to provide a particular type of authentication.
Within this framework, the javax.security.auth.login.LoginContext class provides the basic methods used to authenticate subjects such as users, roles, or computing services (when a user tries to log in to the application, for example). An application instantiates this class with a name and a callback handler (described shortly). When the login() method of a LoginContext instance is invoked by an application that a subject is trying to access, the LoginContext instance consults configuration settings, using a mechanism that employs the name that was passed in, to determine the appropriate login module to invoke for the application. Figure 1-2 summarizes this.
A callback handler is a javax.security.auth.callback.CallbackHandler instance that allows a login module to interact with a user to obtain login information. The only method specified by CallbackHandler is the handle(Callback[]) method, which takes an array of callbacks, which are instances of a class that implements the java.security.auth.callback.Callback interface. Callbacks do not retrieve or display requested information from the underlying security service, but simply provide the functionality to pass the requests to an application and, as applicable, to return the requested information back to the security service. Callback implementations in the javax.security.auth.callback package include: a name callback handler (NameCallback) to handle a user name, a password callback handler (PasswordCallback) to handle a password, and a text input callback handler (TextInputCallback) to handle any field in a login form other than a user name or password field.
If authentication succeeds, then the authenticated subject can be retrieved by invoking the getSubject() method of the LoginContext instance.
Different login modules can be configured with different applications, and a single application can use multiple login modules. The JAAS framework defines a two-phase authentication process to coordinate the login modules configured for an application.
Custom or external (third-party) login modules may be used with any given application. Oracle provides the login modules RealmLoginModule (for the file-based and LDAP-based providers), LDAPLoginModule (for external LDAP providers), and CoreIDLoginModule (for the COREid Access provider).
|
Note: An application that uses declarative J2EE authentication with OC4J and the OracleAS JAAS Provider does not have to create aLoginContext instance; it is created by OC4J implicitly.
|
A role is equivalent to a logical group of users. Wherever a role is discussed in this document, you can think of it as a group of users who will be performing the same tasks and therefore be given the same access capabilities. 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-3 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.
To communicate securely, applications must satisfy the following goals:
Secure communications: The data transmitted over the network cannot be intercepted, read, or altered by a third party. OC4J supports secure communications using the HTTP protocol over the Secure Sockets Layer.
Network authentication: Clients and servers must be able to authenticate themselves to one another over the network. This is achieved using digital certificates, single sign-on, or user name / password combinations.
Identity propagation: This allows one client to act as the agent of another client, using the identity of the original client.
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.
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 trustpoint. The trustpoint signing the certificate can be a certificate authority 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 uses both asymmetric and symmetric encryption to communicate. An asymmetric key—PKI public key—is used to encode a symmetric encryption key—the bulk encryption key; the bulk encryption key is then used to encrypt subsequent communication. After both sides agree on the bulk encryption key, faster communication is possible without losing security and reliability.
When an SSL session is negotiated, the following steps take place:
The server sends the client its public key.
The client creates a bulk encryption key, often a 128 bit RC4 key, using a specified encryption suite.
The client encrypts the bulk key with the public key of the server, and sends the encrypted bulk key to the server.
The server decrypts the bulk encryption key using the private key of the server.
This set of operations is called key exchange. After key exchange has taken place, the client and the server use the bulk encryption key to encrypt all exchanged data.
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 (CA), 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.
In Oracle Application Server, an Oracle wallet is equivalent to a keystore.
Identify propagation, or subject propagation, refers to propagating the identity of principals from context to context. A Web client can establish its identity to a servlet; the servlet can then use that identity to communicate with other EJBs and servlets.
In OC4J, subject propagation is used with IIOP, in accordance with the CSIv2 specification. It is also used with ORMI if it is enabled on the client and server.
J2EE software development is based on a develop-deploy-manage cycle. The Oracle Application Server security implementation plays an important role in the deploy-manage part of the cycle. Developers can use a declarative security model instead of having to integrate security programmatically, unburdening the developer.
The following list summarizes the J2EE development cycle, with an emphasis on the tasks specific to developing secure applications.
The developer creates Web components, enterprise beans, applets, servlets, and application clients.
The Oracle Application Server security implementation offers programmatic interfaces, but the developer can create components without making use of those interfaces.
The developer defines J2EE logical roles and assigns them privileges through security constraints.
The assembler takes these components and combines them into an Enterprise Archive (EAR) file.
As part of this process, the application assembler specifies options appropriate to the environment.
The assembler defines application-level security constraints and resolves potential conflicts between module-level configurations.
The deployer installs the EAR into an instance of OC4J.
As part of the deployment process, the deployer may map roles to users.
The system administrator maintains and manages the deployed application.
This task includes creating and managing JAAS roles and users as required by the application customers.
