WebLogic Web Services Security

There are three kinds of security supported by weblogic workshop: HTTP Transport Security, message security, role-based security

Here, we’re gonna talk about transport security and role-based security. there are three options when using transport security. 1-)one-way ssl,2-)basic authentication, 3-)two-way SSL

Http basic authentication is username/password-based authentication.in basic authentication, password is put in an http header in the clear. To overcome this, you will usually combine one-way SSL with basic authentication. The most powerful but also most complex option is to use two-way SSL also known as Client authentication. Using this option, both the client and the server authenticate to each other using X509 Certificates.


Assume that we build our web services in a web project in wlw,and also assume that different web services are gonna be used by users who have same roles. Name of our web project is WebServiceApp

1-)Transport Security

First, we locate the web application descriptors web.xml and weblogic.xml

Suppose that there is a role defined in the current realm of weblogic server, whose name is OrdinaryUsers. In web.xml, we realise the following changes.

Between the tags  <security-constraint> and  </security-constraint>, we add the following:

Secure Resources
<!– yourWebService relative to WebServiceApp >








Here,OrdinaryUsers specifies the security role to which the access is restricted. We need to add users to this role to provide them access to the secured services.

Below  </user-data-constraint>, we add:

<description>Role description</description>

Now we map the role OrdinaryUsers in the weblogic.xml by adding the following elements just after <weblogic-web-app>





So, we provided http-basic authentication with 1 way SSL. But it doesn’t solve our problems.Suppose that we have 2 different web services in WebServiceApp and there are two different roles,users of each role invoke seperate web services.Our second role is ExtraOrdinaryUsers. if we add the role ExtraOrdinaryUsers to web.xml and map it in weblogic.xml,we couldn’t seperate web services, which is a securtiy leak. If we don’t add this role to deployment descriptors,users of this role can not access any web service. So what should we do? The answer is role-based security.

2-)Role-Based Security

A web service (JWS) file in Workshop compiles to an Enterrprise Java Bean (EJB). Hence the roles referred to within a JWS to provide authorization, using the role based security annotations such as roles-allowed are the roles defined at the EJB or application tier.

In our project, we assume that we have 2 web services: ServiceSuit.jws and ServicePlea.jws. we also asume that we have another role AllUsers who comprises the other 2 roles. First, we remove all of the entries about previous roles OrdinaryUsers  and  ExtraOrdinaryUsers and we place AllUsers  to the descriptors instead.It is the identical to placing OrdinaryUsers  like we did previously. Now we provided authentication at http tier, and we authorize access to everyone who has at least one of 2 previous roles. In order to provide security at application level, we define OrdinaryUsers  and  ExtraOrdinaryUsers  in the ejb tier and restrict access to ServiceSuit to OrdinaryUsers   and  access to ServicePlea to ExtraOrdinaryUsers .

To define a Security role at the application level called “ExtraOrdinaryUsers  ”  right click on “Security Roles” and click the “Create a new role” popup. Type ExtraOrdinaryUsers in the Name textbox and a description. Check the “Use role name” checkbox . Do the same thing for “OrdinaryUsers ” .

This will automatically generate the related entries about roles in the application.xml and weblogic-application.xml file part of the META-INF directory of the WebServiceApp application.

Click on the roles-allowed property within the security group in the Property Editor in the Design View of  ServiceSuit.jws  and add the name OrdinaryUsers. Do the same thing for ServicePlea.jws and  ExtraOrdinaryUsers .

That’s it. Now “ExtraOrdinaryUsers ” will have access at both the HTTP tier and EJB tier to ServicePlea.jws , but “OrdinaryUsers” will only have access at the HTTP tier and hence will fail authentication check at the EJB tier.Similarly, ExtraOrdinaryUsers  will fail authentication check at the EJB tier in his way to access ServiceSuit.jws

On Conclusion, i wanna say that wlw does a good job of providing  facility in security to developpers when developing web services.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s