Posted on

How to recover Oracle Weblogic administrator password

oracle weblogic tutorials howto example wls java ee

How to change the administrator password

The last two recipes of this book will help you in case you have lost your administration password or just in case you want to simply change it. We will begin from the latter one. In order to change the Administrator password:

  1. Start the Web console and select from the left tree panel Security Realms |[yourrealm] | Users and Groups tab. From there, click on the administrator user (e.g. “weblogic”):

oracle weblogic tutorials howto example wls java ee

  1. In the next screen, click on the Passwords tab. Enter the new password and Save.

oracle weblogic tutorials howto example wls java ee
In order to make this change available when the server starts, you need to edit the located at DOMAIN_HOME\servers\AdminServer\security and provide the values used for user/password . The original values should be an encrypted string; however just enter the values as plain text as in the following example:



Save the file. Next time the server will start it, it will pick up the new values from the and once the same had been accepted, they will be encrypted again.

Recovering the administrator password

If you accidentally lost your administrator password don’t despair. Make sure the Administration server is stopped and that you have set the domain environment:


Now execute the following command (mind to include the “.” at the end of it) which sets a new password for the user “wlsadmin”:

C:\WLS121~1\user_projects\domains\base_domain>java wlsadmin newAdminPassword.

The above command will create a file called DefaultAuthenticatorInit.ldift in the current directory. Now make a backup copy of the original file DefaultAuthenticatorInit.ldift which is in the security folder of your domain:

C:\WLS121~1\user_projects\domains\base_domain\security>copy DefaultAuthenticatorInit.ldift DefaultAuthenticatorInit.ldift.backup

        1 file(s) copied.

Next, edit the located at DOMAIN_HOME\servers\AdminServer\security and give the values used for user/password. The original values should be an encrypted string; however just enter the values as plain text as in the following example:



Copy the recently created DefaultAuthenticatorInit.ldift to DOMAIN_HOME\security

C:\WLS121~1\user_projects\domains\base_domain\security>copy C:\wls1211_dev\user_projects\domains\base_domain\DefaultAuthenticatorInit.ldift .

Finally, delete the file named DefaultAuthenticatormyrealmInit.initialized located in DOMAIN_HOME\servers\AdminServer\data\ldap

C:\WLS121~1\user_projects\domains\base_domain\servers\AdminServer\data\ldap>delete DefaultAuthenticatormyrealmInit.initialized

Now restart the server using startWeblogic.cmd/ from DOMAIN_HOME

Posted on

How to restrict access to Oracle Weblogic

oracle weblogic tutorials howto example wls java ee

Restricting access to WebLogic Server

In order to restrict access to WebLogic server to a set of machines, you can use Network Connection Filters which are used to add an additional layer of security allowing you to deny access at the network level.

Network Connection Filters are a type of firewall in that they can be configured to filter on protocols, IP addresses, and DNS node names. For example, you can deny any non-SSL connections originating outside of your corporate network. This would ensure that all access from systems on the Internet would be secure.

You can configure Connection filters, by selecting the top-level domain from the Admin Console and then choosing the Security| Filter tab. In order to add a Connection filter you have to specify a Connection filter class and the Connection Filter rules.

WebLogic ships out of the box with a default Connection Filter class named that examines one or more connection filter rules defined in the Administration Console. Alternatively, you can create your own custom connection filter that evaluates the basis that incoming connections are accepted by the server.

The following Connection Filter rules can be used to deny http and https protocol access from to the local server. 

oracle weblogic tutorials howto example wls java ee

