Módulo 10 – Security

Security

• At the end of this module you will be able to:

– Describe the WSL 8.1 security architecture
– Configure security realms
– Configure user, groups and roles
– Secure Web applications with declarative
security
– Configure policies and SSL
– Create and manage certificates
– Protect WLS against several types of attacks
Roadmap

1. WLS 8.1 Security Architecture Overview

– Security Architecture
– Terminology
2. Users and Groups
3. Protecting Application Resources
4. Protecting Communications
5. Protecting Against Attacks
Architecture Goals

• Using applicable Java standards, create an architecture

that unifies enforcement and present it as a service to
other components
• Provide a security framework that allows integration of
third-party security products with minimum restrictions
on functionality
• Provide consistent, unified protection for resources such
as these, hosted on WebLogic Server
– EJBs
– Web applications (Servlets,JSP)
– Web Services
– J2EE resources :RMI objects JDBC, JNDI, MBeans
Security Architecture

• <Diagrama de página 458>

Process Architecture

• <Diagrama de página 459>

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 can be used as a
LoginModule to map a valid token to a WebLogic
server user.
Authentication 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, “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 CA.
Credential Mapping

• The credential mapping process is initiated

when application components must access
legacy-system authentication mechanism to
obtain a set of credentials.
• The requesting application passes the subjects
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 trial 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
outcome of the requests

• <Programa de página 464>

Section Review

In this section, we learned how to:

– Understand security architecture
– Use security terminology
– Understand compatibility with earlier WLS versions
Roadmap

1. WLS 8.1 Security Architecture Overview

2. Users and Groups
– WLS-embedded LDAP
– Security Realms
– Configuring Users, Group
3. Protecting Application Resources
4. Protecting Communications
5. Protecting Against Attacks
Security Realm

• A security realm is a collection of system

resources and security service providers.
• One security realm can be active at a time.
• Each user and group must be defined in a
security realm.
• Creating a security realm is an administration
task.
Embedded-LDAP Server

• By default user, group and authorization

information is stored in an embedded
lightweight directory access protocol (LDAP)
server.
• LDAP has these properties:
– It is derives from X.500
– It provides a hierarchical lookup service
– It supports complex searching
– It can be secured with SSL
Configuring Embedded LDAP

• <Pantalla de página 469>

Configuring a New Realm

• <Pantalla de página 470>

Configuring Providers

• <Pantalla de página 471>

Configuring Authentication Providers

• <Pantalla de página 472>

Reordering Authentication Providers

• <Pantalla de página 473>

Users and Groups

• A user is an entity that uses WLS; it can be:

– An application end-user
– A client application
– A WebLogic Server instance
• A group is an entity that uses WLS; it can be a
logical set of users.
• A group is more efficient for managing a large
number of users.
• Typically, the members of a group have
something in common.
Configuring a New User

• <Pantalla de página 475>

Groups

• WLS provides the flexibility to organize groups

in various ways:
– A group can contain users
– A group can contain other groups

• <Dibujo de la pág. 476>

Configuring New User

• <Pantalla de página 477>

Adding Users and Groups to a Group

• <Pantalla de página 478>

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 a group can be granted multiple
roles.
• There are two types of roles: global-scoped
roles and resources-scoped roles.
• These global roles are available by
default:Admin, Operator, Deployer and Monitor
… Roles

• Roles defined in deployment descriptors van be

inherited:
– Inheritance occurs at deployment time
– Can be disabled
• You can manage role definitions and
assignments without editing deployment
descriptors or re-deploying
Configuring New Global Roles

• <Pantalla de página 480>

Migrating Security Data

• WLS can export users, groups, security policies,

security roles, and credential maps between
security realms or domains.
• Migration is useful in, for example, transitioning
from the development stage, to QA, to
production.
• Use migration constraints (key/value pairs) to
specify export/import options.
Exporting WLS Default Authenticator

• <Pantalla de página 483>

Importing Into a Different Domain

• <Pantalla de página 484>

Section Review

In this section, we learned how to:

– Understand WLS-embedded LDAP
– Define a security realm
– Configure users, groups and roles
Exercise

Create a Security Realm

– For details on the exercise, refer to the Lab Guide.
– If questions arise, ask the instructor
– The instructor will determine the stop time
Roadmap

1. WLS 8.1 Security Architecture Overview

2. Users and Groups
3. Protecting Application Resources
– Declarative Security
– Protecting Web Applications
– Defining Policies and Roles
4. Protecting Communications
5. Protecting Against Attacks
J2EE Declarative Security

