Single Sign-On in environments with Weblogic 11g

According to Oracle documentation, the Security Assertion Markup Language (SAML) 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.

Well, for the time beginning, I contribute anything about this issue so I’m going to show you in the next picture how must be set Weblogic environments to have two domains that participate in a SSO: Identity Provider domain (IDP) and Service Provider domain (SP). I will add LDAP authentication in IDP domain and SAML authentication in the SP domain to trust in users that only IDP knows. 

Obviously, I have simplified the architecture and both machines have its own local database where Weblogic RDBMS Security Store tables will be set and only have a server for each domain; the admin server. In the case of configure more servers, Oracle recommend enable JMS notification to synchronize security data in all servers within federated domain and configure replicated caches to avoid database delays. 

Well, once the problem is specified, we are going to fix it.

 

Configuring SAML 2.0 services

 

Prerequisites

 

Create a domain in which the RDBMS security store is configured. 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 de data.

For this reason, Weblogic RDBMS Security Store tables must be created in local databases from the above picture. These tables are in “$WL_HOME/server/lib” directory.

Configuring source domain (IDP)

1.  Create a credential mapper: ”myrealm” –> ”Providers” –> ”Credential Mapping” –> Add a ”SAML2CredentialMapper”.  

Once the credential mapper is created and server is rebooted, modify in “Provider specific” configuration tab from newly credential mapper “Issuer URI” and “Name Qualifier” fields. For example:  

   a.       Issuer URI: http://soaandme.blogspot.com.es

   b.      Name Qualifier: soaandme.blogspot.com.es

2.  Click on ”Servers” –> Admin Server –> ”Federation Services” –> ”SAML 2.0 Identity Provider” and change:

   a.       Enabled: check

   b.      Preferred Binding: POST

3.  Click on ”Servers” –> Admin Server –> ”Federation Services” –> ”SAML 2.0 General” and add all contact person info and organization info. Also you must set the next fields:

   a.       Replicated Cache Enabled – Uncheck / Check.

  b.     Published Site URL (http://<SourceSiteDNSName>:<PORT>/saml2): This URL specifies the base URL that is used to construct endpoint URLs for the various SAML 2.0 services. The published site URL should specify the host name and port at which the server is visible externally, which might not be the same at which the server is accessed locally. For example, if SAML 2.0 services are configured in a cluster, the host name and port may correspond to the load balancer or proxy server that distributes client requests to the Managed Servers in that cluster.

 c.    Entity ID (for example: “source_domain”): The entity ID is a human-readable string that uniquely distinguishes your site from the other partner sites in your federation. When your partners need to generate or consume an assertion, the SAML 2.0 services use the entity ID as part of the process of identifying the partner that corresponds with that assertion.

4.  Save the changes and export IDP metadata to an XML -> "Publish Meta Data" (idp_metadata.xml). Copy this XML file to target domain (SP domain).

Configuring destination domain (SP)

1. Create a identity asserter: ”myrealm” –> ”Providers” –> ”Authentication” –> new ”SAML2IdentityAsserter”.  

2.  Click on ”Servers” –> Admin Server –> ”Federation Services” –> ”SAML 2.0 Service Provider” and change:

   a.       Enabled: check

   b.      Preferred Binding: POST

3.  Click on ”Servers” –> Admin Server –> ”Federation Services” –> ”SAML 2.0 General” and add all contact person info and organization info. Also you must set the next fields:

   a.       Replicated Cache Enabled – Uncheck / Check.

   b.      Published Site URL (http://<DestinationSiteDNSName>:<PORT>/saml2).

   c.       Entity ID (for example: “destination_domain”).

4.  Save the changes and export SP metadata to an XML -> "Publish Meta Data" (sp_metadata.xml). Copy this XML file to target domain (IDP domain).

Configuring our service provider (SP) in the source domain (IDP)

1. Click on ”Security Realms” –> ”myrealm” –> ”Providers” –> ”Credential Mapper” –> select the newly created SAML2CredentialMapper –> ”Management” –> ”New” –> ”New Web Single Sign-On Service Provider Partner”.

   a.       Select the “sp_metadata.xml” file and click on OK.

   b.      Click on newly created element and change the next fields:

   i.                     Name

   ii.                   Enabled : Checked

   iii.                  Description

   iv.                  Key Info Included : Check

    2.   You can verify SP info in “Site Info” tab.

Configuring our identity provider (IDP) in the destination domain (SP)

1. Click on ”Security Realms” –> ”myrealm” –> ”Providers” –> “Authentication” -> select the newly created SAML2IdentityAsserter –> ”Management” –> ”New” –> “New Web Single Sign-On Identity Provider Partner”.

a.       Select the “idp_metadata.xml” file.

b.      Click on newly created element and change the next fields:

i.                     Name

ii.                   Enabled : Check

iii.                  Description

 

Considerations

• If you are configuring a SAML 2.0 Identity Provider or a SAML 2.0 Service Provider, you must configure the SAML 2.0 general services identically and individually in each WebLogic Server instance in the domain that will run SAML 2.0 services.
• If you are configuring a SAML 2.0 Identity Provider site, you must configure the SAML 2.0 Identity Provider services identically and individually in each WebLogic Server instance in the domain that will run SAML 2.0 services.
• If you are configuring a SAML 2.0 Service Provider site, you must configure the SAML 2.0 Service Provider services identically and individually in each WebLogic Server instance in the domain that will run SAML 2.0 services.

 

Configuring LDAP authentication in the source domain (IDP)

With the purpose of LDAP users are available to allow authentication and authorization in developed applications, the IDP must configure an LDAP Authenticator. To do this, the next steps are necessary:

1. Create an LDAP Authenticator: ”myrealm” –> ”Providers” –> ”Authentication” –> new ”LDAPAuthenticator”.  
2. Configure the newly created LDAP Authenticator with corresponding environment LDAP configuration.  

Configuring SAML authentication in the destination domain (SP)

With the purpose of SP trusts in users that it doesn’t know them but IDP authenticated them, configuring a SAML Authenticator is mandatory. This avoids configuring LDAP Authenticator in the SP domain, which is conceptually wrong. If we want configure SAML Authenticator, the next steps are necessary:

1. Create a SAML Authenticator: ”myrealm” –> ”Providers” –> ”Authentication” –> new ”SAMLAuthenticator”.
2.  This authenticator requires no configuration.
   
   

NOTE:

- IDP sample app: Download

- SP sample app: Download 

- To test this sample application login using "weblogic" user.

The principal I have used in weblogic.xml file of this application is: 

 <security-role-assignment>
 <role-name>SamlTrainee</role-name>
 <principal-name>Administrators</principal-name>
 </security-role-assignment>

- Change to your respective host / IP address in the application jsp pages.

- Change or add LDAP users as principal to security-role-assignment.