Things to remember for integrating BPEL worklist with OSSO in realtime

I have written a post earlier on the integration aspects of OSSO with BPEL worklist. However, I did not talk about real time aspects of this integration. Let's assume there are 2 nodes of OSSO servers with software load balancer (with virtual hostname say osso.oracle.com) configured in the production system. In the same lines, let's assume there are 4 nodes of BPEL worklist with hardware loadbalancer (with virtual hostname say soa.oracle.com).


The first step of this integration is to register the BPEL worklist as a partner application to OSSO server using ssoreg.sh script. The question is on how many OSSO nodes will we run this script? The answer is single node. Since the OSSO servers are clustered, registering in one node will automatically get reflected in another node. However, a small additional step needs to be performed i.e., osso.conf file generated in first node has to be copied to the 2nd to the same location say $ORACLE_HOME/Apache/Apache/conf/osso/worklist. Remember that while running the ssoreg.sh script, the hostname specified for the middle tier i.e., SOA worklist is the Virutal hostname instead of individual server hostname.


To verify, login to OSSO console and check whether the application is registered or not.


Next step is the configuration part at the BPEL end using the metalink note 753087.1.  
The question is whether to perform this configuration part at single node of BPEL server or all the nodes? The answer is all the nodes.

Please reach out to me in case of any doubts.

Integration of E-Business Suite 12.x with Oracle Single Sign-on Server 10.1.4.3 in real time

Not many people talk about real time aspects of any integrations and the configurations involved. However, I would like to bring a small point which is vital for integrating E-Business Suite 12.x with Oracle Single Sign-On Server 10.1.4.3.
Lets assume E-Business suite is running on 2 nodes and OSSO server on 2 other nodes (nodes imply different machines or different instances in same machine) in production mode. In real time mode, you will be accessing the OSSO server console/application using a virtual hostname (instead of individual hostname) and same is the case for E-Business suite. For integrating OSSO with E-Business Suite, we will run a perl script txkrun.pl which registers E-Business Suite as partner application in OSSO server. The question is whether to run the script in both nodes of E-Business suite or just single node. The answer is single node as the script will pick up values from profile options that are in the database (A person called Atul helped me in this concept).

The runtime inputs to be provided for the perl script txkrun.perl is shown below:
$FND_TOP/bin/txkrun.pl -script=SetSSOReg

Enter the host name where Oracle iAS Infrastructure database is installed ? Virtual Hostname of OSSO Server (not to get confused as it specifies Infrastructure database hostname)
Enter the LDAP Port on Oracle Internet Directory server ? 389 (default port is 389, if you have customized the ports, then specify it)
Enter SSL LDAP Port on Oracle Internet Directory server ? 636 (default port is SSL, if you have customized the ports, then specify it)
Enter the Oracle Internet Directory Administrator (orcladmin) Bind password ? (OID administrator password)
Enter the instance password that you would like to register this application instance with ? (mostly this password is same as OID admin password)
Enter Oracle E-Business apps database user password ? (EBS apps user password)

Oracle Access Manager integration with BPEL worklist

This is a new task that I accomplished recently with lots of ups and downs. The objective is to achieve Single Sign-on or authentication of BPEL worklist using Oracle Access Manager.

The various component versions are:
1. OAM 10.1.4.3
2. BPEL Process Manager 10.1.3.4
3. Oracle Single Sign-on 10.1.4.3

There are 2 ways to integrate OAM with BPEL.
1. Direct integration using Access SDK
2. Using Oracle Single Sign-on

I followed the second approach as our environment is AIX and Access SDK is not availble for AIX servers. However, I would suggest first approach as OSSO is not a strategic product for single sign-on from 11g onwards and no further development will be carried upon OSSO.

Integration Process:
I am writing the procedue for integration using second approach.
The integration is divided into 2 bits. OSSO integration with BPEL and OSSO integration with OAM.
I have posted here in detail about the BPEL-OSSO integration. OSSO integration with OAM is avaiable in oracle by example here.

