Using SQL Developer debugger with Oracle DB Cloud Service

Oracle Database Cloud Service provides a very agile Cloud environment for your database workload, either as production and development. In the latter case is a good choice for experienced SQL developer to continue to use their common development environment while connecting to the Cloud Database. Before doing this you need to perform few configuration steps that are described in this post. 

SQL Developer runs by default in "Remote Debugger" mode. It means that SQL Developer listens on a port for events coming from the Database. This allows the developer to debug a PL/SQL either launching it from the tool or even from a different session, e.g. from a Web Application while watching what is going on in the IDE window. This is a very smart option but requires SQL Developer to listen and Database to send events to the tool. 

When running the Database in Cloud, the debug session will probably fail because your workstation is not accessible from the internet and the port SQL Developer is listening on is not open on the corporate firewall. 

You then have two solutions: 

• ask your network admin to open the firewall and let your IP address to be published on the Internet, or 
• disable "Remote Debugging". 

In the latter you'll only be able to debug a PL/SQL if you run it from the IDE, but you'll have all the debug features available. 
To disable "Remote Debugging" exit SQL Developer and insert the line:

DatabaseDebuggerDisableJDWP=true  

into ide.properties file, which is usually located in: 

C:\Users\AppData\Roaming\SQLDeveloper\system${VERSION}\o.sqldeveloper.${SYSTEM_VERSION} on Windows or in:

$HOME/.sqldeveloper/system${VERSION}/o.sqldeveloper.${SYSTEM_VERSION}/ide.properties on Linux.

Restart SQL Developer and Happy Debugging. 


Post Scriptum SQL Developer can connect to Oracle Cloud directly to port 1521 or by SSH tunneling. You can find plenty of resources in Internet on the topic.

Building a secure architecture for JEE application using Oracle solutions

Table of Contents

• Summary
• Security in dept
• Description
• What has been left out

Summary

More and more today is important to define new applications architecture with security in mind to be able to reduce the area of possible attacks and to be as efficient as possible in the detection and reaction to intrusions.

I am describing here a possible secure architecture that can be implemented to protect a JEE application and the Database where data are stored from malicious users and external subjects that want to get access to sensible data.

While I am not an information security expert, this paper is the result of my personal experience in designing and configuring security for JEE systems.

Security in dept

The main concept I tried to apply is to apply several security layers that are indipendent from each others, thus providing:

• the ability to use a different set of layers, depending of the project type and environment
• the ability to detect and block intrusion attempts that may have passed a more external security layer

This approach is useful while building a new application but also when securing an existing application that can be secured incrementally adding security features based on the threats and risks assessment and budget related considerations.

Description

The following figure describes the architecture and the component that are part of it. Oracle product are in red while non Oracle product are in blue.

The main components of the application are WebLogic Server and Oracle Database. I first require that that users connect to WLS via HTTPS only and that must authenticate providing a digital certificate (doc, blog) configuring Two-Ways SSL and X.509 Identity Provider.

An appropriate configuration of WebLogic Identity Assertion Provider and Authentication Provider will enable the application to get the user identity from the X.509 Certificate and to map it to user name stored in the user repository, hereby defined as an LDAP registry. Note that the Security Provider architecture in WebLogic gives a lot of freedom to the developers: they can write their application using Java standard security API's (JAAS) whatever provider will be user later on. (doc)

Application security is configured using WebLogic Custom Roles model; this means that developers modify the deployment descriptor to define which resources have to be protected and the names of roles that can access them. WebLogic administrator will configure the roles mapping to map users or groups to roles. (doc)

Although the use of JPA does not guarantee from SQL Injection, it makes easier to protect the application from such types of attacks: the web is full of resources that can help the developer to get familiar with these techniques.

Now we get closer to the data layer; since we are using Oracle Database, we can configure the JDBC provider to make use of CLIENT_IDENTIFIER. In this way the JDBC driver will open a pool of connection using a pre-configured user and (encrypted) password, but when the application makes use of a connection, the driver will pass the application user name in the CLIENT_IDENTIFIER parameter. Oracle Database can then use it for security and accounting operation that I'll describe later on. (doc)

