Monday May 30, 2016

Steps to create partitions in WLS 12.2.1

Below are the steps to create partitions in Weblogic Server 12.2.1 :

Step 1 :

- Create a weblogic domain (say Partition_From_Windows_Domain)

FMW control is the recommended console for Partition management, so it is good to enable it at the time of  domain creation.  

To enable FMW control select "Oracle Enterprise Manager-Restricted JRF - 12.2.1 [em]" template in the configuration wizard, as shown below :

To access FMW control access : http://<host>:<port>/em

NOTE : We will continue using Weblogic Admin console to create partitions in this example.

Partition names : coke-partition and pepsi-partition

Partition specific realms : coke_realm and pepsi_realm

Partition specific Admin Users : coke_admin and pepsi_admin

Virtual Targets for these partitions : coke-vt and pepsi-vt

Partition Specific Resource Groups : coke-rg1 and pepsi-rg1

Step 2 :

Before creating a partition, you need to create a security realm (then create an Admin user inside this realm, say coke_admin and pepsi_admin) and virtual target for this partition :

To create a new security realm :

Login to console -> Security Realms -> new (say 'coke_realm' and 'pepsi_realm') -> "create default providers within this new realm" (check)

Now create a Virtual target :

Login to console -> + Environment -> Virtual Targets -> new (say coke-vt) and target it to Weblogic Server (say Admin Server) -> specify a URI Prefix

Step 3 :

Lets create a partition now :

Login to console -> Domain Partitions -> new (say coke-partition)-> then target it to a Virtual target (say coke-vt) -> select the security realm for this partition from the drop down menu (say coke_realm)

 Step 4 :

Create a Resource Group inside domain partition

 Step 5 : 

Check the Identity Domains of the partitions :

Step 6 :

You can now deploy applications to Global scope / to a resource group of a partition

To access the application deployed to your partition use the following URL :

http://<host>:<port>/coke/Weblogic_SP_sample_App/login.jsp  ==> Try to login with the coke Admin and also test the login using weblogic user.

Perform similar tests with application deployed on pepsi-partition and global scoped deployment.

Friday Mar 11, 2016

Steps to configure SAML 2.0 with Okta as IDP and Weblogic as SP

Okta is one of the third party SAML Identity Providers which can be configured with Weblogic Server for Single Sign-On.

In this post we will see, how to configure Okta as a SAML 2.0 Identity Provider and Weblogic Server as a SAML Service Provider.....

[Read More]

Wednesday Mar 04, 2015

Steps to create a .jks keystore from .pfx file

What are the different certificate extensions ?

How do they differ from each other ?

Common filename extensions for X.509 certificates are:

.pem – (Privacy-enhanced Electronic Mail) Base64 encoded DER certificate, enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----"

.cer, .crt, .der – usually in binary DER form, but Base64-encoded certificates are common too.

If you have a .pem file (Base64) then you can directly rename the file to .cer / .crt and open the certificate in Windows to view its contents. ( by double clicking on the file ) 

.p7b, .p7c – PKCS#7 SignedData structure without data, just certificate(s) or CRL(s)

.p12 – PKCS#12, may contain certificate(s) (public) and private keys (password protected)

.pfx – PFX, predecessor of PKCS#12 (usually contains data in PKCS#12 format, e.g., with PFX files generated in IIS)

PKCS#7 is a standard for signing or encrypting (officially called "enveloping") data. Since the certificate is needed to verify signed data, it is possible to include them in the SignedData structure. A .P7C file is a degenerated SignedData structure, without any data to sign.

PKCS#12 evolved from the personal information exchange (PFX) standard and is used to exchange public and private objects in a single file.

 Source : 

In this post we will see how to convert a pfx file to pem / JKS.....

[Read More]

Monday May 05, 2014

Steps to configure Custom Identity and Custom Trust with Weblogic Server

What are the different ways keystore can be configured with Weblogic Server ?

What is the default keystore configuration in Weblogic ? 

Weblogic is configured with DemoIdentity and DemoTrust by default.

If you have generated any of the following certficate / keystores then you need to configure a CustomIdentity and CustomTrust as shown in this blog post :

 - Self signed certificate / keystore

