Academic Tutorials

English | French | Portugese | German | Italian
Home Advertise Payments Recommended Websites Interview Questions FAQs
News Source Codes E-Books Downloads Jobs Web Hosting

Weblogic Tutorial
WebLogic Tutorial Introduction
The WebLogic Workshop Development Environment
Developing Applications
Applications and Projects
Workshop File Types
Debugging Your Application
Managing the Build Process
Compile a Single Java File
Source Control Systems
Message Logging
Working with Java Controls
Developing Web Applications
Designing Asynchronous Interfaces
Handling XML with XMLBeans
Building Integration Applications
Building Portal Applications
Developing Enterprise JavaBeans
The Life Cycle of an Entity Bean
Session Beans
Developing Message-Driven Beans
WebLogic Workshop Security Overview
Deploying an Application

HTML Tutorials
HTML Tutorial
XHTML Tutorial
CSS Tutorial
TCP/IP Tutorial
CSS 1.0
CSS 2.0
XML Tutorials
XML Tutorial
XSL Tutorial
XSLT Tutorial
DTD Tutorial
Schema Tutorial
XForms Tutorial
XSL-FO Tutorial
XML DOM Tutorial
XLink Tutorial
XQuery Tutorial
XPath Tutorial
XPointer Tutorial
RDF Tutorial
SOAP Tutorial
WSDL Tutorial
RSS Tutorial
WAP Tutorial
Web Services Tutorial
Browser Scripting
JavaScript Tutorial
VBScript Tutorial
DHTML Tutorial
HTML DOM Tutorial
WMLScript Tutorial
E4X Tutorial
Server Scripting
ASP Tutorial
PERL Tutorial
SQL Tutorial
ADO Tutorial
Apple Script
PL/SQL Tutorial
SQL Server
.NET (dotnet)
.Net Mobile
C# : C Sharp
SVG Tutorial
Flash Tutorial
Media Tutorial
SMIL Tutorial
Photoshop Tutorial
Gimp Tutorial
Gnuplot Programming
GIF Animation Tutorial
Scientific Visualization Tutorial
Web Building
Web Browsers
Web Hosting
W3C Tutorial
Web Building
Web Quality
Web Semantic
Web Careers
Weblogic Tutorial
Web Site Hosting
Domain Name
Java Tutorials
Java Tutorial
JSP Tutorial
Servlets Tutorial
Struts Tutorial
EJB Tutorial
JMS Tutorial
JMX Tutorial
Programming Langauges
C Tutorial
C++ Tutorial
Visual Basic Tutorial
Data Structures Using C
Assembly Language
Forth Programming
Lisp Programming
Data Warehousing
CGI Programming
Emacs Tutorial
Soft Skills
Communication Skills
Time Management
Project Management
Team Work
Leadership Skills
Corporate Communication
Negotiation Skills
Database Tutorials
Operating System
Software Testing
SAP Module
Business Warehousing
SAP Basis
Material Management
Sales & Distribution
Human Resource
Customer Relationship Management
Production and Planning
Networking Programming
Corba Tutorial
Networking Tutorial
Microsoft Office
Microsoft Word
Microsoft Outlook
Microsoft PowerPoint
Microsoft Publisher
Microsoft Excel
Microsoft Front Page
Microsoft InfoPath
Microsoft Access
Financial Accounting
Managerial Accounting
Network Sites

WebLogic Workshop Security Overview

Previoushome Next

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

Be the first one to comment on this page.

  Weblogic Tutorial eBooks

No eBooks on Weblogic could be found as of now.

 Weblogic Tutorial FAQs
More Links » »
 Weblogic Tutorial Interview Questions
More Links » »
 Weblogic Tutorial Articles

No Weblogic Articles could be found as of now.

 Weblogic Tutorial News

No News on Weblogic could be found as of now.

 Weblogic Tutorial Jobs

No Weblogic Articles could be found as of now.

Share And Enjoy:These icons link to social bookmarking sites where readers can share and discover new web pages.
  • blinkbits
  • BlinkList
  • blogmarks
  • co.mments
  • connotea
  • digg
  • Fark
  • feedmelinks
  • Furl
  • LinkaGoGo
  • Ma.gnolia
  • NewsVine
  • Netvouz
  • RawSugar
  • Reddit
  • scuttle
  • Shadows
  • Simpy
  • Smarking
  • Spurl
  • TailRank
  • Wists
  • YahooMyWeb

Previoushome Next