The connection filter rules are written using a firewall-like syntax (check here for more details about constructing filter rules:

Posted on

Configuring the Secured Socket Layer (SSL) on Oracle Weblogic

oracle weblogic tutorials howto example wls java ee

Secure Sockets Layer (SSL) provides secure connections by allowing two applications connecting over a network connection to authenticate the other’s identity and by encrypting the data exchanged between the applications. So, while authentication allows a server (and optionally a client) to verify the identity of an user, encryption makes data transmitted over the network intelligible only to the intended recipient.     

SSL can be configured one-way or two-way:

  • one-way SSL: the server is required to present a certificate to the client in order to verify its identity. To successfully negotiate an SSL connection, the client must authenticate the server, but the server will accept a connection from any client.   
  • two-way SSL: the server presents a certificate to the client and the client presents a certificate to the server. WebLogic Server can be configured to require clients to submit valid and trusted certificates before completing the SSL connection.

Configuring SSL on Oracle WLS         

In order to configure SSL, we will use the Java Keytool to generate the certificates required for both the one-way SSL communication and the two-way SSL communication.

A step-by-step guide for creating the certificates using keytool has been included in the Appendix of this book. Therefore, in order to proceed, follow these steps:

  1. Start by creating the required keystores (for one-way SSL) and truststore file (if you need two-way SSL) as indicated in the Appendix.
  2. In order to use the certificates, log into the Admin Console and, for each server that needs to be secured, click on its Keystore tab. By default it points to the Demo Certificates.
  3. Click on the Change button:

oracle weblogic tutorials howto example wls java ee

  1. In the next screen, select as Keystores the option “Custom Identity and Custom Trust” :

oracle weblogic tutorials howto example wls java ee

  1. Click on Save. This will return to the Keystore subtab.
  2. Now enter the details of your KeyStore (and in case of two-way SSL the truststore too ). Specify as Custom KeyStore Type “JKS”, which is the keystore type generated with JDK’s keytool utility.

oracle weblogic tutorials howto example wls java ee

  1. Click on Save. Now move on the Configuration | SSL tab and enter the alias of the Private Key Alias and its password, as shown by the following screen:

oracle weblogic tutorials howto example wls java ee

  1. The last step, which needs also to be repeated in every secured server, is Enabling SSL and setting a Listen Port for your https requests. This can be achieved through the Configuration | General Sub Tab as shown by this picture:

oracle weblogic tutorials howto example wls java ee

Posted on

Securing Oracle Weblogic applications

Configuring Security for Web applications

Configuring security for Oracle WLS Web applications is done in two separate points:

  1. Inside the standard web application configuration file (web.xml) you will define the authorized Roles, the secured URL Pattern and the Authorization method.
  2. Inside the weblogic.xml you will map these roles to actual principals defined in the WebLogic Server security realm.

Let’s define at first in your web.xml how to apply security constraints using BASIC authentication:




                            <description>Our Secure Area</description>




                            <description>Constraints for secure area</description>





                            <description>SSL is not required</description>





              <auth-method>              BASIC</auth-method>



We have restricted access to all Web Context resources so that only users with the role admin and poweruser can access them, but we are not requiring the use of SSL transport for access.

Setting the <transport-guarantee> to CONFIDENTIAL or INTEGRAL would further restrict access to only those users in one of the specified roles who are using SSL to access the page.

If we stopped here, WebLogic Server would try to map these roles to principals (either users or groups) with the same name, as defined in the active security realm’s authentication provider. In most cases, you don’t actually want this, so you need to define the mapping from these roles to actual principals defined in the WebLogic Server security realm.

In order to map these roles to principals in the underlying security realm, you use the <security-role-assignment> element in the weblogic.xml deployment descriptor. In the following example, we are mapping the “admin” role to the “webuser” user and the “poweruser” role to “john”.











Configuring Security for EJB applications

Configuring security for EJB applications is similar to Web applications; just it is uses different files.

Inside your Java EE’s ejb-jar.xml deployment descriptor, define your access control policy by using the <security-role> and <method-permission> elements. In the following example, we restrict access to the SecuredEJB’s getData method to users which are granted the admin role:













EJB 3.0 and later also allows for declaration of EJB security constraints through annotations found in the package, as in the following example:



public class SecuredEJB {


  public Data getData() { … } }

Next, configure into weblogic-ejb-jar.xml the actual mapping data. The following example maps the admin role to ejbuser user. Additionally, you can use the <externally-defined> element to force a role to be defined in the role mapping security provider.







              <externally-defined />


Posted on

Configuring Oracle Weblogic Security Providers

Security providers are modular components that handle specific aspects of security, such as authentication and authorization. Although applications can leverage the services offered by the default WebLogic security providers, the WebLogic Security Service’s flexible infrastructure also allows security vendors to write their own custom security providers which can be used with WebLogic Server.

Before configuring new Security providers, you must be aware that WebLogic Server security includes many unique terms and concepts that you need to understand. The following table describes them shortly:


Authentication: this is the process of determining whether someone is, in fact, who it is declared to.

Identity Assertion: an Authentication provider that performs perimeter authentication—a special type of authentication using tokens—is called an Identity Assertion provider.

Authorization: once a user’s identity has been established by an authentication provider, authorization is responsible for determining whether access to resources should be permitted for that user.

Role Mapping: you can assign one or more roles to multiple users and then specify access rights for users who hold particular roles for a given resource.

Adjudication: an Adjudication provider is used to resolves authorization conflicts between multiple Authorization providers. It can do so, by weighing each Authorization provider’s access decision and determining whether to permit access to the requested resource.

Credential Mapping: credential mapping allows WebLogic Server to log into a remote system on behalf of a subject that has already been authenticated.

Keystore: this is a repository of security certificates, either authorization certificates or public key certificates – used for instance in SSL encryption.

Certificate Lookup and Validation (CLV):  you can usecertificate lookup and validation (CLV) providers to perform additional validation on the certificate chain.

Certificate Registry: a certificate registry is a mechanism for adding certificate revocation checking to a security realm. The registry stores (into an embedded LDAP server) a list of valid certificates. Only registered certificates are valid.

Auditing: auditing is a process which is in charge is to collect, store and distribute information about security requests for the purpose of non-repudiation.

Managing Security Providers

You can get the list of available Security Providers by selecting the Providers upper tab (Security realm | Providers). Out of the box, WLS provides a default WebLogic Authentication Provider and an Identity Assertion Provider.

WebLogic Server’s default security providers use an embedded LDAP server to persist all security-related data. Each server stores this data locally, including all of the user, group, role, access control policy, and credential information. You can use the embedded LDAP server for managing users and groups for reasonably small environments (10,000 or fewer users).

Connecting to the embedded LDAP server

Connecting to the embedded LDAP server is quite simple as it just requires an ordinary LDAP browser such as JXPlorer (

Before doing that, you need to set a password in order to be able to log to the LDAP server. This can be done by navigating into the Domain | Security | Embedded LDAP screen. Once there, set the Credential (and confirm it) that will be your password for accessing LDAP:

Now restart WLS and launch your LDAP explorer. From there enter the Base DN information, which will be bound to your domain name, and enter as username “Admin” and as password the one we have just entered in the console. The LDAP port is 7001. The LDAP explorer window is depicted in the following picture:

Click Ok. You can now view/export your WLS realm using the standard LDAP’s ldif format.

oracle weblogic tutorials howto example wls java ee

Creating a new provider: Database Authentication provider

In this section, we will show how to create a new Authentication provider which uses the database for storing the user’s credentials.

  1. Open up the Console and select the Security Realm| [Your Realm] |Providers Summary view.
  2. Click on New.
  3. In the next screen you will need to configure some basic settings for your provider. In the Type combo you need to select the type of authentication provider you want to create.

oracle weblogic tutorials howto example wls java ee

WebLogic Server comes with several built-in, configurable authentication providers. These providers primarily include support for external directory servers such as Active Directory, Sun Java System Directory Server, OpenLDAP, and Novell eDirectory, Oracle Internet Directory, and Oracle Virtual Directory LDAP servers.

In this recipe we will show how to use a DBMS provider to store your users and roles, therefore select the SQLAuthenticator as Type and click Ok.

Once created, select your just created provider and enter the Configuration tab and the Common sub-tab:

oracle weblogic tutorials howto example wls java ee

There you specify, via the Control Flag option, how this Authentication provider fits in the overall authentication process, in case you have multiple Authentication providers. The Control Flag option can have the following values:

  • REQUIRED: the authentication provider is required to succeed. If it succeeds or fails, the authentication process continues to proceed through the list of configured providers. If multiple providers are present, at least one needs to be set as REQUIRED.
  • REQUISITE: the authentication provider is required to succeed. If it succeeds, the authentication process continues through the list of configured providers. If it fails, the authentication process immediately fails and returns control to the application.
  • SUFFICIENT: the authentication provider is not required to succeed. If it does succeed, the authentication process succeeds and control is returned immediately to the application. If it fails, the authentication process continues down the list of configured providers.
  • OPTIONAL: the authentication provider is not required to succeed. If it succeeds or fails, the authentication process continues down the list of configured providers.


Warning! Because the administration server must authenticate the user using the default authentication provider, a misconfigured provider using one of these strict control flags will prevent the server from starting (for example by setting more than one option to REQUIRED).

Back to our example, we have decided to set the control flag to SUFFICIENT. Click Save and move to the Provider specific sub-tab:

oracle weblogic tutorials howto example wls java ee

We need to fill in the Data Source name which will be used to connect to your database. You can leave all the other options to the default values. Then we need to restart the WebLogic server. After the reboot, we can go the User and Group tab of your default security realm where we can change or add users and roles.

Database schema setup

In order to get working with the Database authentication provider you need to create your schema where users and roles will be stored. A creation script is available at Github on the following address: ( in the SQLAuthenticator_createDB.txt 

Now just add your users using either direct SQL commands as follows:

insert into USERS (U_NAME,U_PASSWORD,U_DESCRIPTION) values(‘system’,’weblogic’,’admin user’);

insert into GROUPS (G_NAME,G_DESCRIPTION) values(‘Administrators’,’Administrators’);

insert into GROUPMEMBERS (G_NAME,G_MEMBER) values(‘Administrators’,’system’);

The only limitation is that passwords are not encrypted so either you can add users via console or via WLST script to store them in encrypted form. The following WLST script can be used to add users:











Remember to customize user, password and admin URL in the 1st line. Also replace domain name “base_domain” with your domain name in line 5. Finally change SQL authenticator name in line 6 with your authenticator name.

Posted on

Oracle Weblogic Security

Oracle WLS provides a complete security infrastructure which combines the JVM Security Manager and the standard JAAS authentication and authorization options. The main components of WLS Security service are illustrated by the following picture:

As you can see from the above picture, at the highest level WLS uses a Security API which combines with Java Security API. This security stack allows application developers to specify authorization information that is used when Oracle WebLogic Server acts as a client; it also allows application developers to obtain information about the Subject and Principals used by Oracle WebLogic.

Next stack is the Security Service Provider Interfaces (SSPI) for developing new security services that can be plugged into the Oracle WebLogic Server environment. SSPIs are available for Authentication, Authorization, Auditing, Role Mapping, Certificate Lookup and Validation and Credential Mapping.

The implementation of SSPIs are a set of WebLogic security providers. These security providers are the Oracle implementation of the SSPIs and are available by default in the Oracle WebLogic Server.


Configuring a WebLogic Security realm

A Security Realm is a mechanism for protecting all Oracle WebLogic Server resources. Each security realm consists of a set of configured security providers, users, groups, security roles and security policies. You can configure multiple security realms in a domain; however, only one can be the active security realm.

WebLogic Server provides a default security realm named myrealm which has the WebLogic Adjudication, Authentication, Identity Assertion, Authorization, Role Mapping and Credential Mapping providers configured by default.

You can access the security realm screen from the Administration console under the Domain | Security Realms option:

By clicking on the Configuration | General tab, you can configure the general behaviour of the security realm:

The Security Model Default determines how applications are protected by default.

When using the default option (DD Only) WLS only uses the roles and policies defined in the JEE deployment descriptors. Thus, if an EJB or a Web application is not protected by a role or policy in the DD, then it is unprotected and anyone can access it.

The other Security Model options allow to Customize Roles Only (which means that policies are taken from DD but Roles are customized) and Customize Roles and Policies (both Roles and Policies are customized). Finally the Advanced Security model is used mostly for backward compatibility with prior-to-9 releases of the application server. This model uses the roles and policies defined in the deployment descriptors to seed the WebLogic Server security roles and policies; it then uses the WebLogic Console to modify roles and policies from that point onward.