- Generated a csr and got a certificate signed from a 3rd party Certificate Signing Authority ( CA ) 

- Generated a csr and got the certificate signed by an internal CA.

 You can also configure a Custom Identity and Java Standard Trust when you have any of the above certificates.

 In case of CustomIdentity and JavaStandardTrust, we create a Identity keystore and for the Trust keystore we make use of the default JDK Trust store i.e cacerts.

We need to import the root/intermediate certificate to cacerts using the following command :

keytool -import -file <root_certificate> -keystore <JDK>/lib/security/cacerts -storepass changeit 

In this post we will see how to configure a Custom Identity and Custom Trust with Weblogic Server.........

[Read More]

Wednesday Apr 02, 2014

Steps to configure SAML 2.0 with Shibboleth ( deployed on WLS ) as IDP and Weblogic as SP.

Shibboleth is a free and open source federated identity solutions.

Points to Remember:

The logging configuration for the IdP is located at $IDP_HOME/conf/logging.xml. This file is checked for changes every 10 minutes  by default and is reloaded if changes have been made. 
This means a deployer can keep the logging level at WARN until a problem occurs and then change the logging to DEBUG to get more information if the problem persists, all without restarting the IdP.

By default Shibboleth 2.0 Identity Providers write to three log files :

- idp-access.log contains a log entry for each time the IdP is accessed, whether information was ever sent back or not. These messages include request time, remote host making the request, server host name and port, and the request path. This log is written in the machine parsable format requestTime|remoteHost|serverHost|serverPort|requestPath|.

- idp-audit.log contains a log entry for each time the IdP sends data to a relying party. These messages include the audit event time, IdP and relying party IDs, request and response binding, communication profile ID, request and response ID, principal name, authentication method, and released attribute of the current user. This log is written in the machine parsable format auditEventTime|requestBinding|requestId|relyingPartyId|messageProfileId|assertingPartyId|responseBinding|responseId|principalName|authNMethod|releasedAttributeId1,releasedAttributeId2,|nameIdentifier|assertion1ID,assertion2ID,|
Note the name identifier and assertion IDs were added in V2.1.

- idp-process.log contains messages logged during the normal operation of the IdP. This log is meant to be human readable and contains messages that indicate what the IdP is currently doing, encountered errors, warning messages that may indicate potential problems, etc.

All logging messages are "rolled over" at midnight each night, if the IdP is running, or the next time the IdP starts up after that.

You can test your configuration here :

Here are few other sites which might be helpful :


SAML2 Assertions encryption is a feature that is not supported by any current version of WebLogic Server, whatever the Identity Provider.

SAML2 Assertions in WebLogic Server are base64 encoded but not encrypted.

In the case of Shibboleth Identity Provider, the default Out-Of-The-Box configuration is to require encryption of the SAML2 Assertions. Thus, this issue is usually raised when using Shibboleth as the Identity Provider.

Shibboleth can be configured to use non-encrypted SAML2 Assertions, for instance check this :

Link :

The wiki describes the way to configure Shibboleth when used in conjunction with WebLogic Server.

In this post we will see how to configure SAML 2.0 SSO using Shibboleth as IDP ( deployed on WLS ) and Weblogic as SP...

[Read More]

Friday Oct 04, 2013

Steps to create a .jks keystore using .key and .crt files...

How to create a .key and .crt file ?

If we already have a .key and .crt file how do we import them into a .jks keystore file ? 

How to convert a certificate from DER format to PEM format ? 

Keytool cannot import/export a private key into a keystore file.

To import a private key we need to use other tools like openssl.

We have seen situations when in we get a .key and .crt file from our vendors and we need to import the same into a .jks keystore to configure SSL with WLS.

Here .crt is the signed certificate from a CA and .key contains the private key.

To import these two files into a .jks keystore we can use the following command :

Syntax : $ java utils.ImportPrivateKey keystore storepass storetype keypass alias certfile keyfile keyfilepass

The ImportPrivateKey utility is used to load a private key into a private keystore file.

You can use the CertGen utility to create a .key ( testkey ) and .crt ( testcert ) and then use the ImportPrivateKey utility to create a .jks file.