Keywords: WebLogic Workshop Security Overview, WEBLOGIC, WebLogic, WebLogic tutorials, WebLogic tutorial pdf, history of WebLogic, How To Deploy An Application Using WebLogic , learn WebLogic

HTML Quizzes
CSS Quiz
CSS 1.0 Quiz
CSS 2.0 Quiz
XML Quizzes
XML Quiz
XSL Quiz
DTD Quiz
Schema Quiz
XForms Quiz
XLink Quiz
XQuery Quiz
XPath Quiz
XPointer Quiz
RDF Quiz
RSS Quiz
WAP Quiz
Web Services Quiz
Browser Scripting Quizzes
JavaScript Quiz
VBScript Quiz
WMLScript Quiz
E4X Quiz
Server Scripting Quizzes
ASP Quiz
SQL Quiz
ADO Quiz
CVS Quiz
Python Quiz
Apple Script Quiz
SQL Server Quiz
PHP Quiz
.NET (dotnet) Quizzes
Microsoft.Net Quiz
ASP.Net Quiz
.Net Mobile Quiz
C# : C Sharp Quiz
VC++ Quiz
Multimedia Quizzes
SVG Quiz
Flash Quiz
Media Quiz
Photoshop Quiz
Gimp Quiz
Matlab Quiz
Gnuplot Programming Quiz
GIF Animation Quiz
Scientific Visualization Quiz
Graphics Quiz
Web Building Quizzes
Web Browsers Quiz
Web Hosting Quiz
W3C Quiz
Web Building Quiz
Web Quality Quiz
Web Semantic Quiz
Web Careers Quiz
Weblogic Quiz
SEO Quiz
Web Site Hosting Quiz
Domain Name Quiz
Java Quizzes
Java Quiz
JSP Quiz
Servlets Quiz
Struts Quiz
EJB Quiz
JMS Quiz
JMX Quiz
Eclipse Quiz
J2ME Quiz
Programming Langauges Quizzes
C Quiz
C++ Quiz
Visual Basic Quiz
Data Structures Using C Quiz
Cobol Quiz
Assembly Language Quiz
Mainframe Quiz
Forth Programming Quiz
Lisp Programming Quiz
Pascal Quiz
Delphi Quiz
Fortran Quiz
OOPs Quiz
Data Warehousing Quiz
CGI Programming Quiz
Emacs Quiz
Gnome Quiz
ILU Quiz
Soft Skills Quizzes
Communication Skills Quiz
Time Management Quiz
Project Management Quiz
Team Work Quiz
Leadership Skills Quiz
Corporate Communication Quiz
Negotiation Skills Quiz
Database Quizzes
Oracle Quiz
MySQL Quiz
Operating System Quizzes
BSD Quiz
Symbian Quiz
Unix Quiz
Internet Quiz
IP-Masquerading Quiz
IPC Quiz
Software Testing Quizzes
Testing Quiz
Firewalls Quiz
SAP Module Quizzes
ERP Quiz
Business Warehousing Quiz
SAP Basis Quiz
Material Management Quiz
Sales & Distribution Quiz
Human Resource Quiz
Netweaver Quiz
Customer Relationship Management Quiz
Production and Planning Quiz
Networking Programming Quizzes
Corba Quiz
Networking Quiz
Microsoft Office Quizzes
Microsoft Word Quiz
Microsoft Outlook Quiz
Microsoft PowerPoint Quiz
Microsoft Publisher Quiz
Microsoft Excel Quiz
Microsoft Front Page Quiz
Microsoft InfoPath Quiz
Microsoft Access Quiz
Accounting Quizzes
Financial Accounting Quiz
Managerial Accounting Quiz
Testimonials | Contact Us | Link to Us | Site Map
Copyright ? 2008. Academic All rights reserved Privacy Policies | About Us
Our Portals : Academic Tutorials | Best eBooksworld | Beyond Stats | City Details | Interview Questions | Discussions World | Excellent Mobiles | Free Bangalore | Give Me The Code | Gog Logo | Indian Free Ads | Jobs Assist | New Interview Questions | One Stop FAQs | One Stop GATE | One Stop GRE | One Stop IAS | One Stop MBA | One Stop SAP | One Stop Testing | Webhosting in India | Dedicated Server in India | Sirf Dosti | Source Codes World | Tasty Food | Tech Archive | Testing Interview Questions | Tests World | The Galz | Top Masala | Vyom | Vyom eBooks | Vyom International | Vyom Links | Vyoms | Vyom World | Important Websites
Copyright ? 2003-2024 Vyom Technosoft Pvt. Ltd., All Rights Reserved.