Who said I was?

I already noted the nasty side effects, but instead of altering the once published blog, I decided to add this one. After all, the portal single-sign on (SSO) was just an example, and I want the originally registered applications still to be registered, including OIDDAS, orasso and both the infrastructure as well as the middle tier Oracle HTTP Servers (or OHS).

Inventory taking.
What is it I will have to move? Let's check with the Single Sign-On:orasso entry on the Infrastructure management console. Opening sub pages will get me to the Orasso SSO home page, in this exercise located at http://asinfra101202.mymachine.local:7777/pls/orasso/orasso.home.
This page provides a list of all current "partner applications" that rely on orasso to take care of the login procedure.
After logging in (with orcladmin) by clicking the modest link in the right upper hand corner, you will be shown another link: "Maintain the SSO server". Particulary interesting is the link about maintenance on partner applications!

History
Was did I already do? Actually, not a lot - the changing of the DAD is what was done, to allow the midtier to access /pls/orasso, but that was about it. Reread that thread first.
In the mean time, I do have access to the orasso home page, using the midtier link as well; however, the login link provides me with an error, and all page links refer to the infrastructure.

Moving the SSO server
Less of a move than fact - only the references will be changed to the middle tier instance, not the actual server.
First of all, I want to get rid of the references to the infrastucture on the orasso home page. I can do that by changing the home URL, success URL and logout URL in the Maintain Partner Applications screen of orasso. Unfortunately, I cannot change the login URL, nor the Single Sign-Off URL on this page, and those still point to the infrastructure.
So, the second step is to reregister orasso, by running this on the infrastructure: $ORACLE_HOME/sso/bin/ssoreg.sh -oracle_home_path $ORACLE_HOME -site_name "The SSO Server (OraSSO)" -config_mod_osso TRUE -mod_osso_url http://asmt101202.mymachine.local:7777/pls/orasso/orasso.home


After that, stop and start all opmn registered processes - both sides!

So, you're the security expert on Oracle iAS... or How To Relocate the SSO server

Well, uhm, actually I'm not, but how often do you find yourself in the position that the consulting firm you work for positions you as one?
Picture the following: a perfectly reasonable setup of Oracle's internet Application Server, with Oracle's LDAP implementation (Oracle Internet Directory, or OID) and Portal, Single Sign On (SSO), the Oracle Certificate Authority (OCA), Forms, Discoverer, the Oracle HTTP Server (OHS) and WebCache.
Basically, it looks like this:


What runs where?
Here's what the documentation has to say about the middle or Application Server tier:
The middle-tier is the part of an Oracle Application Server architecture that contains several components responsible for accepting requests from clients, validating the requests, and providing content, while using intelligent data caching for faster and reliable performance. For OracleAS Portal, the middle-tier handles all Web requests by forwarding them to the appropriate provider. This is also where Portal pages are assembled, and where the caching of Portal content is managed. The middle-tier also provides other functions for other Oracle Application Server components.

Components on the Middle tier are:

• The Oracle HTTP Server (powered by Apache), or OHS
  OHS handles all requests for Portal, either via mod_plsql, or via the Parallel Page Engine (PPE)
  
• Webcache
• the Application Server containers for J2EE (OC4J)
  

Same for the Infrastructure tier:
By default, the infrastructure tier handles all authentication requests and hosts the Oracle Application Server Metadata Repository, which contains schemas and business logic used by application server components (including OracleAS Portal) and other pieces of the infrastructure.
Mind the "By default"...

Components, running in the infrastructure are:

• Application Server Control
• Oracle Internet Directory (OID)
• Oracle Application Server Single Sign on (SSO)
• Oracle Application Server Metadata Repository
  some middle tier products, like Portal, store their metadata in this repository.
  

Simple enough, isn't it? Sure, until the network guys came in, as they demanded -and rightly so- this:

So - what's the problem? The middle tier is moved to the DMZ, and firewalls are in place. What can be the problem? Well, Portal doesn't work anymore, as nobody can login...
How comes?

A closer look.
First of all, Portal "runs" on the middle tier; the OHS on the middle tier uses mod_plsql and/or the Parallel Page Engine. Do'nt be mislead by Portal pages themselves, as there is a rewrite engine. A portal page reference (before the rewrite!) may look like:

http://asmt101202.mymachine.local:7777/pls/portal

So, there must be a DAD defined on the middle tier, because of the /pls/ :