Note: By default, the CertGen utility looks for the CertGenCA.der and CertGenCAKey.der files in the current directory, or in the WL_HOME/server/lib directory, as specified in the weblogic.home system property or the CLASSPATH.

Alternatively, you can specify CA files on the command line. If you want to use the default settings, there is no need to specify CA files on the command line.

1. Enter the following command to generate certificate files named testcert with private key files named testkey:

Command : $ java utils.CertGen -keyfilepass mykeypass -certfile testcert -keyfile testkey

2. Convert the certificate from DER format to PEM format.

Command :  $ java utils.der2pem CertGenCA.der

3. Concatenate the certificate and the Certificate Authority (CA).

Command :  $ cat testcert.pem CertGenCA.pem >> newcerts.pem

4. Create a new keystore named mykeystore and load the private key located in the testkey.pem file.

Command :  $ java utils.ImportPrivateKey -keystore mykeystore -storepass mypasswd -keyfile mykey -keyfilepass mykeypass -certfile newcerts.pem -keyfile testkey.pem -alias passalias

In this post we will see how to import a .crt and .key file into a .jks file.

[Read More]

Saturday Aug 24, 2013

Steps to create a self-signed certificate and configure Custom Identity and Custom Trust with Weblogic Server using Keytool...

 What are self signed certificates and how to create them ?

A self-signed certificate is an identity certificate that is signed by the same entity whose identity it certifies.

 This term has nothing to do with the identity of the person or organization that actually performed the signing procedure. In technical terms a self-signed certificate is one signed with its own private key.
 Note :
 Identity keystores must contain a private key entry
 Trust store must contain all trusted key entries
 Below are few default values when using keytool command on JDK 1.6 :
 -alias "mykey"
    "DSA" (when using -genkeypair)
    "DES" (when using -genseckey)
    1024 (when using -genkeypair)
    56 (when using -genseckey and -keyalg is "DES")
    168 (when using -genseckey and -keyalg is "DESede")
-validity 90

Note :

-genkey is used in the example here. This was an old name used in previous releases. This old name is still supported in this release and will be supported in future releases, but for clarify the new name, -genkeypair, is preferred going forward.

Changes in keytool in Java 1.6 :

keytool no longer displays password input when entered by users. Since password input can no longer be viewed when entered, users will be prompted to re-enter passwords any time a password is being set or changed (for example, when setting the initial keystore password, or when changing a key password).

Some commands have simply been renamed, and other commands deemed obsolete are no longer listed in this document. All previous commands (both renamed and obsolete) are still supported in this release and will continue to be supported in future releases. The following summarizes all of the changes made to the keytool command interface:

Renamed commands:

-export, renamed to -exportcert
-genkey, renamed to -genkeypair
-import, renamed to -importcert
Commands deemed obsolete and no longer documented:



In this post we will see how to create self-signed cretificates and configure it Weblogic Server 10.3.6 ( CustomIdentityandCustomTrust ).

[Read More]

Wednesday Jul 31, 2013

Steps to configure SAML 2.0 with Weblogic Server (using embedded LDAP as a security store - Only for Dev Environment)...

 What is SAML 2.0 ?

Security Assertion Markup Language 2.0 (SAML 2.0) is a version of the SAML standard for exchanging authentication and authorization data between security domains.

SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, that is an identity provider, and a SAML consumer, that is a service provider

It enables cross-platform authentication between Web applications or Web services running in a WebLogic domain and Web browsers or other HTTP clients.

When users are authenticated at one site that participates in a single sign-on (SSO) configuration, they are automatically authenticated at other sites in the SSO configuration and do not need to log in separately.

One who generated the SAML token is called the Identity Provider OR Asserting Party OR Source Site.

And the one accepts the token is called the Service Provider OR Relying Party OR Destination Site.
Trust has to be established between them for SAML to work hence details of the Service Provider has to be with the Identity Provider and details of Identity Provider has to be with the Service Provider.

SAML can be classified into two types depending on the manner in which requests are obtained.

- IDP initiated ( Identity Provider Initiated )

- SP initiated ( Service Provider initiated )

In this post we will see how to configure Single sign-on (SSO) using SAML 2.0 in Weblogic Server. 

[Read More]

Oracle Fussion Middleware - WebLogic


« July 2016