WebLogic Workshop Security Overview

 

The following overview sets out the aims of security and the security technologies available in WebLogic Workshop.

 

Security Goals

 

All security technologies are designed to achieve three basic goals.

1.    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.

2.    Confidential communication

Data transmission is confidential when only the intended recipient can read the data.

3.    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:

1.    Application scoped (defined in the application's application.xml / weblogic-application.xml files)

2.    Web application scoped (defined in a project's web.xml / weblogic.xml files)

3.    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.