[oracle@asmt101202 bin]$ cat $ORACLE_HOME/Apache/modplsql/conf/dads.conf
<Location /pls/portal>
SetHandler pls_handler
Order allow,deny
Allow from All
AllowOverride None
PlsqlDatabaseUsername portal
PlsqlDatabasePassword @BW01fa60ocxhrL9E2N88jEyS0bXgwimw==
PlsqlDatabaseConnectString cn=asdb,cn=oraclecontext NetServiceNameFormat
PlsqlNLSLanguage AMERICAN_AMERICA.AL32UTF8
PlsqlAuthenticationMode SingleSignOn
PlsqlDocumentTablename portal.wwdoc_document
PlsqlDocumentPath docs
PlsqlDocumentProcedure portal.wwdoc_process.process_download
PlsqlDefaultPage portal.home
PlsqlPathAlias url
PlsqlPathAliasProcedure portal.wwpth_api_alias.process_download
</Location>

So, there you have it - on the middle tier, there's a Database Access Descriptor, pointing to the (standard infrastrutcure setup named) database "asdb". Whenever someone logs on to Portal, SSO is activated, the login link on Portal looks like

http://asmt101202.mymachine.local:7777/pls/portal/PORTAL.wwsec_app_priv.login?p_requested_url=http%3A%2F%2Fasmt101202.mymachine.lo....

Following that link, you will get redirected to

http://asinfra101202.mymachine.local:7777/sso/jsp/login.jsp?site2pstoretoken=v1.2~458......

and that is where the trouble starts: asinfra101202 is not in the DMZ, it's host name cannot be resolved by the DNS-server, in short: you'll get a "page not found" response.

What SSO does.
The Single Sign On server uses mod_osso, which is configured on the infrastructure server. The flow of events is as follows:

1. The user requests a page; the Apache configuration is such that authentication is needed.
2. The mod_osso module kicks in, and looks for a cookie with an encrypted token. If found, the token is passed back to the application.
   If not found, the request gets redirected to the SSO server.
3. The SSO server requests it's own cookie - if not found, it produces a login page.
4. The user credentials are checked and validated against OID
5. The SSO server sets it's own cookie, and redirects the user identity in encrypted form back to mod_osso.
   
6. mod_osso sets it's own cookie, with a token, which holds the user identity in encrypted form (see step 2)

Also, one needs to realize that Oracle Portal is considered a "partner application".
SSO used to be incorporated in Portal, hence the -incorrect- saying 'portal is a partner app of itself'.
Not since iAS 9.0.2, where SSO and Portal were disconnected (and mod_osso was born).




What to do?
Now that the problem is clear, so is the solution. Basically, we need to reconfigure mod_osso, so that:

1. it can be accessed from the middle tier
2. redirection takes place to the middle tier

The SSO server Home Page is located at [host][:port]/pls/orasso, where the host is your infrastructure server, e.g.

http://asinfra101202.mymachine.local:7777/pls/orasso/orasso.home

We will have to change that for starters, so that is will become

http://asmt101202.mymachine.local:7777/pls/orasso/orasso.home

As this is a /pls/ entry, too, it must be a DAD, just like Portal uses, so let's check the dads.conf file on the infrastructure machine:

[oracle@asinfra101202 ~]$ cat $ORACLE_HOME/Apache/modplsql/conf/dads.conf
#=========================================================== # mod_plsql DAD Configuration File
# ===========================================================
# 1. Please refer to dads.README for a description of this file
# ===========================================================
# Note: This file should typically be included in your plsql.conf file with
# the "include" directive.
# Hint: You can look at some sample DADs in the dads.README file
# ===========================================================
<Location /pls/orasso>
SetHandler pls_handler
Order deny,allow
Allow from All
AllowOverride None
PlsqlDatabaseUsername orasso
PlsqlDatabasePassword @BcyVNZv4W9rd5+bPajizTuISOz9AvJ3lLg==
PlsqlDatabaseConnectString cn=asdb,cn=oraclecontext NetServiceNameFormat
PlsqlNLSLanguage AMERICAN_AMERICA.AL32UTF8
PlsqlAuthenticationMode SingleSignOn
PlsqlSessionCookieName orasso
PlsqlDocumentTablename orasso.wwdoc_document
PlsqlDocumentPath docs
PlsqlDocumentProcedure orasso.wwdoc_process.process_download
PlsqlDefaultPage orasso.home
PlsqlPathAlias url
PlsqlPathAliasProcedure orasso.wwpth_api_alias.process_download
</Location>

Just add that to the existing DADs in the dads.conf file on the middle tier, and bounce the OHS:

[oracle@asmt101202 bin]$ opmnctl restartproc type=ohs
opmnctl: restarting opmn managed processes...

Then, try to access the SSO Server's home page:

http://asmt101202.mymachine.local:7777/pls/orasso/orasso.home

That works...[edit]But you cannot login; you will get: WWC-41439.[/edit]
However, the Portal/SSO login page still redirects you to the infrastructure. You will have to reregister the SSO server. Now, there are two ways of doing that:

