You are not authorized to access this site.

On accessing Extranet URL from Internet, we got this message:

Access Denied

You are not authorized to access this site.

The application you are attempting to access requires additional authorization. If you feel you have received this message in error, please contact your local business Help Desk.

This error is coming because we have SSO enabled our Extranet also. If the user exists in the SSO database and doesn't exist in the FND_USER table of Oracle E-Business Suite, this error would appear.

After creating the users locally in E-Business Suite, this error should disappear.

Extranet tier prompts for username/password twice after clone

Anand called me today and described a problem being faced:

After clone of extranet tier, when username and password are keyed in the first time, the username and password fields become blank and the user is prompted again for entering them. After the user enters the username and password the second time, the Self Service Page is shown. I asked him to tail the Apache log and see what corresponding entries were getting formed when we were doing this. This is how they looked:

192.168.15.1 - - [27/Apr/2008:10:44:14 -0400] "GET /oa_servlets/oracle.apps.fnd.sso.AppsLogin?requestUrl=http%3A%2F%2Fextdev.justanexample.com%3A8032%2FOA_HTML%2FOA.jsp%3Fpage%3D%2Foracle%2Fapps%2Ffnd%2Fframework%2Fnavigate%2Fwebui%2FHomePG%26homePage%3DY%26OAPB%3DFWK_HOMEPAGE_BRAND%26transactionid%3D1622860638%26oapc%3D2%26oas%3D5PZsF5fcdnhFfJ1R0rPWPA..&cancelUrl=http%3A%2F%2Fextdev.justanexample.com%3A8032%2Foa_servlets%2Foracle.apps.fnd.sso.AppsLogin&errText=You+have+insufficient+privileges+for+the+current+operation. HTTP/1.1" 302 705 0
192.168.15.1 - - [27/Apr/2008:10:44:15 -0400] "GET /OA_HTML/AppsLocalLogin.jsp?requestUrl=http%3A%2F%2Fextdev.justanexample.com%3A8032%2FOA_HTML%2FOA.jsp%3Fpage%3D%2Foracle%2Fapps%2Ffnd%2Fframework%2Fnavigate%2Fwebui%2FHomePG%26homePage%3DY%26OAPB%3DFWK_HOMEPAGE_BRAND%26transactionid%3D1622860638%26oapc%3D2%26oas%3D5PZsF5fcdnhFfJ1R0rPWPA..&cancelUrl=http%3A%2F%2Fextdev.justanexample.com%3A8032%2Foa_servlets%2Foracle.apps.fnd.sso.AppsLogin&langCode=US&errText=You+have+insufficient+privileges+for+the+current+operation.&s1=IinGd45sClw4CKn4cMrklw.. HTTP/1.1" 200 7261 1
192.168.15.1 - - [27/Apr/2008:10:44:52 -0400] "POST /OA_HTML/fndvald.jsp HTTP/1.1" 302 412 0
192.168.15.1 - - [27/Apr/2008:10:44:52 -0400] "GET /OA_HTML/OA.jsp?page=/oracle/apps/fnd/framework/navigate/webui/HomePG&homePage=Y&OAPB=FWK_HOMEPAGE_BRAND&transactionid=1622860638&oapc=2&oas=5PZsF5fcdnhFfJ1R0rPWPA.. HTTP/1.1" 200 11180 0
192.168.15.1 - - [27/Apr/2008:10:45:00 -0400] "GET /OA_HTML/OALogout.jsp?menu=Y HTTP/1.1" 302 270 0
192.168.15.1 - - [27/Apr/2008:10:45:00 -0400] "GET /oa_servlets/oracle.apps.fnd.sso.AppsLogout HTTP/1.1" 302 320 0
192.168.15.1 - - [27/Apr/2008:10:45:00 -0400] "GET /OA_HTML/AppsLocalLogout.jsp?returnUrl=http://extdev.justanexample.com:8000/oa_servlets/oracle.apps.fnd.sso.AppsLogin?langCode=US HTTP/1.1" 302 281 0
192.168.15.1 - - [27/Apr/2008:10:45:01 -0400] "GET /oa_servlets/oracle.apps.fnd.sso.AppsLogin?langCode=US HTTP/1.1" 302 435 0
192.168.15.1 - - [27/Apr/2008:10:45:01 -0400] "GET /OA_HTML/AppsLocalLogin.jsp?requestUrl=APPSHOMEPAGE&cancelUrl=http%3A%2F%2Fextdev.justanexample.com%3A8032%2Foa_servlets%2Foracle.apps.fnd.sso.AppsLogin&langCode=US&s2=34554EE5947F1746754F671CF150A536B02E53E4049CFB609BE4970DB131D03B HTTP/1.1" 200 8510 0

When the user was prompted for the password again, in the Apache logs it was showing this:

AppsLogin&errText=You+have+insufficient+privileges+for+the+current+operation. HTTP/1.1" 302 705 0

Seeing this error, Anand checked for the value of the profile option PON: External URL and PON: Default External User Responsibility:

SQL> select fnd_profile.value('PON_EXT_LOGIN_URL') from dual;

FND_PROFILE.VALUE('PON_EXT_LOGIN_URL')
--------------------------------------------------------------------------------
http://ext.justanexample.com:8000/OA_HTML/AppsLocalLogin.jsp

SQL> select fnd_profile.value('PON_DEFAULT_EXT_USER_RESP') from dual;

FND_PROFILE.VALUE('PON_DEFAULT_EXT_USER_RESP')
--------------------------------------------------------------------------------
PON_SOURCING_SUPPLIER