Between WebLogic and Database I setup an instance Oracle Database Firewall (full name: Audit Vault and Database Firewall, ie. AVDF) that will inspect the SQL through its SQL grammar analysis engine. It is a choice of the administrator to configure AVDF with a Black List (block or alert when something matches the rules in the list) or White List (block or alert when something does not match the rules in the list). In my opinion the White List is more secure but it is harder to configure. AVDF also provides more filters and features; please refer to the documentation for a complete list. (doc)

The database is implementing a set of Option in order to protect the data from inappropriate access and usage.

As the user identity is sent from the application server to the database with the CLIENT_IDENTIFIER parameter, the database is able to map it to the same user repository used by WebLogic Server. To do this it is necessary to configure Enterprise User Security.

The data can be protected from unwanted access at a very fine granularity using security labels (eg. Top Secret, Secret, etc) applied to each table or line that requires it. Oracle Label Security will verify if the label defined on the database object and the credential owned by the user match before delivering the data. (doc)

An additional barrier to data leak is the ability to implement some Separation of Duty rules on database users. Normally database administrators are able to see and change the data. I thus suggest the use of Database Vault to implement preventive controls on privileged user access to application data. (doc)

While I assume the Operating Systems has been hardened, it is a good rule to encrypt the data at rest ie. on the physical media. This can be done with Oracle Transparent Data Encryption. The data is encrypted by the database engine transparently to the client protecting the data files and the backup files from malicious access by operationg systems users. (doc)

What has been left out

Since I focused on single application eg. a department application, I did not cover many important components of an enterprise architecture, here I list three of them: Access Manager, Identity Manager and User Repository.

Oracle Access Manager is used to add a perimetral access control layer that can authenticate users using multiple schems, implement a Single Sign On infrastructure and define coars-grained authorization.

Oracle Identity Manager can be added to manage the lifecycle of identities and roles, regulatory compliance, auditing.

Finally, the architecture shows a LDAP user repository but of course the implementation choice is important. Oracleuser repository is called Oracle Internet Directory.

Configuring Single Sign-On using SAML in WebLogic Server 12.2.1

Configuring Single Sign-On using SAML in WebLogic Server 12.2.1

by Guido Campani, based on Configuring Single Sign-On usingSAML in WebLogic Server 9.2 by Vikrant Sawant.
09/04/2017

Abstract

This Guide has been tested and revised for WebLogic Server 12.2.1 running on Oracle Linux 6.4. I made few changes to Vikrant Sawant's work to reflect my tests that included adding a third domain in the single sign-on architecture. References to WebLogic Server 9.2 still appears in the document: this is intended as a recognition to the work of the original author.
BEA WebLogic Server 9.2 provides out-of-the-box support for Security Assertion Markup Language (SAML) to build single sign-on (SSO) solutions with minimum or no coding, depending on your security requirements. Using WebLogic Server 9.2, the single sign-on capability can be easily added between multiple online applications running on trusted domains. The SAML standard defines a framework for exchanging security information between the federation of trusted servers. The primary function of the security framework is to provide configuration tools and APIs to secure your applications.
The first part if this tutorial provides step by step instructions to configure the single sign-on capability between two simple Java EE Web applications running on two different WebLogic domains.
The second part describes how to add a third domain in the single sign-on scenario.
The SAML configuration for single sign-on is performed using the WebLogic Server 9.2 Administration Console with no programming involved. The tutorial also briefly introduces the basic interactions between WebLogic containers, the security providers, and the security framework during the single sign-on process.

Introduction

The SAML standard defines a framework for exchanging security information within the federation of trusted servers. For some background, read Introduction to SAML by Beth Linker (Dev2Dev, 2006). This tutorial shows how to set up SAML authorization between two Web applications. The source for these applications is provided here.
This tutorial looks at a simple example involving two Web applications; appA deployed on the source (local) site, and appB deployed on the destination (remote) site. You'll learn how to configure these applications using the WebLogic Server 9.2 Administration Console and participate in a SSO process using SAML.
The source site provides an authentication service and securely passes the authentication details using SAML Inter-site Transfer Service (ITS) when requested by the destination site. The server on the source site includes an ITS servlet, which is an addressable component that provides SAML processing functionality such as artifact generation and the ability to redirect a user to the destination site.
Figure 1 shows the basic interaction between source site and destination site during the SSO process.

Figure 1. Interaction between source site and destination site, using SAML, during single sign-on

