Security

 

At the end of this chapter you will be able to:

• Describe WLS security architecture
• Configure users, groups, and roles
• Configure security realms
• Secure Web Applications with declarative security
• Configure policies and SSL
• Create and manage certificates
• Protect WLS against several types of attacks

  WLS Security Architecture Overview Architecture Goals

• Using Java standards (where applicable) create an architecture that unifies security enforcement and present it as a service to other components.
• Provide a security framework that allows integration of 3rd party security products with minimum restrictions on functionality.
• Provide consistent and unified protection for all resources hosted on WebLogic Server:

– EJBs                         – Web Services

– Web Applications    – Miscellaneous J2EE Resources

(Servlets, JSP)                 (RMI objects JDBC, JNDI,  MBeans)

 

Security Architecture  

 

 

Process Architecture

 

 

Security Services

 

Authentication Providers  

• An authentication provider uses LoginModules to authenticate users within a security realm.
• An authentication provider transports identity information and makes it available to components with Subjects.
• The Principal Validation provider provides additional protection by signing and verifying the authenticity of the principals.
• Identity Assertion providers as a LoginModule to map a valid token to a WebLogic server user.

  Authorization Providers

• An authentication provider is a process to control the interactions between users and resources based on user identity.
• The role mapping provider supplies the security role with information to determine whether access is allowed for role-based resources, such as EJBs.
• The access decision component answers the question, is access allowed?
• The access decision returns a result of PERMIT, DENY or ABSTAIN.
• The adjudication provider can be used to tally the results that multiple access decisions return to determine the final decision.

  Confidentiality

• WebLogic Server supports the Secure Sockets Layer (SSL) protocol to secure the communication between clients and server.
• SSL client authentication allows a server to confirm a user’s identity by checking that a client’s certificate and public ID are valid and are issued by a certificate authority (CA).
• SSL server authentication allows a user to confirm a server’s identity by checking that the server’s certificate and public ID are valid and are issued by a CA

Interested in mastering Weblogic Training? Enroll now for FREE demo 
on Weblogic Training.

  Credential Mapping

• The credential mapping process is initiated when application components must access a legacy system authentication mechanism to obtain a set of credentials.
• The requesting application passes the Subject as part of the call and information about the type of credentials required.
• Credentials are returned to the security framework which is then passed to the requesting application component.
• The application component uses the credentials to access the external system.

  Auditing

• Auditing provides a trail of activity.
• The Auditing provider is used to log activity before and after security operations.
• The default auditing provider records the event data associated with the security requests and the outcome of the requests.

Managing  Users and Groups:   Security Realms

• A Security Realm is a collection of system resources and security service providers.
• Only one security realm can be active at a given time.
• A single security policy is used in any realm.
• Users must be recognized by an authentication provider of the security realm
• Admin tasks include creating security realms.

  What Is LDAP?

• LDAP is:
  • The Lightweight Directory Access Protocol
  • Derived from X.500
  • Provides a hierarchical lookup service
  • Supports sophisticated searching
  • Can be secured via SSL

Embedded LDAP Server

• In WLS users, groups, and authorization information is stored in an embedded LDAP server.
• Several properties can be set to manage the LDAP server, including:
  • Credentials
  • Backup settings
  • Cache settings
  • Replication settings

 

  Configuring Embedded LDAP

 

 

Connecting an external LDAP browser

 

Users and Groups

• Users are entities that use WLS such as:
  • Application end users
  • Client applications
  • Other WebLogic Servers
• Groups are:
  • Logical sets of users
  • Are more efficient for managing a large number of users

     

Configuring New Users

 

 

Groups

• WLS provides the flexibility to organize groups in various ways:
  • Groups can contain users
  • Groups can contain other groups

 

 

Configuring New Groups

 

Roles

