Secure Oracle WebLogic Server Environments Using Oracle Optimized Solutions

Version 1

    by Michelle Szucs

     

    Oracle Optimized Solution for Secure Oracle WebLogic Server provides detailed guidelines for securing Oracle WebLogic Server environments, improving confidence and reducing deployment time and risk.

     

    Introduction

     

    Securing computer systems is a never-ending task as new vulnerabilities are exposed and new technologies enter the playing field. But this ongoing churn is precisely why it is so important to stay abreast of security developments and take constant steps to improve the security of the most critical environments.

     

    Oracle WebLogic Server environments often run critical applications that are necessary for a business to function. They have access to potentially sensitive databases, and must send and receive large quantities of information over the network. Oracle Optimized Solution for Secure Oracle WebLogic Server advances a number of common-sense steps that should form the basis of any secure Oracle WebLogic Server installation.

    OOS_Logo_small125.png
    Oracle Optimized Solutions provide tested and proven best practices for how to run software products on Oracle systems. Learn more.

     

    Encryption

     

    One of the most important ways to improve system security is enabling encryption. Unfortunately, conventional CPU resources are often overburdened by the computational costs of encryption, leading to costly performance decreases that can make this option untenable. Dedicated cryptography cards and network appliances can offload the encryption workload, but only at the cost of significant financial investment, complexity, a higher power profile, and increased traffic latency and volume.

     

    These trade-offs do not need to be made with Oracle's SPARC servers. Cryptographic accelerators built directly into specialized areas of the CPU allow encrypted workloads to run with minimal performance overhead and at no added financial cost. Organizations can enable encryption by default without worrying about impacting overall performance and at no financial penalty, a game-changing solution to the paradox of performance and cost being mutually exclusive.

     

    Best practices regarding encryption are constantly evolving, but current recommendations are to use Transport Layer Security (TLS) versions 1.1 or 1.2, and to disable the older standards (TLS 1.0 and SSL 2.0 and 3.0). TLS 1.1 requires at least JDK 6 update 111, and TLS 1.2 requires JDK 7. Java Secure Socket Extension must also be enabled. These requirements are certified with Oracle WebLogic Server 10.3.6 or 12c.

     

    When Oracle WebLogic Server and Oracle HTTP Server are properly configured to utilize TLS, the hardware cryptographic accelerators on the SPARC chip will automatically be used.

     

    To enable TLS using Java startup options, navigate to the directory where the Oracle WebLogic Server startup scripts will be run and execute:

     

    export JAVA_OPTIONS= -Dweblogic.security.SSL.protocolVersion=TLS1 \

    -Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.1

     

    Note that this action sets the minimum acceptable version of TLS to 1.1.

     

    These settings also can be enabled by creating or editing a script and adding the command. In Oracle WebLogic Server 12c, the script is called setUserOverrides.sh and should be located inside the Oracle WebLogic Server domain's bin directory; by default, this path installs at $MIDDLEWARE_HOME\user_projects\domains\$DOMAIN_NAME\bin. In Oracle WebLogic Server version 10.3.6, the file should instead be called setDomainEnv.sh.

     

    To enable TLS in Oracle HTTP Server, navigate to $DOMAIN_HOME/config/fmwconfig/components/OHS/componentName. The ssl.conf file must contain the following line:

     

    SSLProtocol nzos_Version_1_1 nzos_Version_1_2

     

    Java EE Security Feature Support in Oracle WebLogic Server

     

    Oracle WebLogic Server support for Java EE security features include Java Authorization Contract for Containers (JACC), Java Authentication Server Provider Interface for Containers (JASPIC), the Java Authentication and Authorization Server (JAAS), and Java Secure Sockets Extension (JSSE).

     

    The JACC specification defines a contract between a Java EE application server and an authorization policy provider; the contract is supported by all Java EE containers. Enterprise JavaBeans (EJB) and servlet containers running in Oracle WebLogic Server can leverage this authorization method; this implementation would replace use of the WebLogic authorization provider.

     

    To utilize the Oracle WebLogic Server JACC provider, the script startWebLogic.sh must be run with the following command, including a path to the weblogic.policy file:

     

    ./startWebLogic.sh -Djava.security.manager \

    -Djava.security.policy==$PATHNAME/weblogic.policy \

    -Djavax.security.jacc.policy.provider= \

    weblogic.security.jacc.simpleprovider.SimpleJACCPolicy \

    -Djavax.security.jacc.PolicyConfigurationFactory.provider= \

    weblogic.security.jacc.simpleprovider.PolicyConfigurationFactoryImpl \

    -Dweblogic.security.jacc.RoleMapperFactory.provider= \

    weblogic.security.jacc.simpleprovider.RoleMapperFactoryImpl

     

    Using the Oracle WebLogic Server JACC provider only changes the authorization and role mapping processes for EJB and servlets; authorization and role mapping tasks are provided through the Oracle WebLogic Server security framework providers. Enabling the Oracle WebLogic Server JACC provider also removes the ability to access and change the EJB and servlet roles and policies in the administration console.

     

    The JASPIC specification defines a service provider interface by which authentication providers that implement message authentication mechanisms may be integrated in client or server message processing containers or runtimes. Effectively, the API allows a consistent manner for authentication modules to communicate authentication requests from client applications to the databases or LDAP servers that contain user credentials.

     

    Like JACC, JASPIC overrides default Oracle WebLogic Server behavior and should be evaluated for compatibility with the overall security policy of the organization.

     

    JAAS is the preferred authentication method over JNDI in Oracle WebLogic Server, but only supports authentication schemes based on username and password combinations. Default support for certificate-based login is only available through JNDI. However, JAAS can be adapted to support certificate-based login by implementing a custom LoginModule that calls weblogic.security.auth.Authenticate.authenticate(). Java clients can call a variety of Java and Oracle WebLogic Server APIs to use JAAS authentication.

     

    JSSE provides Oracle WebLogic Server support for SSL and TLS. The startup flag for enabling JSSE is:

    -Dweblogic.ssl.JSSEEnabled=true

     

    JSSE-based SSL can also be enabled through the administration console. The path is Environment > Servers > $SERVER_NAME > Configuration > SSL > Advanced. Afterward, restart SSL in Environment > Servers > $SERVER_NAME > Control > Start/Stop.

     

    These Java EE features allow organizations to develop and deploy modular, secure applications that use established standards for secure communication between components and services.

     

    Oracle WebLogic Server Security Service

     

    A number of Oracle WebLogic Server-specific security features should be used to secure application environments. These features are part of the Oracle WebLogic Server security service, a framework that provides an API to be used by application developers to define security services. The service acts as an intermediary between Oracle WebLogic Server containers, resource containers, and security providers.

     

    An extremely useful component of the Oracle WebLogic Server security service framework is the single sign-on (SSO) capability. SSO allows an application user to log in only once to gain access to multiple application components or services, even if these individual pieces have independent authentication schemes. With just one identity, users are able to access disparate application processes. SSO functionality in Oracle WebLogic Server is implemented using the Security Assertion Markup Language (SAML) and Windows Integrated Authentication.

     

    Security Service Provider Interfaces (SSPIs) are another component of the security service framework. Developers and third-party vendors can leverage the SSPIs to develop customer security providers for Oracle WebLogic Server environments. The interfaces include adjudication, auditing, authentication, authorization, credential mapping, identity assertion, role mapping, and certificate lookup.

     

    Oracle WebLogic Server security providers call the security framework on behalf of applications. Custom security providers are one component of security realms. Security realms in Oracle WebLogic Server include these configured security providers plus users, groups, security roles, and security policies. When a user tries to access an Oracle WebLogic Server resource, the realm authenticates the user and verifies both the security role of the user within the realm and the security policy of the resource. Security policies replace access control lists and are associations between resources and users, groups, or security roles that can be bounded by dates and times. A lack of a security policy implies open access to a resource. Security policies can be assigned on a level as high as EJB or on a finer-grained level, referring to a particular EJB method or servlet. Security policies are inherited by all instances of a given resource type.

     

    See Also

     

    Oracle Optimized Solution for Secure Oracle WebLogic Server web page

     

    About the Author

     

    Michelle is a product manager on the Oracle Optimized Solutions team in the Systems division of Oracle. She is the solution manager for Oracle Optimized Solution for Secure Oracle WebLogic Server.

     

    Follow us:
    Blog | Facebook | Twitter | YouTube