The profile option PON: External URL was still having the value of Production URL ext.justanexample.com instead of extdev.justanexample.com. He change this value to extdev.justanexample.com so that:


SQL> select fnd_profile.value('PON_EXT_LOGIN_URL') from dual;

FND_PROFILE.VALUE('PON_EXT_LOGIN_URL')
--------------------------------------------------------------------------------
http://extdev.justanexample.com:8000/OA_HTML/AppsLocalLogin.jsp

Apache was bounced.

The issue was resolved.

The incorrect extranet site mystery

Many enterprise applications encounter a major obstacle when they deploy multiple servers for scalability: the challenge of maintaining session persistence. A transaction typically consists of several TCP connections between the client browser and the servers. Once multiple servers are deployed, connections for a given transaction could go to any of the servers. While many load balancers solve the problem of balancing load across multiple servers, not every one supports the different persistence needs. Because persistence by definition requires the load balancer to ignore the load conditions on the servers and select a server based on persistence rules, the trick for the load balancing products is to ensure that the required level of persistence is met without breaking load balancing as much as possible.

For the last few days, Akhilesh contacted me regularly for an issue in one extranet environment. In this environment, we have iSupplier running in extranet with the URL pon.justanexample.com which connects to the E-Business Suite. This has two app tiers on extranet which are running Oracle Apps configured for DMZ. There is another Java application which is called supplier.justanexample.com. This is also load balanced on two servers. The BigIP box is same for both but their webs (pool) are different. The following steps can be taken to reproduce the problem:

From your home machine which is connected to internet, if you access pon.justanexample.com the E-Business Suite login page appears. After this if you access supplier.justanexample.com, then also you are directed to pon.justanexample.com

Go to another machine with a different public IP and try to access supplier.justanexample.com. The site opens with its login page. Now try accessing pon.justanexample.com, you'll get directed to supplier.justanexample.com

This was a consistent behaviour which could be reproduced easily. We had network guys, DNS guys scratching their heads, trying to figure this one out. Finally we reached out to a network expert who had previously solved such tricky problems. He did a trace of the network calls and found that the global IP was resolving correctly and requests were coming in on the correct IP address, but it was opening the incorrect application. He said maybe it is being done by the Application itself. Application teams denied this. So he checked from the other side, that is from the load balancer inside the DMZ and found that it was indeed going to the incorrect server. It was very strange. He checked the persistence setting in the load balancer and saw that it was set to source IP based persistence. Since all other environments had cookie based persistence, he changed the persistence to cookie based on a hunch. Voila, the problem was solved. After this, if you typed http://pon.justanexample.com, it would take you to E-Business Suite and if you typed http://supplier.justanexample.com, it would take you to that application's username/password page.

He said that it is possible that source IP based persistence was not taking the URL into account and was routing traffic solely on the IP. The BigIp load balancer would check the source IP from which the your first request came for a particular application, and would always send any subsequent request coming from your IP to the same application disregarding the URL you were trying to actually reach. This could be a bug in the load balancer. We are not really sure about this. Changing the persistence method to cookie based, fixed the issue.

There are two ways to do cookie-based persistence: cookie based switching and cookie hashing. In the first approach, the real server sets a cookie value that indicates to the load-balancing switch which real server a connection must be directed to. In the second approach, the load balancer can hash on the entire cookie string to select a real server. Once the load balancer selects a real server for a given hashing value, it will stick with that real server for all such traffic.

I am not sure which method is used by BigIP to do the cookie based persistence, but it sure avoided the problem we had with source ip based persistence.

Redirect to third party site from extranet pages

In one of the iSupplier implementations, we have given a link to a third party site. Whenever this link http://www.anotherthirdpartysite.com is clicked, we got the following error:

Gone

Access to the requested URI has been blocked by the URL Firewall.

If you believe that you have reached this page while performing valid operations within the application, please send mail to applmgr@justanexample.com explaining what you were doing when you got this error.

This is expected because the url firewall file doesn't have this entry. To allow this we made the following change indicated in bold in the $IAS_ORACLE_HOME/Apache/Apache/conf/url_fw.conf file present on the extranet web tiers:

On line 617 of url_fw.conf:

#==========================================================
#Include all Custom files
#==========================================================
# Third party link
RewriteRule https://www.thirdpartysite.com - [L]

# If not allowed by list above - go away! [G] is '410 Gone'
RewriteRule .* - [G]
# END Positive list of URLs

After making this change, the Gone error stopped coming.

Running vnc over ssh in extranet

In our new extranet setup, we have two servers in the DMZ which can be accessed through a jumpbox server from the intranet. The only protocol allowed between the jumpbox server and the extranet servers is ssh. Till the global URL being assigned to the extranet application tier is live, there was no way to test if everything was setup correctly on the extranet tier, as we could not access the server through http port from intranet. If I ran vnc on the extranet server, I couldn't access access it from jumpbox because VNC port is not open in firewall. I did a little research and came across this URL: http://www.cskk.ezoshosting.com/cs/answers/vnc-thru-firewall-via-ssh.txt

You can tunnel vnc over ssh by following the steps given in the above URL which boils down to this.

1. Start vncserver on extranet tier by typing: vncserver :5
2. On the jumpbox server type:

ssh -v -l 5905:extranet_hostname:5905 extranet_hostname

3. Start vncviewer on jumpbox server and access localhost:5. This will redirect you to the extranet server over ssh and connect you to vnc running on extranet server on port 5
4. Create a file test.htm in $COMMON_TOP/portal/$CONTEXT_NAME directory with the text "You have reached extranet server