1. Call the ssoreg.jar in $ORACLE_HOME/sso/lib
   
2. use the ssoreg script (or batch, when using MS), located in $ORACLE_HOME/sso/bin.

Some posts suggest to use the latter, as it sets some environment variables; so I will. What this registration does is create an encrypted osso.conf file.
[edit]There are some nasty side-effects... See Metalink Note:249408.1 What will happen, is that an empty obfuscated configuration file, osso.conf, is created, to which Portal is added. Portal may work OK after these actions, other vital SSO applications, like OIDDAS, will not.[/edit]

[oracle@asmt101202 bin]$ $ORACLE_HOME/sso/bin/ssoreg.sh -oracle_home_path $ORACLE_HOME -site_name asmt101202.mymachine.local:7777/pls/portal -config_mod_osso TRUE -mod_osso_url http://asmt101202.mymachine.local:7777/pls/portal

I did it on the infrastructure tier as well, seemed logical, but I have no real explanation as to why. I do remeber a note on metalink, mentioning it should be done on both.
Make sure all configs are updated: $ORACLE_HOME/dcm/bin/dcmctl updateconfig -d -v
stop and start all processes, both ends: opmnctl stopall, opmnctl startall
You will stil get an error page; make sure to alter the iasadmin.xml file on the middle tier ($ORACLE_HOME/portal.conf/iasadmin.xml - alter the Host entry on line 2), and run ptlconfig:

oracle@asmt101202 conf]$ ./ptlconfig -dad portal -site -pw welcome2
~/product/as101202/midtier/portal/conf ~/product/as101202/midtier/portal/conf

Portal Dependency Settings Tool

Processing Portal instance '/pls/portal' (cn=asdb,cn=oraclecontext)
Processing complete

Now - following the "login" link on the orasso home page, I get:
You cannot login because there is either invalid or no configuration information stored in the enabler configuration table (WWSEC_ENABLER_CONFIG_INFO$ (WWC-41439))
The WWC-41439 is a link to an error page, that tells me:
WWC-41439 - You cannot login because there is either invalid or no configuration information stored in the enabler configuration table (WWSEC_ENABLER_CONFIG_INFO$).

Cause:

One or both of the following occurred:

• An alias defined in the Apache configuration caused Apache to translate host.domain.com to just host. If this is the case, the Login link only shows host:port (dropping the domain).
• The default domain was not set in the Apache configuration. When this occurs, only the hostname is shown in the Login link and the domain is not included.
• The Portal was configured with an incorrect host or port.

Action:

Do one or both of the following:

• Remove all such aliases from your Apache configuration.
• Include the domain in the ServerName parameter.
• Fix the Host in the IASInstance element and ListenPort in the WebCacheComponent element in iasconfig.xml and run ptlconfig -dad portal -site. The ptlconfig script and the iasconfig.xml file is normally located in the directory portal/conf under the OracleAS Portal and OracleAS Wireless middle-tier home.

Looks like we still have to explain to portal, that the url's are routed somewhere else, which makes sense, of course.
Just fixing the host entry in iasconfig.xml and running the ptlconfig utility does not seem to be enough; inspecting the table shows:

SQL> select LS_LOGIN_URL from portal.WWSEC_ENABLER_CONFIG_INFO$
/

LS_LOGIN_URL
------------------------------------------------------------------------------------------------------------------------------------
http://asinfra101202.mymachine.local:7777/pls/orasso/orasso.wwsso_app_admin.ls_login

SQL> update portal.WWSEC_ENABLER_CONFIG_INFO$
2 set LS_LOGIN_URL = 'http://asmt101202.mymachine.local:7777/pls/orasso/orasso.wwsso_app_admin.ls_login';

1 row updated.

SQL> commit;

That does the trick - no more redirects.
In a nutshell:

1. Enable the orasso DAD on the middle tier.
2. Reregister the SSO server (middle tier)
3. Fix iasconfig.xml
   
4. Update the portal table

Troubles....

About two weeks ago, my monitor went dead. I switched it on, and it did ''poof!" - lights out. Funny smell came from it, too. Anyway - no fuse to be seen, and as the main switch was dead as well (no power light), I decided to say farewell to my 19" Iiyama, that has served me for about 8 years.
So - something new had to be bought, but what? I wanted a 22" wide Samsung (the SyncMaster 225 BW), but after discussing the pro and cons, I decided for a 204B (20", 1600 by 1200 resolution), and a graphics card upgrade (my old card could neither handle the resolution, nor DVI - not that DVI is a requirement...).
Luckily, the "new" card fitted in my computer (which still uses AGP - I know, hopelessly old fashioned), so I'm typing away with a crisp, clear screen, and a lot more space on my desk.