The hiccups and troubleshooting tips I used in this integration process are written here 1, 2.

Oracle SSO provisioning for APEX

This section deals with provisioning Oracle SSO for APEX application.
1. Register APEX as partner application in Oracle Application server.
Note some of the details as shown below.
ID: 80F63272
Token: 51J0903680F63272
Encryption Key: EBBD933BC541FAFF
Login URL: http://directory_server_hostname:7777/pls/orasso/orasso.wwsso_app_admin.ls_login
Single Sign-Off URL: http://directory_server_hostname:7777/pls/orasso/orasso.wwsso_app_admin.ls_logout
Name : APEX
Home URL : http://apex_hostname:8080/apex
Success URL : http://apex_hostname:8080/apex/wwv_flow_custom_auth_sso.process_success
Logout URL :http://apex_hostname:8080/apex
This Application Name APEX will be used in 5th step while associating SSO application name in the Authentication scheme.
2. Next step is to install SDK package and configuration.
Extract the sdk902.zip file present in middle tier to the local machine.
Login as FLOWS_xxxx user and execute @loadsdk.sql.
Then logout and login again, and execute @regapp.sql by inputting some parameters of Partner application.
Enter value for listener_token: HTML_DB:sbpdb.idc.oracle.com:8080
Enter value for site_id: 80F63272
Enter value for site_token: 51J0903680F63272
Enter value for login_url: http://directory_server_hostname:7777/pls/orasso/orasso.wwsso_app_admin.ls_login
Enter value for encryption_key: EBBD933BC541FAFF
Enter value for ip_check: N
It is important that listener_token should be in the format HTML_DB:hostname_where_apex_installed:port_no_apex_listens.
When the registration is successful, then the result will be as shown below:
Registration successful.
Listener token: HTML_DB:sbpdb.idc.oracle.com:8080
Site id : 80F63272
Site token : 51J0903680F63272
Encryption key: EBBD933BC541FAFF
Login URL : http://directory_server_hostname:7777/pls/orasso/orasso.wwsso_app_admin.ls_login
Logout URL : http://directory_server_hostname:7777/pls/orasso/orasso.wwsso_app_admin.ls_logout
IP check : N
3. Third step is to execute custom_auth_sso_902.sql and custom_auth_sso_902.plb as FLOWS_xxxx user.
4. Grant execute permissions as shown below:
grant execute on wwv_flow_custom_auth_sso to APEX_PUBLIC_USER;
5. Login to APEX console, and create Authentication scheme with name CUSTOM SSO and map the SSO Partner application as APEX (as in the first step).

Congrats, you have finished SSO configurations for APEX.
Now login to apex application (for eg, http://apex_hostname:8080/apex/f?p=104:2) and check SSO login page will be displayed.

Integrating Access Manager with Oracle SSO

The following steps discuss the integration of Oracle Access Manager with Oracle Application Server.
(This is not applicable to a standalone oc4j.).

1. User accesses OAM protected application deployed on Oracle Application Server and webgate intercepts that request.
2. Webgate checks with the Access Server if the resource is protected.
3. When the resource is protected, Webgate prompts for the username and password (depends on authentication scheme selected for the resource in Policy Manager).
4. The credentials are validated by the Access Server against the LDAP server.
5. When authentication is successful, OAM cookie ObSSOCookie is set in the browser.
6. Upon successful authentication, Access System determines if the user is authorized to access the resource.
6. Upon successful authorization, Access system executes actions and sets HTTP Header variables that maps to the Oracle AS userid.
7. mod_osso (part of OSSO) intercepts the request and redirects to the Oracle SSO for authentication.
8. SSOOblixAuth.class is registered with OSSO and retrieives userid set in the HeaderVar by the OAM as part of Authz actions execution.
9. OSSO Cookie is set and user is redirected back to the requested URL.
10. Hence for any sub-sequent requests it uses ObSSOCookie as reference.

Note: The Header Variable name should be set as HTTP_REMOTE_USER.