• A role refers to a set of users who have the same permissions.
• A role differs from a group; a group has static membership; a role is conditional.
• A user and group can be granted multiple roles.
• There are two types of roles: global-scoped roles and resource-scoped roles.
• These global roles are available by default: Admin, Operator, Deployer and Monitor.
• Roles defined in deployment descriptors can be inherited.
  • Occurs at deployment time
  • Can be disabled
• You can manage role definitions and assignments without editing deployment descriptors or redeploying.

             

Configuring New Roles

 

Migrating Security Data

• Can export users/groups, security policies, security roles, or credential maps between security realms or domains.
• Useful, for example, in transitioning from development to QA to production.
• Use migration constraints (key/value pairs) to specify the export/import options.
• Currently only supports migrating security data between WLS security providers.

   

Exporting WLS Default Authenticator Provider

 

Importing into a different domain

Protecting Application Resources  

J2EE Declarative Security

• Declarative security:
  • Is a means to describe an application’s access control in a form that is external to the application
  • Involves defining security roles and constraints on web application resources
  • Uses lazy authentication to protect application resources
  • Implemented in XML-based deployment descriptors
  • Applies to all types of application

 

Using Deployment Descriptors  

• The security realm definition determines how the deployment descriptors will be used
• 

  Protecting Web Applications with declarative security:  

1. Define roles that should access the protected resources
2. Determine Web Application resources that must be protected
3. Map protected resource to roles that should access them
4. Map roles to users/groups in the WLS security realm
5. Set up an authentication mechanism

  Define Security Roles

• Define types of users that exist in your Web Application.
• Use the web.xml deployment descriptor to define security roles.

 

Determine Protected Resources  

Web resources are defined based on URL patterns. URL patterns provide a flexible way to define a single resource or a group of resources.  

Map Roles to Resources…

• Apply security constraints to specified resources in your web application.
• Users must be authenticated when accessing resources by these URL patterns.

• Define which role(s) may access this collection of resources.

Map Roles to Users in Realms  

• Use weblogic.xml to map your web application roles to entities in the WebLogic security realm.
• Map to Groups or individual Users.

Setup Authentication

• Configure how a Web application determines users’ security credentials:
  • BASIC – web browser displays a dialog box
  • FORM – use a custom HTML form
  • CLIENT-CERT – request a client certificate

 

Authentication Examples

   

Policies and Roles

• Security roles:
  • Are an abstraction of users and groups
  • Can be determined dynamically for different resources
• Security policies:
  • Are rules/conditions that users/groups must adhere to, to be granted/denied authorization
  • Implement parameterized authorization

 

Defining Policies and Roles for Web Resources

 

 

Defining Policies and Roles for Other Resources…  

• You can define roles and policies on other resources, e.g. JDBC, JMS and more….

 

 

Protecting Communications  

What Is SSL?

• Secure Socket Layer (SSL) is a protocol that enables:
  • Connection security through encryption
  • A server to authenticate to a client
  • A client to authenticate to a server (optional)
  • Data integrity such that data that flows between a client and server is protected from tampering by a third party

Trust and Identity

• SSL and keystore are configured independently.

 

• For the purpose of backward compatibility, this release of WebLogic Server supports private keys and trusted CA certificates stored in files, or in the WebLogic Keystore provider:

   

• Identity
  • Private Key and Digital Certificate (can now be looked up directly from the keystore, not necessarily as a standalone file outside the keystore)
• Trust
  • Certificates of Trusted Certificate Authorities

  Using a SSL Connection

• SSL is used by WLS to secure HTTP and t3 communication.
• To use SSL, clients access WLS via the https or t3s protocols.
  • https://localhost:7002/orderStock
  • t3s://localhost:7002/useCreditCard
  • 

  Enabling Secure Communication

• With SSL data is encrypted using a negotiated symmetric session key.
• A public key algorithm is used to negotiate the symmetric session key.
• In SSL digital certificates are used to provide a trusted public key.

  WebLogic Server SSL Requirements