1. The user's browser accesses the application appA(source site), hosted on a WebLogic Server domain, called domainA, by supplying user credentials.
2. The application appA passes the user credentials to the authentication service provider.
3. If authentication is successful, the authenticated session is established, and a welcome page of appA is displayed.
4. From the welcome page, the user then clicks on a link on the page to access a secured Web page of application appB (destination site), hosted on a different WebLogic Server domain, called domainB. This triggers a call to the Inter-Site Transfer Service (ITS) servlet.
5. The ITS servlet calls the SAML Credential Mapper to request a caller assertion. The SAML Credential Mapper returns the assertion. It also returns the URL of the destination site application Web page (a secured Web page of appB) and path to the appropriate POST form (if the source site is configured to use the POST profile).
6. The SAML ITS servlet generates a SAML response containing the generated assertion, signs it, base-64 encodes it, embeds it in the HTML form, and returns the form to the user's browser.
7. The user's browser POSTs the form to the destination site's Assertion Consumer Service (ACS).
8. The assertion is validated.
9. If the assertion is successful, the user is redirected to the target—that is, the secured Web page of the appB application.
10. The user is logged in on the destination site application appB, without having to reauthenticate at appB.
    

The whole single sign-on process listed above requires no coding by the developer (except for the coding of applications appA and appB, of course) and can be easily configured using the Administration Console.

Part 1

SAML Configuration Using the WebLogic Administrative Console

Before starting the SAML configuration, in the first few steps you'll create and set up the server environment for the sample applications appA and appB.

Step 1: Create SAML source site and destination site domains and application servers

The sample applications in this tutorial are hosted on two domains on the local host, so the first step is to create the domains and servers running on given ports, as listed below in Table 1.

	Host	Application Server	Application Name	Port	SSL Port
SAML Source Site Domain: domainA	localhost	AdminServer	appA	7001	7002
SAML Destination Site Domain: domainB	localhost	AdminServer	appB	7003	7004

Table 1. Sample application domains and application servers
Create domains, as shown in Table 1, using the Domain Configuration Wizard. I configured them as in Production Mode; AdminServer is the only server in the domain. No Managed Servers are configured. Update the appropriate listen ports using the WebLogic Server 9.2 Administration Console.

Step 2: Create users

For simplicity, this tutorial uses the default security realms on each domain, each named with the same default realm name, that is, myrealm. Create a user ssouser in each domain separately under the myrealm realm. Alternatively, you could create this user in a centralized external LDAP store and configure both domains to use this common store for authentication.
The user ssouser created here will authenticate with application appA hosted on domainA, and then access application appB hosted on domainB directly using SSO.

	Realm	User/Password
SAML Source Site Domain: domainA	myrealm	ssouser/welcome1
SAML Destination Site Domain: domainB	myrealm	ssouser/welcome1

Table 2. The user participating in single sign-on
Create the user, ssouser, as shown in Table 2, in both domains under the default security realms, each called myrealm.

Step 3: Create and deploy the Java EE Web applications appA and appB

The sample application source code for appA can be downloaded here. Import the existing Web application into WebLogic WorkShop Studio or any other IDE, such as Eclipse.
Application appA is configured to use FORM-based authentication. This application is deployed on the SAML source site domain ( domainA). A JSP page of appA called auth.jsp, under the admin folder, requires the authenticated user to have an admin role in order to access it. The admin role is mapped to a principal called ssouser in weblogic.xml. Figure 2 shows the configuration of the security in web.xml.

<display-name>Saml Source Site
Application</display-name>

<security-constraint>

        <web-resource-collection>

               
<web-resource-name>SecurePages</web-resource-name>

                <description>These pages
