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]

Tuesday Sep 08, 2015

Steps to configure SAML SSO with ADFS (as IDP) and Weblogic Server (as SP)

Active Directory Federation Services (ADFS) is a software component developed by Microsoft that can be installed on Windows Server operating systems to provide users with single sign-on access to systems and applications located across organizational boundaries.

In this example we are using ADFS 2.0 on Windows Server 2008 R2.

ADFS 2.1 is available on Windows 2012 and ADFS 3.0 on Windows 2012 R2.

AlternateLoginID feature is introduced in Windows Server 2012 R2.

You can download ADFS from the following link : 

Link :  --> " RTW\W2K8R2\amd64\AdfsSetup.exe " for Windows Server 2008 R2.

In this post we will see how to configure Single sign-on (SSO) using SAML where ADFS is used as Identity Provider and Weblogic is used as a Service Provider. 

[Read More]

Tuesday Mar 31, 2015

How to configure a Custom IDP login page for SAML SSO in Weblogic

In case of an IDP initiated SSO, you can either get an initial challenge from the browser or you can customize it by using a FORM login by changing the <auth-method> in the web.xml file of your SourceApplication.

However, if you are doing a SP initiated SSO, then the challenge you get from IDP is always a BASIC challenge from browser.

How do you customize this ?

Can you create a custom login page ?

In this post we will see how to configure a Custom IDP login page.....

[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]

Wednesday Dec 11, 2013

Steps to configure SAML 2.0 with Weblogic Server (using Oracle DB as a RDBMS security store)...

 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 )


- The RDBMS security store is required by the SAML 2.0 security providers in production environments so that the data they manage can be synchronized across all the WebLogic Server instances that share that data.

- Note that Oracle does not recommend upgrading an existing domain in place to use the RDBMS security store. If you want to use the RDBMS security store, you should configure the RDBMS security store at the time of domain creation. If you have an existing domain with which you want to use the RDBMS security store, create the new domain and migrate your existing security realm to it.

- For testing purpose you can use embedded LDAP instead of an external RDBMS store. 

In this post we will see how to configure SAML2 with Weblogic Server using Oracle DB as a RDBMS security store. 

[Read More]

Oracle Fussion Middleware - WebLogic


« August 2016