• Declarative security:
– Describes an application’s access control in a
form that is external to the application
– Specifies security roles, access control, and
authentication requirements on application
resources
– Uses XML-based deployment descriptors
Protecting Web Applications

• To protect a Web application with declarative

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

• <Pantalla de página 490>

1. Define Security Roles

• Define the types of users of your Web

application.
• Use the web.xml deployment descriptor to
define security roles

• <Pantalla de página 491>

2. Define Protected Resources

• Web resources are defined according to URL

patterns.
• URL patterns provide a flexible way to define
one resource or a group of resources.

• <Pantalla de página 492>

3. Map roles to resources …

• Apply security constraints to specified resources

in a Web application.
• Users must be authenticated when accessing
resources by these URL patterns.

• <Pantalla de página 493>

… Map roles to resources

• Define which roles can access a collection of

resources.

• <Pantalla de página 494>

4. Map Roles to Users in Realm

• Use Weblogic.xml to map Web application roles

to entities in the WebLogic security realm.
• Map to groups or individual users

• <Pantalla de página 495>

5. Configure Authentication

• Configure how a Web application determines

user’s security credentials:
– BASIC – Web browser displays a dialog box
– FORM – use a custom HTML form
– CLINT-CERT – request a client certificate

• <Pantalla de página 496>

Authentication Examples

• <Pantalla de página 497>

Editing the DD Using WebLogic Builder

• <Pantalla de página 498>

Policies and Scoped Roles

• A scoped role:
– Is an abstraction of users and groups
– Can be determined dynamically for different
resources
• A security policy:
– Is a set of rules and conditions that users and
groups must meet, to be granted or denied
authorization
– Implements parameterized authjorization
– Allows expressions using defined roles
Configuring Scoped Roles and Policies for URL
Resources

• <Pantalla de página 500>

Defining a Security Policy

• <Pantalla de página 501>

Defining Policies and Scoped Roles for Other
Resources

• <Pantalla de página 502>

Section Review

In this section, we learned how to:

– Protect Web applications with declarative security
– Define policies and roles
Roadmap

1. WLS 8.1 Security Architecture Overview

2. Users and Groups
3. Protecting Application Resources
4. Protecting Communications
– What is the Secure Sockets Layer (SSL)
– Configuring SSL
– Certificates
– Keytool
5. Protecting Against Attacks
What Is SSL?

• The Secure Sockets Layer (SSL) is a protocol

that allows:
– Connection security, through encryption
– A server to authenticate to a client
– A client to authenticate to a server (optional)
– Data integrity: data that flows between a
client and server is protected from tampering
by a third party
Using a SSL Connection

• SSL is used by WLS to secure HTTP and t3

communication
• To use SSL, clients access WLS with the HTTPS
or T3S protocols.
– https://localhost:7002/orderStock
– t3s://localhost:7002/useCreditCard

• <Dibujo de la página 506>

Making Secure Communication Possible

• Public key encryption uses a pair of asymmetric

keys for encryption an decryption
• Each pair of keys consist of a public key and
private key
• Data encrypted with a public key can be
decrypted only by a private key, and vice versa
WebLogic Server SSL Requirements

• To enable WebLogic Server SSL, you must:

– Generate an identity keystore and a
public/private key pair using keytool (or
another utility)
– Generate a CSR and use it to obtain signed
public certificate from a CA
– Import the signed public certificate into the
identity keystore
– Configure the WebLogic Server SSL
properties (SSL port, two-way
authentication)
– Configure the keystore properties
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
keystores contents.
• For documentation see:
– http://java.sun.com/j2se/1.4.1/docs/tooldocs/wind
ows/keytool.html
– http://
java.sun.com/j2se/1.4.1/docs/tooldocs/solaris/keyt
ool.html
Obtaining a Digital Certificate

• <Esquema de la página 511>

Obtaining a Digital Certificate:
keytool Examples

• <Esquema de la página 512>

Certificate Reply Properties

• CA-signed certificates are not completely

identical
• If you request a certificate from:
– VeriSign, Inc., request a WebLogic certificate
– GTE CyberTrust, follow the instructions for
supporting WebLogic Server
– Thawte, specify “BEA WebLogic” as a servert
type
• For other CAs, ensure that the certificate reply
is in X.509 or PKCS#7 format (keytool supports
both)
Proxying Using SSL