are only accessible by authorized users.</description>

               
<url-pattern>/admin/*</url-pattern>

                <http-method>GET</http-method>

        </web-resource-collection>

        <auth-constraint>

                <description>These are the
roles who have access.</description>

                <role-name>admin</role-name>

        </auth-constraint>

        <user-data-constraint>

                <description>This is how
the user data must be transmitted.</description>

               
<transport-guarantee>NONE</transport-guarantee>

        </user-data-constraint>

</security-constraint>

<login-config>

        <auth-method>FORM</auth-method>

        <realm-name>myrealm</realm-name>

        <form-login-config>

               
<form-login-page>/login.jsp</form-login-page>

               
<form-error-page>/fail_login.htm</form-error-page>

        </form-login-config>

</login-config>

<security-role>

        <description>These are the roles
who have access</description>

        <role-name>admin</role-name>

</security-role>

Example 1. Application appA - web.xml snippet
When the user tries to access the /admin/auth.jsp page, a configured login page, login.jsp, will be displayed, asking the user to supply credentials. After submitting the details, the container will authenticate the user ssouser. If authentication is successful, the auth.jsp will be displayed. Before going on to explore the Web page auth.jsp, I'll create the application appB on the SAML destination site domain ( domainB).
Sample application source code for appB can be downloaded from the here. Application appB is configured to use CLIENT-CERT, so that it will use identity assertion for authentication. This application should be deployed on the SAML destination site domain ( domainB). A JSP page of appB, called services.jsp and located in the /admin folder, requires the authenticated user to have the admin role in order to access it. This role is mapped to a principal called ssouser in weblogic.xml. Figure 3 shows an excerpt from appB's web.xml configuration:

<display-name>SAML Destination Site
Application</display-name>

 <!-- ... -->

<security-constraint>

        <web-resource-collection>

               
<web-resource-name>SecurePages</web-resource-name>

                <description>These pages
are only accessible by authorized users.</description>

               
<url-pattern>/admin/*</url-pattern>

                <http-method>GET</http-method>

        </web-resource-collection>

        <auth-constraint>

                <description>These are the
roles who have access.</description>

                <role-name>admin</role-name>

        </auth-constraint>

        <user-data-constraint>

                <description>This is how
the user data must be transmitted.</description>

               
<transport-guarantee>NONE</transport-guarantee>

        </user-data-constraint>

</security-constraint>

<login-config>

        <auth-method>CLIENT-CERT</auth-method>

        <realm-name>myrealm</realm-name>

</login-config>

<security-role>

        <description>These are the roles
who have access.</description>

        <role-name>admin</role-name>

</security-role>

Example 2. Application appB - web.xml snippet
Compile and build the WAR files ( appA.war,appB.war) for each application. Use WebLogic Console to deploy appA.war and appB.war.
When the SAML configuration has been completed, as described in the steps to follow, the user ssouser, authenticated at appA (SAML source site), will be able to directly access the services.jsp page of appB (SAML destination site) without being asked to supply the credentials again.

Step 4: Generate and register SSL certificates

To secure communication between the SAML source and destination sites, communication between the source site and destination site should be encrypted. Additionally, certificates should be used to verify the identity of the other party during SAML interaction. In this step I'll create and register certificates that will be used in the communication between the source site and the destination site.
Generate a key using the keytool utility (part of your JDK). By default, a keystore called DemoIdentity.jks will already be configured for domainA and domainB.
Now I'll show how to generate a private key and certificate for test purposes:

1. Open a terminal window and change the directory to $DOMAIN_HOME/security for domainA
2. Run the keytool command to generate the key, as shown below.
   

keytool -genkey -keypass testkeypass -keystore
DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -keyalg
rsa -alias testalias

Figure 2. Generate test SSL certificate screen shot
Now run the keytool command with -export option, as shown in Figure 2, to generate a key file called testalias.der:

keytool -export -keypass testkeypass -keystore
DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -alias
testalias -file testalias.der

SAML Configuration

I'll begin with the SAML source site configuration.

Step 5: Configure domainA, acting as a SAML source site

In this step I will create and configure a SAML Credential Mapper V2 instance. The SAML Credential Mapper acts as a producer of SAML security assertions, allowing domainA to act as a source site for using SAML for SSO.
A SAML security assertion is a package of information that supplies one or more statements made by a SAML authority (meaning an asserting party). The statements made are of the following types; authentication statements, attribute statements, and authorization decision statements.
I'll start by configuring a SAML Credential Mapper V2 instance (note that the SAML Credential Mapper V1 is deprecated as of BEA WebLogic Server 9.2):

1. Log in to the WebLogic Server Administration Console on domainA (http://localhost:7001/console).
2. In the administration console, select Security Realms in the Domain Structure window
3. Select a security realm. The default realm used is myrealm.
4. Select the Providers tab, and then select the Credential Mappings tab.
5. If SAMLCredentialMapper doesn't exist, then create a new SAMLCredentialMapper, as shown in Figure 3.
   

Figure 3. Create a new SAML credential mapping provider

6. Select SAMLCredentialMapper, and then select Provider Specific.
7. In the Change Center window, select Lock and Edit; this will allow you to edit the SAMLCredentialMapper settings.
8. Edit the issuer URI, http://www.bea.com/demoSAML. This unique URI tells the destination site (domainB/appB) the origin of the SAML message and allows it to match with the key. Typically, the URL is used to guarantee uniqueness.
9. Enter the Signing Key Alias (testalias) and the Signing Key Pass Phrase (testkeypass). You used these values when you generated the keystore.
10. Set the Default time to Live and Cred Cache Min Viable TTL and other values, as shown in Figure 4.
    

Figure 4. SAML credential mapping provider settings

11. Click Save.
12. In the Change Center window, click Activate Changes.
    

At this point the SAML credential mapper provider is configured to allow domainA to act as a source site (source of SAML security assertions) and also it is configured to use the keystore you generated in Step 4.

Step 6: Configure relying party properties

In this step I'll create and configure a relying party. When you configure WebLogic Server to act as a source of SAML security assertions, you need to register the parties that may request SAML assertions that will be accepted. For a SAML relying party, you can specify: the SAML profile used, details about the relying party, and the attributes expected in assertions for the relying party.
The relying party determines whether it trusts the assertions provided to it by the asserting party. SAML defines a number of mechanisms that enable the relying party to trust the assertions provided to it.

1. On the Management tab, click Relying Parties.
2. In the Relying Parties table, click New.
3. In the Profile pull-down menu, select Browser/POST. In the Description field, enter the name demoSAML to identify the relying party, as shown in Figure 5.
   

Figure 5. Relying party configuration

4. Set the relying party values, as listed in Table 3.
   

Parameter	Value
Enabled	Select the checkbox(true)
Target URL	http://localhost:7003/appB/admin/services.jsp
Assertion Consumer URL	https://localhost:7004/samlacs/acs
Assertion Consumer Parameters	APID=ap_00001
Signature Required	Select the checkbox(true)
Include Keyinfo	Select the checkbox(true)

Table 3. Relying Party (rp_00001) Values
Although a relying party may trust the assertions provided to it for user ssouser, the local access policy on the destination site application appB on domainB defines whether the subject ( ssouser) may access local resources.

Step 7: Configure SAML on the source site

In this step I'll configure various federation services source site settings for the server instance running the application appA. These settings enable server instances running on domainA to serve as a SAML source site, define the source site URIs and service URIs, add certificate to sign assertions, and configure SSL for retrieving assertions.

1. In the administration console, in the Domain Structure window, select Environment and then Servers.
2. Select AdminServer, and then in the Settings for AdminServer, click Federation Services on the SAML 1.1 Source Site tab, as shown in Figure 6.
   

Figure 6. Source site configuration

3. Set the source site values, as listed in Table 4.
   

Parameter	Value
Source Site Enabled	Select the checkbox (true)
Source Site URL	http://localhost:7001/appA
Signing Key Alias	testalias
Signing Key Passphrase	testkeypass
Intersite Transfer URIS	/samlits_cc/its (keep the other values)
ITS Requires SSL	Select the checkbox (true)
Assertion Retrieval URIs	/samlars/ars
ARS Requires SSL	Select the checkbox(true)

Table 4. Source Site Values

Step 8: Configure domainB, acting as a SAML destination site

I'm ready to begin the SAML destination site configuration. In this step I'll create and configure a SAML Identity Assertion Provider V2 instance. The SAML Identity Assertion provider acts as a consumer of SAML security assertions, allowing WebLogic Server to act as a destination site for using SAML for single sign-on. The SAML Identity Assertion provider validates SAML assertions by checking the signature and validating the certificate for trust in the certificate registry maintained by the provider. The first thing I need to do here is to create a SAML Identity Assertion Provider V2 instance and import the certificate generated in step 4 into the provider's certificate registry.
Import the certificate:

1. Copy the key file ( testalias.der) that you generated previously to the $DOMAIN_HOME/security directory for domainB.
2. Log in to the WebLogic Server Administration Console on domainB.
3. Select a security realm, myrealm.
4. Select the Providers tab, and then select the Authentication tab.
5. If a SAMLIdentityAsserter doesn't exist, then create a new SAMLIdentityAsserter, as shown in Figure 7. An identity asserter allows WebLogic Server to establish trust by validating a user.
   

Figure 7. Create a new Identity asserter

6. Select SAMLIdentityAsserter, click the Management tab, and then click Certificates.
7. In the Certificates dialog, click New, as shown in Figure 8.
   

Figure 8. Create a new identity asserter certificate

8. In the Alias field, enter a name for the certificate. Good practice is to use the same name you used when you created the certificate.
9. Enter the path to the certificate file in the Certificate File Name field.
10. Click Finish. If there are no problems, the message "The certificate has been successfully registered." is displayed.
    

Step 9: Configure asserting party properties

In this step I'll create and configure an asserting party. When you configure WebLogic Server to act as a consumer of SAML security assertions, you need to register the parties whose SAML assertions will be accepted. For a SAML asserting party, you can specify the SAML profile used, details about the asserting party, and the attributes expected in assertions received from the asserting party.
The asserting party asserts that a user has been authenticated and given associated attributes. For example, there is a user ssouser, and he/she is authenticated to this domain using a password mechanism. Asserting parties are also known as SAML authorities.

1. On the Management tab, click Asserting Parties.
2. In the Asserting Parties table, click New.
3. In the Profile pull-down menu, select Browser/POST. In the Description field, enter the name demoSAML to identify the asserting party, as shown in Figure 9.
   

Figure 9. Create a new asserting party

4. Set the asserting party values, as listed in Table 5.
   

Parameter	Value
Enabled	Select the checkbox(true)
Target URL	http://localhost:7001/appA
POST Signing Certificate alias	testalias
Source Site Redirect URIs	/appB/admin/services.jsp
Source Site ITS URL	https://localhost:7002/samlits_ba/its
Source Site ITS Parameters	RPID=rp_00001
Issuer URI	http://www.bea.com/demoSAML
Signature Required	Select the checkbox(true)
Asserting Signing Certificate Alias	testalias

Table 5. Asserting Party (ap_00001) Values

 
Figure 10. Asserting Party (ap_00001) Values

Step 10: Configure the SAML 1.1 destination site

In this step I'll configure various destination site settings for the server instance running application appB. These settings enable a server instance running on domainB to serve as a SAML destination site, define service URIs (for example, Assertion Consumer Service URI), add a certificate to sign POST profile responses, and configure SSL for the Assertion Consumer Service.

1. In the administration console, select Environment, and then select Servers in the Domain Structure window.
2. Select AdminServer, and then in the Settings for AdminServer, click Federation Services, and then the SAML 1.1 Destination Site tab, as shown in Figure 10.
   

Figure 11. SAML destination site settings

3. Set the destination site values, as listed in Table 6.
   

Parameter	Value
Destination Site Enabled	Select the checkbox(true)
Assertion Consumer URIs	/samlacs/acs
ACS Requires SSL	Select the checkbox(true)
SSL Client Identity Alias	DemoIdentity
SSL Client Identity Pass Phrase	DemoIdentityPassPhrase
POST Recipient Check Enabled	Select the checkbox(true)
POST one Use Check Enabled	Select the checkbox(true)
Used Assertion Cache Properties	APID=ap_00001

Table 6. Destination Site Values

Test Single Sign-On

To test single sign-on, open a browser and point to the URL http://localhost:7001/appA/. The FORM-based authentication configured for appA will display the login.jsp page, as shown in Figure 11. Enter ssouser and demosaml as the values (created in step 2).

Figure 12. Browser showing appA login
This will authenticate the user using the default authenticator configured for domainA.
The auth.jsp page will now be displayed. This page shows a link to appB (http://localhost:7003/appB/admin/services.jsp), as shown in Figure 12. Clicking this link will trigger a call to the ITS servlet and cause the assertion to be generated and the control to be transferred to the destination site.

Figure 13. Browser showing appA successful login with destination site (appB on domainB) link
Once the assertion is validated on the destination site, the ssouser is allowed to access the services.jsp page, as shown in Figure 13.

Figure 14. Browser showing appB successful login with SSO
What if ssouser visits the destination site first? In Step 9, when the asserting party was configured, the Source Site Redirect URI was set to URI /appB/admin/services.jsp. This is the URI from which the unauthenticated user will be redirected to the ITS URL, https://localhost:7001/samlits_ba/its, of the source site. This is done to support the destination site first scenario, whereby a user tries to access a destination site URL prior to being authenticated and is redirected to the source site to be authenticated and then obtain a SAML assertion. The ITS servlet at the source site will challenge the user to supply a username and password. Upon successful authentication, the redirection to the destination site is issued, and the /appB/admin/services.jsp page is displayed.

Debugging Notes

You can enable SAML security debugging to see how the source and destination site interact using the SAML SSO process. To enable SAML security debugging:

1. In the administration console, select Environment, and then select Servers, in the Domain Structure window.
2. Select AdminServer and then the Debug tab.
3. In the Change Center window, select Lock and Edit; this will allow you to edit the debug settings.
4. In the Debug Scope and Attributes, click to open the weblogic > security > saml node. Select the checkbox to enable SAML debugging, as shown in the Figure 14.
5. In the Change Center window, click Activate Changes.
   

Figure 15. Showing WebLogic console enabling SAML debug
You can then view the AdminServer log file on domainA (source) and domainB (destination) to debug the SAML-related issues (Figure 15).

Figure 16. AdminServer log showing SAML interactions

Download

• Sample code for this tutorial
• Sample code modified
  

Summary

The tutorial shows how SAML source and destination site domains can be configured to allow Web applications on these domains to operate in a federation of trust based on successful single sign-on to the SAML source site Web application. This is a powerful paradigm, completely configured using the administration console, providing immediate benefit to users of your many applications.

Part 2

SAML Configuration Using the WebLogic Administrative Console

Before extending the SAML configuration, in the first few steps you'll create and set up the third Weblogic Server domain containing a single AdminServer that will host another copy of the sample application appB.

Step 1: Create a second SAML destination site domain and application server

The sample applications in this tutorial are hosted on two domains on the local host, so the first step is to create the domains and servers running on given ports, as listed below in Table 1.

	Host	Application Server	Application Name	Port	SSL Port
SAML Source Site Domain: domainA	localhost	AdminServer	appA	7001	7002
SAML Destination Site Domain: domainB	localhost	AdminServer	appB	7003	7004
SAML Destination Site Domain: domainC	localhost	AdminServer	appB	7005	7006

Table 7. Sample application domains and application servers
Create domainC, as shown in Table 1, using the Domain Configuration Wizard. Update the appropriate listen ports during Domain creation or using the WebLogic Server Administration Console.

Step 2: Create users

Create a user ssouser in domainC under the myrealm realm.

	Realm	User/Password
SAML Source Site Domain: domainA	myrealm	ssouser/welcome1
SAML Destination Site Domain: domainB	myrealm	ssouser/welcome1
SAML Destination Site Domain: domainB	myrealm	ssouser/welcome1

Table 8. The user participating in single sign-on

Step 3: Configure relying party properties

In this step I'll create and configure a new relying party on the Asserter Provider (domainA).
The relying party determines whether it trusts the assertions provided to it by the asserting party. SAML defines a number of mechanisms that enable the relying party to trust the assertions provided to it.

1. Connect to WebLogic Console for domainA
2. Go to Security Realms, select myrealm
3. Click on the Providers tab, then on the Credential Mappers tab
4. From the list select SAMLCredentialMapper (that you previously created)
5. On the Management tab, click Relying Parties.
6. In the Relying Parties table, click New.
7. In the Profile pull-down menu, select Browser/POST. In the Description field, enter the name demoSAML to identify the relying party, as shown in Figure 5.
   

Figure 17. Relying party configuration

8. Set the relying party values, as listed in Table 3.
   

Parameter	Value
Enabled	Select the checkbox(true)
Target URL	http://localhost:7005/appB/admin/services.jsp
Assertion Consumer URL	https://localhost:7006/samlacs/acs
Assertion Consumer Parameters	APID=ap_00001
Signature Required	Select the checkbox(true)
Include Keyinfo	Select the checkbox(true)

Table 9. Relying Party (rp_00002) Values
Although a relying party may trust the assertions provided to it for user ssouser, the local access policy on the destination site application appB on domainB defines whether the subject (ssouser) may access local resources.

Step 4: Configure domainC, acting as a SAML destination site

I'm ready to configure domainC as a SAML destination site as we did already for domainB. The first thing I need to do here is to create a SAML Identity Assertion Provider V2 instance and import the certificate generated in step 4 into the provider's certificate registry.
Import the certificate:

1. Copy the key file ( testalias.der) that you generated previously to the $DOMAIN_HOME/security directory for domainC.
2. Log in to the WebLogic Server Administration Console on domainC.
3. Select a security realm, myrealm.
4. Select the Providers tab, and then select the Authentication tab.
5. If a SAMLIdentityAsserter doesn't exist, then create a new SAMLIdentityAsserter, as shown in Figure 7. An identity asserter allows WebLogic Server to establish trust by validating a user.
   

Figure 18. Create a new Identity asserter

6. Select SAMLIdentityAsserter, click the Management tab, and then click Certificates.
7. In the Certificates dialog, click New, as shown in Figure 8.
   

Figure 19. Create a new identity asserter certificate

8. In the Alias field, enter a name for the certificate. Good practice is to use the same name you used when you created the certificate.
9. Enter the path to the certificate file in the Certificate File Name field.
10. Click Finish. If there are no problems, the message "The certificate has been successfully registered." is displayed.
    

Step 4: Configure asserting party properties

In this step I'll create and configure an asserting party. When you configure WebLogic Server to act as a consumer of SAML security assertions, you need to register the parties whose SAML assertions will be accepted. For a SAML asserting party, you can specify the SAML profile used, details about the asserting party, and the attributes expected in assertions received from the asserting party.
The asserting party asserts that a user has been authenticated and given associated attributes. For example, there is a user ssouser, and he/she is authenticated to this domain using a password mechanism. Asserting parties are also known as SAML authorities.

1. On the Management tab, click Asserting Parties.
2. In the Asserting Parties table, click New.
3. In the Profile pull-down menu, select Browser/POST. In the Description field, enter the name demoSAML to identify the asserting party, as shown in Figure 9.
   

Figure 20. Create a new asserting party

4. Set the asserting party values, as listed in Table 5.
   

Parameter	Value
Enabled	Select the checkbox(true)
Target URL	http://localhost:7001/appA
POST Signing Certificate alias	testalias
Source Site Redirect URIs	/appB/admin/services.jsp
Source Site ITS URL	https://localhost:7002/samlits_ba/its
Source Site ITS Parameters	RPID=rp_00002
Issuer URI	http://www.bea.com/demoSAML
Signature Required	Select the checkbox(true)
Asserting Signing Certificate Alias	testalias

Table 11. Asserting Party (ap_00001) Values

 
Figure 21. Asserting Party (ap_00001) Values

Step 5: Configure the SAML 1.1 destination site

In this step I'll configure various destination site settings for the server instance running application appB. These settings enable a server instance running on domainC to serve as a SAML destination site, define service URIs (for example, Assertion Consumer Service URI), add a certificate to sign POST profile responses, and configure SSL for the Assertion Consumer Service.

1. In the administration console, select Environment, and then select Servers in the Domain Structure window.
2. Select AdminServer, and then in the Settings for AdminServer, click Federation Services, and then the SAML 1.1 Destination Site tab, as shown in Figure 10.
   

Figure 22. SAML destination site settings

3. Set the destination site values, as listed in Table 6.
   

Parameter	Value
Destination Site Enabled	Select the checkbox(true)
Assertion Consumer URIs	/samlacs/acs
ACS Requires SSL	Select the checkbox(true)
SSL Client Identity Alias	DemoIdentity
SSL Client Identity Pass Phrase	DemoIdentityPassPhrase
POST Recipient Check Enabled	Select the checkbox(true)
POST one Use Check Enabled	Select the checkbox(true)
Used Assertion Cache Properties	APID=ap_00001

Table 12. Destination Site Values

Test Single Sign-On on domainC

To test single sign-on, first change appA to add a link to domainC.
Open a browser and point to the URL http://localhost:7001/appA/. As in the previous test enter ssouser/welcome1.
The following page appears:

Figure 23. Welcome page after login on domainA

You can click on the second link and you will be redirected to appB in domainC without being asked for authentication any more:

Figure 24. Application appB on domainC

That's all folks!