The following overview sets out the aims of security and the security
technologies available in WebLogic Workshop.
A D V E R T I S E M E N T
Security Goals
All security technologies are designed to achieve three basic
goals.
Authentication of participants
When a participant is authenticated it means that there is some
assurance that the participant really is who they say they are.
Different scenarios call for different levels of authentication. In some
cases, only the web resource needs to be authenticated, while the client
can remain anonymous. For example, if your web resource takes customer
credit card numbers, you want your customers to have peace of mind that
they are providing their card numbers to you, and not some malicious
third party. But your customers may remain anonymous. In other cases,
the web resource will want proof of identity from its clients. For
example, if a bank provided online access to its customer's checking
accounts, the bank should require some form of client authentication
from those parties who want to access the online accounts.
Confidential communication
Data transmission is confidential when only the intended recipient can
read the data.
Integrity of transmitted data
Data integrity means that the data has not been altered in the
process of transmission. (When using transport security, there
is generally no need to take special measures to ensure data
integrity. This is because the encryption processes used by SSL
ensures data integrity.)
The topics below provide detailed information to help you implement a
security strategy for your WebLogic Workshop application.
WebLogic Workshop Security Technologies
WebLogic Workshop offers three main areas of security technology:
transport security
web service security
role-based security
Transport security refers to the mechanisms used to enable
the http protocol to operate over a secure transport connection. Transport
security lets you secure your web resources through SSL, username/password
authentication, and client digital certificates.
An advantage of transport
security is that is well known and relatively easy to implement. A
disadvantage is that data is secured only while it is in transport over the
wire. The transport security mechanisms no longer apply once the data has
reached the recipient, so if the data is logged on the recipient's machine,
its confidentiality may be at risk. This is not the case with Web service
security, where the security mechanisms are applied to the data itself.
For detailed information on implementing SSL and client certificates see
Transport Security. For detailed information on implementing
username/password authentication see
Username/Password Authentication.
Web service security provides message-level security for
web services through an implementation of the
Oasis Web Service
Security standard. Web service security, often referred to as
"WS-Security" or simply "WSSE", lets you secure the SOAP messages that pass
between web services with security tokens (username and password), digital
signatures, and encryption.
An advantage of WS-Security is that the security mechanisms are applied
to the SOAP messages that pass between web services. So WS-Security security
mechanisms apply both while the SOAP message is in transit and once the
message has arrived at the recipient's machine.
The disadvantages of WS-Security are that it is not a widely used form of
security and it is relatively more difficult to implement than the analogous
transport security technologies. For example, users must be familiar with
some of the inner workings of the Public Key Infrastructure (PKI) to
effectively use WS-Security's encryption and digital signature technologies.
For detailed information on implementing see
Web
Service Security.
Role-based security lets you secure a web resource by
restricting access to only those users who have been granted a particular
security role. For detailed information on see
Role-Based Security.
Transport Security
Transport security refers to a group of security technologies that
ensure the authenticity of both clients and servers and the integrity
and confidentiality of data passed between web servers and their
clients.
In most cases, transport security alone is sufficient to
secure a web resource such as a web application or web service; but
there is another security option available specifically for web
services. For detailed information see
Web Service Security.
Transport Security Strategies
Transport security offers three basic strategies for achieving the three
main security goals: authentication of participants, confidential
communication and data integrity. See
WebLogic Workshop
Security Overview for a description of these security goals.
One-way
SSL
One-way SSL offers two primary benefits. First it authenticates the
identity of the web server. Second, it ensures confidential communication by
encrypting the messages between the client and the server. The "one-way" in
one-way SSL refers to the fact that only the identity of the server is
authenticated, not the client. You should use one-way SSL when you want to
ensure private communication, but where the identity of the client is not a
critical factor.
One-way SSL with Basic Authentication
Basic authentication ensures the identity of clients by requiring a
username and password. Basic authentication should always be used together
with one-way SSL, otherwise the username and password could be intercepted
by a malicious third party. You should use one-way SSL when you want to
ensure the identities of both the client and server. For details on
implementing a basic authentication process, see
Basic Authentication.
Two-way SSL
Two-way SSL combines server authentication, encryption of data, and
client authentication through client digital certificates.
Web Service Security (WS-Security)
WebLogic Workshop provides message-level security for web services
through an implementation of the
WS-Security Oasis web service security standard. WS-Security lets
you secure the SOAP messages passed between web services using (1)
security tokens, (2) digital signatures, and (3) encryption.
Although
WebLogic Workshop supports both transport and message-level security, it
is generally not necessary to use both sorts of security to secure a web
service. In most cases, developers should choose one or the other type
of security to secure their web services.
Security Tokens
Security tokens are credentials used for authentication,
authorization, or both. The WebLogic Workshop implementation supports
two types of tokens. (1) Username and password tokens, and (2) X509
Binary Security Tokens.
When a X509 Binary Security Token accompanies an inbound SOAP
message, the token is passed to the WebLogic Server security framework
for authentication.
To include a Binary Security Token in an outbound SOAP message, you
specify that you want to sign the outbound message. Signing the
SOAP message will automatically include a X.509 BinarySecurityToken in
the message. Note that sending a X509/Binary Security Token without
signing the outbound SOAP message is not supported.
Digital Signatures
Digital signatures are used for two purposes: (1) to authenticate the
identity of the sender and (2) to ensure the integrity of SOAP messages.
If any part of an incoming SOAP message has been changed in transport,
the signature validation performed by the recipient will fail. In
WebLogic Workshop, if you require XML signatures for incoming SOAP
messages, the SOAP body must be digitally signed to be processed by the
web service.
By default, digital signatures are applied only to the body of
outgoing SOAP messages. You must specifically provide for the signing of
elements in the header. For details see
in the WS-Security reference
documentation.
Encryption
Encryption is used to encrypt either the body of the SOAP message,
the header, or both. If your web service requires encryption for
incoming messages, then, at a minimum, the body of incoming SOAP
messages must be encrypted.
For outgoing SOAP messages, encryption is applied only to the SOAP
body by default. You must specifically provide for the encryption of
elements in the header. For details see
in the WS-Security reference
documentation.
Note that keys used in WebLogic Workshop's implementation of
WS-Security must be RSA keys.
WSSE Policy Files
Web service security is controlled through WSSE policy files. WSSE
policy files are XML files with a .WSSE file extension.
To secure a web service with web service security, you
create a WSSE policy file and associate that file with your web service.
All outbound and inbound SOAP messages are processed according to the
policy called for in the WSSE file. Inbound messages are first checked
for the necessary security measures called for in the policy file. If
the inbound message is found to be appropriately secured, then the SOAP
message, cleaned of its security enhancements, is passed to the web
service for normal processing. Outbound messages go through the reverse
process: they are enhanced with the security measures called for in the
policy file before they sent out over the wire.
To access a web service secured with WS-Security, you create
a policy file and associate that file with the web service control. The
policy file you associate with a web service's control should match the
policy file of the target web service. If the target web service
requires encrypted incoming messages, then a control file targeting that
web service should encrypt messages before they are sent to the web
service.
For detailed information see
Using WSSE
Policy Files.
An Overview of Role-Based Security
The topics in this section explain how role-based security can be used to
restrict access to resources (web services, page flows, Java controls, EJBs)
to only those users who have been granted a particular security role. It
also explains the relationship between EJB-scoped, application-scoped,
web-application scoped, and global security roles.
To restrict access you
set up two kinds of tests that candidate users must pass to access some
resources: an authentication process, which determines the user's
identity and group membership, and an authorization process, which
decides whether a user has the role membership necessary to access a
particular resource. Once a user has access to a method and the method
executes, it can run under the security role of the user or under a
different security role.
The Authentication Process
A candidate user is first tested against the authentication process. The
authentication process is generally a login process, where the candidate
user is asked to provide a username and password. If the candidate succeeds
in passing this challenge, the user is granted a set of identities: one
identity is his username identity, the other identities are the set of
groups that user has membership in. The user's username identity and group
identities are called the user's principals: think of these
principals as a set of credentials that the user presents when he/she wants
to access some resource protected by an authorization process. For more
information, see
Authentication.
The Authorization Process
In the authorization process, users are tested to see if they have been
granted the required role to access the protected resource. If they have
been granted the required role, they can access the resource; if they
haven't, they are denied access. A user has been granted a particular role
if one of his/her principals has been granted a particular role. Principals
are granted roles by a set of role-principal mappings.
Note. A user can be a person or another
software component. For instance, a web service can invoke an EJB's method
with security restrictions; if the web service does not pass the
authorization process, it is prevented from invoking the EJB method.
Global Roles
Global roles are available to all resources within a server's security
realm, that is, a server's domain. These roles can be used by any
application and any resource using this domain. WebLogic Server predefines a
set of global roles but you can define additional global roles as needed.
For more information, see the WebLogic Server help topic
Securing WebLogic Resources.
Scoped Roles
Scoped roles apply to a particular resource. WebLogic Workshop
applications can have three different scopings:
Application scoped (defined in the application's application.xml /
weblogic-application.xml files)
Web application scoped (defined in a project's web.xml / weblogic.xml
files)
EJB scoped (defined in an EJB's ejb-jar.xml / weblogic-ejb-jar.xml
files)
Application scoped roles can be used in an authorization process to protect
any of the resources within the application, whereas web application scoped
roles apply only to the resources within an individual web project and EJB
scoped roles apply only to the resources within an individual EJB. For
instance, if you want a security role to be defined just for a particular
EJB, you make it EJB-scoped.
Note that EJB scoped roles do not exclusively
protect WebLogic Workshop's EJB projects: they also can be used to protect
Web Services, Java control extensions (JCX files), and JPD files. This is
because all these files are compiled into EJBs at compile time.
The following diagram shows the three kinds of scoped roles, and
corresponding deployment descriptors, that you can define with WebLogic
Workshop.
Note. You can also define scoped
security roles for other resources such as JDBC resources. For more
information, see the WebLogic Server help topic
Securing WebLogic Resources.
Role-Principal Mapping
Role-principal mappings define how principals map to security roles. A
particular user can be mapped to one or more security roles or a group can
be mapped to one or more security roles. Role-principal mappings for a
scoped role are defined in the appropriate deployment descriptor
configuration file (see the fragments in the above picture; this is
discussed in more detail in
Implementing
Role-Based Security).
For scoped roles, you can alternatively use the element to indicate that the role and
role-principal mapping are defined elsewhere in the security realm.
Specifically, when you use this element for EJB-scoped or web application
scoped roles, WebLogic Server first examines the application-scoped roles
for a role with the same name and with a role-principal mapping definition.
If no appropriate application-scoped roles are found, global roles are
examined. For application-scoped roles with the element, global roles are examined for
role-principal mappings.
Note. When you map a scoped role to a
principal, the principal is assumed to exist in the security realm.
Role-principal mapping does not have the side effect of defining the
principal if it doesn't exist. For more inforrmation, see
Creating
Principals and Role-Principal Mappings.
Running Under Another Security Role
An EJB, Java control, or web service method can run under the security
role of the invoking user, or it can run under a different security role and
principal. This might for instance be necessary when the EJB or web service
in turn use resources that have strict security requirements.
Authentication
Authentication establishes the identity of a user by challenging the user to
provide a valid username/password pair: something only the intended user
knows.
Authentication can be used to protect any web-accessible resource,
including web applications, web services, page flow applications, and
individual JSP pages.
If the protected web resource is intended for human clients, the
application can be configured to redirect users to a login page, where they
must enter a valid username and password before they can access the
resource. If the web resource is intended for machine clients, the machine
client can provided the required username and password through methods on
the resource's control file. For detailed information on authenticating
machine clients see
Using Controls to Access Transport Secured Resources.
The username/password pair can be checked against a variety of
authentication provider services. A default authentication provider is
provided by WebLogic Server, but other providers can be supplied as needed.
For details on changing the default authentication provider or adding
addition providers, see
Configuring Security Providers in the WebLogic Server 8.1 documentation.
If you want to restrict access to sensitive information,
username/password authentication should always be used in conjunction with
SSL. Without SSL the username and password to are transported over the HTTP
protocol, which uses only 64-bit encryption to hide the username and
password, making it relatively easy for a malicious party to intercept and
decode the message. For this reason you should always use basic
authentication in conjunction with SSL, which uses 128-bit encryption.
However, if the primary purpose of username/password authentication is
tracking user behavior in an application, and there is no especially
sensitive information at stake, you do not need to use SSL.
Below are three basic strategies for setting up a username/password
challenge in a WebLogic Workshop application:
Basic Authentication: uses a standard login screen
provided by the web browser.
Form Authentication: uses a custom login screen
provided by the developer.
Page flow authentication: uses a page flow to
authenticate a user.
Basic Authentication
Basic authentication has the advantage of being easy to implement, but,
since the login page is provided by the browser software, the developer does
not have control over the look and feel of the login page. For detailed
information see
Basic
Authentication. (Also see
Developing BASIC Authentication Web Applications in the WebLogic Server
8.1 documentation.)
Form Authentication
Form authentication is easy to implement and gives the developer control
over the look and feel of the login screen, but it should not be used in all
situations. In particular it should not be used to secure (1) web services
which have machine clients and (2) individual pages and methods within a
page flow.
Web services with machine clients will encounter a problem interpreting
the HTTP login page; instead use basic authentication for resources with
machine clients.
Form authentication should not be used to secure individual pages and
methods within a page flow. This is because form based authentication relies
on redirecting the user from and back to the protected resource, but page
flows do not support redirection from and back to the same location within a
page flow. For this reason, you should only use form authentication to
establish the identity of a user before he enters a page flow, not once he
is within the page flow. If you want to allow a user to navigate within a
page flow unauthenticated, but require authentication for other pages within
the page flow use
Page Flow
Authentication.
For details on developing Form Authentication see
Form
Authentication. (Also see
Developing FORM Authentication Web Applications in the WebLogic Server
8.1 documentation.)
Page Flow Authentication
Page Flow authentication uses a page flow to authenticate a user. The
page flow can be a nested page flow, so it is appropriate to use this
authentication technique when a user is already navigating within another
page flow. For detailed information see
Page Flow
Authentication.
Portal Security Scenario
The following scenario describes the portal implementation needs of a
fictitious company called Avitek, many of which involve security
considerations. The topic that follows,
Implementing the
Portal Security Scenario, describes the security touch points in the
scenario and provides links to implementation information.
Avitek needs
two types of portal-based Web presence: an internal site for its employees
and partners called "Inweb," and a public portal for its customers called "Outweb."
It needs authentication for both sites. Inweb must live behind a firewall.
Outweb is set up on a server cluster for load balancing and failover.
For Inweb, Avitek needs to cater to three different types of users:
managers, regular employees, and partners.
For the three types of users, Avitek wants to create only two portals:
one for managers and employees and one for partners. Since there are five
different partners, each partner must have a separate view of Inweb.
Some of the partners also perform contract work for Avitek, so they must
also be able to access the employee portal desktop.
Avitek wants all Inweb users to authenticate before seeing any view of
the portals.
For Outweb, Avitek provides information and services on a subscription
basis, so it wants to provide a portal that lets all users see unsecured
company information and log in to see secure information.
Avitek has a staff of two to administer all portals, and it wants to
grant limited administrative access to certain partners to let them maintain
their partner portal.
There are two JSP-based administration portlets that can never be seen by
anyone other than Avitek's in-house administrators.
Avitek also wants to use its existing content management system for
delivering content to its portals. The content management system vendor has
created an interface to connect to BEA's Virtual Content Repository.
Avitek will use two user databases: The Intranet site will use an
existing user database, and the public site will use the default WebLogic
Server LDAP user database and is gradually adding users to it.
Share And Enjoy:These icons link to social bookmarking sites where readers can share and discover new web pages.
Keywords:
WebLogic Workshop Security Overview, WEBLOGIC, WebLogic, WebLogic tutorials, WebLogic tutorial pdf, history of WebLogic, How To Deploy An Application Using WebLogic , learn WebLogic