• Web server prox plug-in supports SSL to connect

to a back-end WLS server.
– SSL Connection between the web server and
the back-end WebLogic server can to be
enabled on the respective plug-in
configuration file
• Each server in a cluster should use its own
certificate ( not a common shared one).
Configuring SSL

• <Pantalla de la página 516>

Configuring SSL Properties

• <Pantalla de la página 517>

Trust and Identity

• SSL and keystores are configures independently.

• For backward compatibility, SSL can use a
private key file (it is not recommended).
• Identity: private key and digital certificate (can
be looked up directly from the keystore, not
necessarily as a stand-alone file outside the
kestore).
• Trust: certificates of Trusted Certificate
Authorities
Configuring Trust and Identity Keystores …

• <Pantalla de la página 519>

… Configuring Trust and Identity Keystores

• <Pantalla de la página 520>

Configuring SSL Using Stan-alone Certificate and
Key Files

• <Pantalla de la página 521>

Section Review

In this section, we learned how to:

– Identify the Secure Sockets Layer (SSL) protocol
– Configure SSL
– Create certificates
– Manage certificates with keytool
Exercise

Configure SSL
– For details on the exercise, refer to the Lab Guide.
– If questions arise, ask the instructor
– The instructor will determine the stop time
Roadmap

1. WLS 8.1 Security Architecture Overview

2. Users and Groups
3. Protecting Application Resources
4. Protecting Communications
5. Protecting Against Attacks
– Types of Attacks
– Protecting Against Man-in-the-middle
Attacks
– Protecting Against Denial-of-service
Attacks
– Protecting Against Large-buffer Attacks
– Protecting Against Connection-starvation
Attacks
Protecting Against Attacks

• WLS can help protect applications against

several types of attacks:
– Man-in-the-middle attacks
– Denial-of-service (DoS) attacks
– Large-buffer attacks
– Connection-starvation attacks
• This section describes countermeasures that
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 and intercepts
messages between a client and the real host.
• Rather than issuing the real destination host’s
SSL certificate, the attacker issues its own,
intending for the client to accept is as being
from the real destination host.

• <Diagrama de la Página 526>

Man-in-the-middle Countermeasures

• Man-in-the-middle attack can be resisted using

a hostname verifier.
• A hostname verifier ensures that the host to
which an SSL connection is made is the
intended or authorized entity.
• WLS provides a default hostname verifier.
• To create a custom hostname verifier,
implement the interface:
– Weblogic.security.SSL.HostynameVerifier
Configuring a Hostname Verifier

• <Pantallas de la página 528>

Denial-of-service Attacks

• A denial-of-service (DoS) attack is an attempt to

prevent legitimate users of a service from using
it.
• These are the basic types:
– Consumption of scarce, limited, or non-
renewable resources
– Destruction or alteration of network
components
– Physical destruction or alteration of network
components
DoS Countermeasures

• Harden WLS against DoS 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 according to the origin of
the client.
• This feature can be used to:
– Restrict locations from which connections to
WLS are made
– Restrict the type of connections made; for
example, allow only SSL connections.
• To filter network connections, create a class
that implements the ConnectionFilter interface
and install it using the Administration Console
Connection Filter

• <Pantallas de la página 532>

Large Buffer Attacks …

• Someone tries to take down a Web site by

sending a large buffer data, which starves the
system of memory.
• Administrators can combat this attack by setting
a threshold for incoming data.
… Large Buffer Attacks

• <Pantalla de la página 534>

Connection Starvation …

• Someone tries to take down a Web site by

sending small, incomplete messages that cause
the server to wait.
• Administrators can combat this attackby setting
a threshold.
• Connections time out while waiting for the
remainder of the data, if they have reached the
threshold set by the administrator.
… Connection Starvation

• <Pantalla de la página 536>

User Lockout

• Someone tries to hack into a computer using

combinations of usernames and passwords.
• Administrators can protect against this security
attack by setting the lockout attributes.
• The administrator has an option to unlock a
locked user through the console.
Configuring User Lockout

• <Pantalla de la página 538>

Unlocking Users

• <Pantalla de la página 539>

Section Review

In this section, we learned how to:

– Identify the main types of attacks
– Protect WLS from man-in-the-middle attacks
– Protect WLS from denial-of-service attacks
– Protect WLS from large buffer attacks
– Protect WLS from connection-starvation attacks
Module Review

In this module, we learned how to:

– Understand the WLS 8.1 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 from several types of
attacks