We would create portal pages, and put iframe calls to web-apps in the 10.1.3 iAS. Since both were SSO-enabled authentication and authorization was no problem. I believe I have covered how to SSO/JAZN enable 10.1.3 a year or two ago on a different blog entry for this same blog.
However, when we added SSL (terminating at the Web Cache) this iframe arrangement did not work out so well. This is for several reasons: one the military establishment with which we were affiliated had the rule that only port 443 shall be used/seen by external users. With the iframe arrangement, there were additional HTTP ports (i.e., the 10.1.3 HTTP Server port) that needed to be open on everybody's firewalls. This was unacceptable to our end-users.
The second nastiness we encountered was that while our computer hostname was one thing (according to dns), there was another alias that pointed to the same IP which was the external users moniker of choice for our mid-tier computer. So the 10.1.3 mid-tier and SSO registration wanted to use the host name, while all external references were to the alias. So, when it came time to register the SSL certificate, we had to pick one...we thought. So we picked the external alias. Either choice would have created nasty certificate errors when the other name was attempted to be used, because a certificate is often for a particular name...although we learned that (for a fee, of course) our certificate company would allow wild-cards.
So our end users hated the certificate errors, so we called Oracle Support. We worked with them, and what we worked out...really...is the topic of this blog entry.
In short we implemented the section in the following Oracle doc Oracle Application Server Administrator's Guide 10g Release 3 (10.1.3.1.0) B28940
The above doc contains some information in section 6.4 entitled "Configuring Oracle Application Server 10.1.2 with Oracle Application Server 10.1.3"
Note that for the opmn.xml entry we saw that the port element showed a remote port, which we used to create an entry such as the following:
<notification-server interface="ipv4">... where 6200 was the remote port of the portal mid-tier and 6202 was that of the 10.1.3 mid-tier...as you can see in the "port" element above. Note that all we added was the <toplogy> element and its nodes child as per the doc I mentioned.
<port local="6100" remote="6202" request="6005"/>
<ssl enabled="true" wallet-file="$ORACLE_HOME/opmn/conf/ssl.wlt/default"/>
<topology>
</notification-server>
Also per the aforementioned doc, we altered the mod_oc4j.conf file. We added additional Oc4jMount entries to tell the Web Cache (I think? or maybe the HTTP Server) of the Portal instance to communicate with 10.1.3 instance whenever it saw a context-root (i.e., the part of the JSF web-app url that is right after the domain but before the "faces" bit. It designates with J2EE/Java EE app you are referring to on the server you are addressing with your URL. Some of these entries looked like this:
Oc4jMount /ContextRoot1 ajp13://ourmachinename.oursite.org:8888
Oc4jMount /ContextRoot1/* ajp13://ourmachinename.oursite.org:8888
Oc4jMount /ContextRoot2 ajp13://ourmachinename.oursite.org:8888
Oc4jMount /ContextRoot2/* ajp13://ourmachinename.oursite.org:8888
Note that we obtained the 8888 port by doing an "opmnctl status -l" on the 10.1.3 site, and looking for the primary ajp port for the OC4J to which our apps were deployed.
httpd.conf on the Portal/Web Cache instance we had been using proxy and reverse proxy entries for these two apps (as designated by the ContextRoot* designations above. We had to comment those out.
I appologize that I cannot give more details about SSL enabling the topology, because I was not really involved more with that process. It was involved though, and took the people that knew what they were doing 3 hours to hand-enable a pre-existing production topology as I described. That might give you an idea of what was involved in this SSL enabling process for this technology stack.
No comments:
Post a Comment