• To enable WebLogic Server SSL you must:
  • Obtain an appropriate digital certificate
  • Install the certificate
  • Configure SSL properties
  • Configure two-way authentication(if desired)
  • SSL impacts performance

    The keytool Utility

• keytool is a standard J2SE SDK utility for managing:
  • Generation of private keys and corresponding digital certificates
  • Keystores (databases) of private keys and associated certificates
• The keytool utility can display certificate and keystore contents.

 

• For documentation, see:
  • http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/keytool.html
  • http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html

 

Obtaining a Digital Certificate: keytool Examples

 

Configuring SSL for a WebLogic Server

 

 

Configuring Keystores

 

Protecting Against Attacks

• WLS can help protect applications against several attacks:
  • Man in the middle attacks
  • Denial of service (DoS) attacks
  • Large buffer attacks
  • Connection starvation attacks
• The set of slides that follow detail countermeasures WLS provides to address these attacks.

  Man in the Middle Attacks

• In a man in the middle attack, a third party poses as a destination host intercepting messages between client and the real host.
• Instead of issuing the real destination host’s SSL certificate, the attacker issues his own hoping that client accepts it as being from the real destination host.

 

Man in the Middle Countermeasures

• Man in the Middle attacks can be resisted by using a host name verifier.
• A Host Name Verifier validates that the host to which an SSL connection is made is the intended or authorized party.
• WLS provides a Host Name Verifier by default.
• A custom Host Name Verifier can be created by implementing the interface
  • security.SSL.HostnameVerifier

  Denial of Service Attacks

• DoS attacks are attempts by attackers to prevent legitimate users of a service from using that service.
• There are three basic types of attack:
  • Consumption of scarce, limited, or non-renewable resources
  • Destruction or alteration of configuration information
  • Physical destruction or alteration of network components

• WebLogic Interview Questions

  DoS Countermeasures

• Harden WLS against Denial of Service attacks by:
  • Filtering incoming network connections
  • Configuring consumable WLS resources with appropriate threshold and quotas
  • Limiting access to configuration information and backing up configuration files
  • Preventing unauthorized access by protecting passwords against password guessing attacks

  Filtering Network Connections

• WLS can be configured to accept or deny network connections based on the origin of the client.
• This feature can be used to:
  • Restrict the location from which connections to WLS are made
  • Restrict the type of connection made, i.e., only allow SSL connections and reject all others
• To filter network connections, create a class that implements the ConnectionFilter interface and install it using the Administration Console.

 

Connection Filter

Consuming WLS Resources

• Denial of Service can come from consuming server side resources used by Web Applications:
• Intentionally generating errors that will be logged consuming disk space
• Sending large messages, many messages, or delaying delivery of messages in an effort to cripple JMS
  • Disrupting network connectivity by "connection starvation"
  • Consuming system memory through "large buffer attacks"
• The effect of these attacks can be reduced by setting appropriate quotas and threshold values.

  Large Buffer Attacks…

• Individuals can try and take down a Web site by sending a large buffer of data, which starves the system of memory.
• Administrators can combat this attack by setting a threshold for incoming data.

 

Connection Starvation…

• Individuals can try and take down a Web site by sending small, incomplete messages that cause the server to wait.
• Administrators can combat this attack by setting a threshold.
• Connections time out while waiting for the remainder of the data if they have reached the threshold set by the administrator.

 

User Lockout

• Individuals attempt to hack into a computer using various combinations of usernames and passwords
• Administrators can protect against this security attack by setting the lockout attributes
• Administrator has an option to unlock a locked user through the console

 

Configuring User Lockout

 

Unlocking Users

 

Summary:

In this chapter we discussed:

• WLS security architecture
• Configuring users, groups, and roles
• Configuring security realms
• Securing Web Applications with declarative security
• Configuring policies and SSL
• Creating and managing certificates
• Protecting WLS against several types of attacks