| 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 discusses security issues affecting Web applications, covering the following topics:
See Also:
Oracle Containers for J2EE Servlet Developer's Guide for general information about Web applications
"Synchronization of OracleAS JAAS Provider User Context with Servlet Sessions" for information relevant when using Oracle Identity Management as the security provider with Oracle Single Sign-On
"Introduction to JAAS Mode" and "Configuring and Using JAAS Mode" for information about JAAS mode, which can be used with Web applications
The following Web site for OC4J "how-to" examples:
http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.html
This section discusses configuration settings to specify the authentication method for Web applications. The following topics are covered:
To specify a standard authentication method at the Web application level, use the <login-config> element and its <auth-method> subelement in web.xml. For example:
<web-app ... >
...
<login-config>
<auth-method>BASIC</auth-method>
...
</login-config>
...
</web-app>
Table 17-1 shows the standard <auth-method> settings in web.xml.
Table 17-1 Values for auth-method in web.xml
| Setting | Meaning |
|---|---|
|
|
The application uses basic authentication. |
|
|
The application uses digest authentication (not supported for an external LDAP provider or custom provider). |
|
|
The application uses custom form-based authentication. |
|
|
The application requires the client to supply its own HTTPS certificate for use with SSL. |
Notes:
For either the file-based provider or Oracle Identity Management, we recommend digest authentication as a more secure solution than basic authentication.
When you use DIGEST with Oracle Identity Management as your security provider, you must take preparatory steps as described in "Using Digest Authentication with Oracle Internet Directory".
When you use FORM, you can optionally set an OC4J flag for appropriate client-side redirects, as described in "Using Form-Based Authentication". (This section also discusses standard configuration for form-based authentication.)
To use CLIENT-CERT, you must also configure the OracleAS JAAS Provider property mapping.attribute, as described in "Using Client-Cert Authentication".
See Also:
"Web Application Standard Authentication Methods" for a summary of these authentication methods
The next section, "Specifying auth-method in orion-application.xml", for Oracle-specific authentication methods
Use the <jazn-web-app> element and its auth-method attribute in orion-application.xml to specify an Oracle-specific authentication method at the J2EE application level. Supported settings in the OC4J 10.1.3.1 implementation are "SSO" (for Oracle Single Sign-On), "COREIDSSO" (for Oracle Access Manager single sign-on), and "CUSTOM_AUTH" (to use the identity management framework, including Java SSO). Refer to "Overview of Oracle Application Server Single Sign-On Alternatives" for more information about these features. The following example is for Oracle Single Sign-On:
<orion-application ... >
...
<jazn provider="LDAP" >
<jazn-web-app auth-method="SSO"/>
...
</jazn>
...
</orion-application>
Notes:
The authentication method is set in orion-application.xml automatically for SSO alternatives you configure through Application Server Control (Oracle Single Sign-On and Java SSO).
Any standard authentication method should be configured in the web.xml file as described in the preceding section, "Specifying auth-method in web.xml", not in any OC4J-specific file. (This differs in some cases from proprietary functionality in earlier releases, although that functionality is still supported for backward compatibility.)
The <jazn-web-app> element is also supported in the orion-web.xml file. In the event of conflict, orion-web.xml takes precedence over orion-application.xml for the particular Web application in question.
A setting for auth-method in orion-application.xml (or orion-web.xml) overrides any setting in web.xml.
See Also:
"Overview of Oracle Application Server Single Sign-On Alternatives" for a summary of Oracle-specific authentication methods
In the OC4J 10.1.3.1 implementation, the default behavior is that the digest authentication module does not handle basic authentication, even if the client sends a basic authentication header. (This is different from the default behavior in the 10.1.3.0.0 implementation.) To enable basic authentication fallback in the event that the client sends a basic authentication header, set the digest.auth.basic.fallback property to "true" in a <property> subelement of the <jazn> element in orion-application.xml, as in the example below. (Note that the logic of this property is the reverse of what it was in the 10.1.3.0.0 implementation.)
<jazn provider="XML" location="jazn-data.xml"> <property name="digest.auth.basic.fallback" value="true" /> ... </jazn>
To avoid using basic authentication fallback, either do not set this property, or explicitly set it to "false".
Important:
If you switch from the file-based provider to Oracle Identity Management at any time for any application through Application Server Control, the<jazn> element in orion-application.xml for the application is replaced with the following. Any prior settings within the <jazn> element would be lost and would have to be redone.
<jazn provider="LDAP" />
This section discusses standard and OC4J-specific aspects of form-based authentication.
A setting of FORM requires additional configuration within the <login-config> element in web.xml to specify the URLs for the login page and error page. There is nothing OC4J-specific about this functionality. Here is an example:
<login-config>
<auth-method>FORM</auth-method>
...
<form-login-config>
<form-login-page>mylogin.jsp</form-login-page>
<form-error-page>myerror.jsp</form-error-page>
</form-login-config>
</login-config>
OC4J supports the property oc4j.formauth.redirect for client-side redirects. If you set this property to true when you start OC4J, then OC4J will execute an appropriate client-side redirect after a user has entered their credentials for form-based authentication, affecting the request URI that is listed in the browser. The property is set as follows:
-Doc4j.formauth.redirect=true
The default setting is false.
With a true setting, if a user enters a user name and password with sufficient credentials to pass the form-based authentication, the content of the protected resource will be displayed, and the request URI listed in the browser is the same as the URI that triggered the form-based authentication. (If the form-based authentication does not succeed, the client will instead be redirected to the error page specified in the configuration, described in the preceding section, "Setting Standard Configuration for Form-Based Authentication".)
Without a true setting, an OC4J-specific j_security_check request URI is listed in the browser after any form-based authentication.
As an example, assume the following resource is protected by form-based authentication:
http://myhost:8888/testapp/SecureServlet
If oc4j.formauth.redirect=true and form-based authentication succeeds, then the SecureServlet URI shown above will be listed in the browser when the content of the protected resource is displayed after form-based authentication. Without the true flag setting, though, the request URI listed in the browser would be the following:
http://myhost:8888/testapp/j_security_check
This section describes how to configure OC4J to authenticate a client through HTTPS, and describes the OC4J logic flow for this authentication method.
Note:
To use client certificates with Oracle Single Sign-On, follow procedures outlined in the Oracle Application Server Single Sign-On Administrator's Guide rather than procedures here.To use client authentication through HTTPS:
Configure SSL, as described in Chapter 15, "SSL Communication with OC4J".
Set <auth-method> to CLIENT-CERT in web.xml, as described in "Specifying auth-method in web.xml".
Set the OC4J mapping.attribute property in the <jazn> element of the application orion-application.xml file, as necessary.
If you use a default realm other than jazn.com (the default realm specified in jazn.xml), specify that through the default-realm attribute in the <jazn> element.
For the file-based provider, the default mapping.attribute value is "CN". For Oracle Identity Management (LDAP-based provider) or an external LDAP provider, the default value is "DN". Here is an example that explicitly sets it to "CN" for the file-based provider, and also specifies a default realm:
<orion-application ... >
...
<jazn provider="XML" ... default-realm="myrealm" ... >
<property name="mapping.attribute" value="CN"/>
...
</jazn>
...
</orion-application>
Important:
In standalone OC4J (no Oracle HTTP Server), setting needs-client-auth="true" in the <ssl-config> element in secure-web-site.xml is required in order to use client-cert authentication mode. This attribute is discussed in "Optional Steps in secure-web-site.xml".
If you switch from the file-based provider to Oracle Identity Management at any time for any application through Application Server Control, the <jazn> element in orion-application.xml for the application is replaced with the following. Any prior settings within the <jazn> element would be lost and would have to be redone.
<jazn provider="LDAP" />
Here is how CLIENT-CERT authentication works in OC4J:
A user tries to access a protected resource.
OracleAS JAAS Provider retrieves the distinguished name of the certificate user from the certificate.
According to the value of mapping.attribute, OracleAS JAAS Provider retrieves the appropriate value from the certificate user's distinguished name. For example, if the attribute setting is "CN", OracleAS JAAS Provider retrieves the common name from the distinguished name.
OracleAS JAAS Provider searches for the certificate user in the relevant user repository (such as jazn-data.xml for the file-based provider, or Oracle Internet Directory for the LDAP-based provider). The setting of mapping.attribute determines the search filter. If the attribute setting is "CN", for example, the common name is the search filter in the user repository.
Note, however, that the exact behavior differs between the file-based provider and the LDAP-based or an external LDAP provider. If johndoe is the common name, for example:
For the file-based provider, OracleAS JAAS Provider looks for "johndoe" in the repository.
For the LDAP-based provider or an external LDAP provider, OracleAS JAAS Provider looks for "cn=johndoe" in the repository.
OracleAS JAAS Provider loads the certificate principal and its granted roles, and populates a Subject instance with this information.
Authorization is performed against the subject.
This section describes role types and how they are mapped together:
J2EE includes a feature for portable security roles defined in the standard deployment descriptor web.xml for servlets and JavaServer Pages. These J2EE roles are used in defining a set of resource access permissions for an application. For example, assume you configure a J2EE role called sr_developers in web.xml. This is accomplished using a <security-role> element (a subelement of the top-level <web-app> element):
<web-app>
...
<security-role>
<role-name>sr_developers</role-name>
</security-role>
...
</web-app>
You also define the access permissions for the sr_developers role in web.xml. A role is tied to capabilities and constraints through additional standard descriptor elements, such as under the <security-constraint> element (also a subelement of <web-app>):
<web-app>
...
<security-constraint>
<web-resource-collection>
<web-resource-name>access to the entire application</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<!-- authorization -->
<auth-constraint>
<role-name>sr_developers</role-name>
</auth-constraint>
</security-constraint>
...
</web-app>
Associating a principal or logical role defined in your application code with a J2EE role assigns the defined access permissions of the J2EE role to that principal or application logical role. You can accomplish this in the web.xml file so that you do not have to update application code to change role definitions. Use the <security-role-ref> element (a subelement of the <servlet> element) to link an application role to a J2EE role:
<web-app>
...
<servlet>
...
<security-role-ref>
<role-name>ar_developers</role-name>
<role-link>sr_developers</role-link>
</security-role-ref>
...
</servlet>
...
</web-app>
The <role-name> element indicates a role in the application code. The <role-link> element specifies that this application role (ar_developers) should be linked to a J2EE role (sr_developers) defined previously in a <security-role> element.
In this example, if a servlet running as a user belonging to sr_developers invokes the HttpServletRequest method isUserInRole("ar_developers"), the method will return true.
Note:
Whenever the container finds no<security-role-ref> element matching a particular security role, the container checks the <role-name> value against the entire list of security roles for the application.Deployment roles and users are defined in the security provider that you use. For the file-based provider, for example, deployment users and roles are defined in the system-jazn-data.xml file (or, optionally, a user-supplied jazn-data.xml file).
The following configures a developers deployment role:
<jazn-data>
...
<jazn-realm>
...
<realm>
...
<roles>
...
<role>
<name>developers</name>
<members>
<member>
<type>user</type>
<name>john</name>
</member>
</members>
</role>
...
</roles>
...
</realm>
...
</jazn-realm>
...
</jazn-data>
There are situations where a Web container must allow access to users who are not known by the container. In such situations, the standard Web application descriptor may declare a <run-as> setting to specify the role to be allowed access:
<servlet>
...
<run-as>
<role-name>sr_developers</role-name>
</run-as>
...
</servlet>
The role name must be one of the roles already defined for the Web application. The Web container must propagate the specified identity for any call from a servlet to the EJB layer.
OC4J enables you to map J2EE roles defined in the web.xml file to deployment roles in the security provider. You can accomplish this through Application Server Control during deployment, as described in "Specifying Security Role Mapping through Application Server Control". Mappings are reflected in <security-role-mapping> settings in the orion-application.xml file (for a J2EE application) or orion-web.xml file (for a single Web application). In orion-application.xml, <security-role-mapping> is a subelement of the top-level <orion-application> element. Similarly, in orion-web.xml, it is a subelement of the top-level <orion-web-app> element.
A <group> subelement under a <security-role-mapping> element corresponds to a role in the security provider.
The following configuration in orion-application.xml would map the J2EE role sr_developers (defined in web.xml) to the deployment role developers (defined in system-jazn-data.xml for the file-based provider, for example):
<orion-application>
...
<security-role-mapping name="sr_developers">
<group name="developers" />
</security-role-mapping>
...
</orion-appliction>
This association permits the developers role to access resources that are configured in web.xml to be accessible for the sr_developers role.
Consider a user john, for example, who is a member of the developers role. Because this role is mapped to the J2EE role sr_developers, john has access to application resources that are made available to the sr_developers role.
|
 Copyright © 2003, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|