Policy Configuration in OpenSSO 8.0 U2 Patch 1 still not working

This is a follow up to my post in Feb. I was trying to configure my authentication sources in a failover/load-balanced manner. It was not successful in OpenSSO 8.0 U2, but that was fine since I wrote my own authentication module. Thus was able to fix the bug within my own module.

However, there is another section in OpenSSO which we need to configure the same way - Policy Configuration. We have since upgraded to OpenSSO 8.0 U2 Patch 1. However, the same bug exist.

As long as the format is "local server name|host name:port", the OpenSSO server will get confused and will not parse the string properly.

What's the workaround?

The best we can do is to configure OpenSSO in a load-balanced manner (point to localhost). Failover is not possible in this configuration.


.

OpenSSO 8.0 U2 Patch 2 available

OpenSSO 8.0 U2 Patch 2 has just been released on 12th March 2011. That's a pretty fast release since the last patch release (U2 Patch 1) was just in Jan 2011.

(from 141655-06) U2 Patch 2
Problem Description:
7002787 OpenSSO 8.0 u2 & u2p1 not working with Active Directory DataStore
6987837 OpenSSO8U1P3 - SystemTimerPool - Throws ArrayIndexOutOfBoundsException message regularily
7006491 ERROR: "Not a supported type: FILTEREDROLE" following opensso upgrade when assigning privileges
6994715 OpenSSO update 1 patch 3 oracle db logging error: ORA-01704: String Literal Too Long
7000981 Upgrading Am 7.1 patch3 deployment as a site to OpenSSO 8 U1 patch3 Servers and sites tab dissapear
7005627 Opensso8.0U1P3-sfo enabled attribute in the Secondary instance was missing
6993122 SPNameQualifier element should be removed from NameIDPolicy in SAML AuthnRequest
6935201 OpenSSO U1P3: DAUI sends errors after user reloads DAUI login url thrice
6677966 HttpServletRequest/HttpServletResponse not available in AMLoginModule when using Dist AuthUI
6982882 Browser goes into loop condition for an OpenSSO login when a policy requires realm authentication
6982149 OpenSSO - Null Pointer Exception during session upgrade
6979889 8.0u2 patch 1: Update version of jss4.jar in opensso
6996134 OpenSSO Authentication allows access to users to a Realm to which Users who do not belong to
6986916 problem with AM 7.1 patch 4 DAUI
6992299 problem with AM 7.1 patch 4
6982233 Migrate AM7.0p11 to OpenSSO 8.0u2: legacy agent profiles are still not shown on the console properly
7003167 CDCClientServlet regression with bugfix 6896456 using distauth
7007659 ssopreupgrade.bat stop in initialize with Can't find bundle for name ssoUpgrade
7012182 URI is considered as URL in the goto parameter when it is URL-encoded
7018596 AM 7.1 patch3 to OpenSSO 8.0 update2 upgrade displays configuration page post upgrade
7019578 After Upgrade from AM7.1p3 to OpenSSO 8.0:"Server error" while hitting "platform" button on admin console
7016248 problem with Accessmanager


The Jan release (U2 Patch 1) was a major for us in the project I am currently in for the local Education ministry.

There was a bug in the SJSWS 7 Policy Agent which happily redirecting a POST request as a GET request. This broke our single sign-on integration with Sun IdM. In this particular case, the Forget Password Wizard broke.

We tested U2 Patch 1 and the bug was resolved. What was fixed? I do not know since it's a closed source now.


.

The administration connector self-signed certificate cannot be generated

I was trying to setup OpenAM on a new VM for POC. 

In customer environment, the trend these days is to move away from Solaris OS (which I am very familiar with for the past 7 years) and to adopt Linux as much as possible. Nothing wrong with the OS, just that the physical boxes have got more and more expensive. 

So for this new VM, I have CentOS 5.5 installed (since most customers will be installing RHEL). 

It shouldn't be too difficult to install, I thought. I was wrong! I kept getting the following error:

The administration connector self-signed certificate cannot be generated because the following error occurred: openam: openam. 

I checked the Network Configuration and found that I have a matching Hostname: openam.

In the end, I found out that I need a matching entry in /etc/hosts.

The last entry "openam" is required.

Very strange! How come in "Configuration Store Details", the Host Name is "localhost" and is non-editable? How does that "localhost" get mapped to "openam"? Kind of confused and distracted during debugging.


.

Sun IdM reconciliation of Sun OpenSSO accounts

In the project that I am currently onboard, besides Single Sign-On, we have Identity Management in place.
Sun OpenSSO + Sun Identity Manager (aka Oracle OpenSSO + Oracle Waveset)

As OpenSSO is one of the Identity resources, we need to reconcile large number of accounts ( >40,000 in development ) into OpenSSO, but the reconciliation process always fail.

It took us pretty long to discover what is causing  - do remember to turn off debugging in OpenSSO.

The debug log IdRepo was too verbose (I turned to message logging in development) and was spending too much time logging, than trying to help in reconciliation.


.

amtune Issue

The Single Sign-On infrastructure which I helped to architect for the local ministry is about to go LIVE. I'm trying to tune the OpenSSO server before it's launched - amtune comes to mind. It's a built-in tool.

However, when I run the utility, I kept hanging at the following stage:

"Checking Application Server JVM mode (32-bit or 64-bit) for AS 9/Glassfish v2"

It's not moving. I waited for as long as 15 minutes. This can't be normal as I have used amtune in previous version of Sun Access Manager.


So I debugged the error log file. Nothing unusual. I realized the error shown on my shell prompt mapped to the following line in the error log file:

# /sso/opt/gf211/bin/asadmin generate-jvm-report --user admin --passwordfile /tmp/asadminpass --host localhost --port 8888 --secure --interactive=false


Being curious, I copied the line and tried to execute it manually. Found it!

The OpenSSO servers are SSL-enabled and the keystore in the system's JVM has not trusted the certificate yet. I answered "y" to the above.

Re-executed amtune again. Everything goes smoothly after that!

.

Sun DS with OpenSSO schema - High Available Connections

In a highly-available setup, each OpenSSO server is recommended to connect to a dedicated Sun Directory Server for its Data Store. The other Directory Server will be configured as the secondary server (dotted lines). This ideal setup will yield better performance.

How to do achieve that in OpenSSO/OpenAM via the AM Console?

The above setup is wrong. It means both OpenSSO servers will connect to LDAP1 always. And only when LDAP1 is down, will both of them redirect to LDAP2.

This is not what we want to achieve. We want the setup to be highly available and efficient. (aka good performance)


So, we need to play with Format: LDAP server host name:port | server_ID | site_ID.


Problem is how do we know what is the value for server_ID and what is the value for site_ID?

As usual, I whack the OpenDS directly. The configuration data for the above screen is stored in ou=iPlanetAMPlatformService.

The configuration for Site is stored in ou=com-sun-identity-sites.

The configuration for Servers is stored in ou=com-sun-identity-servers.

So, the configuration should be as follows:

Nice!

.

Backing up configuration data -- Part II

The configuration data which is stored in the embedded OpenDS/OpenDJ can be dumped out into a XML file.

This little script can do the job:

/sso/bin/tools/ossotools/opensso/bin/ssoadm export-svc-cfg -u amadmin -f /tmp/.admin.pwd -e secretkeytoencryptpassword -o /tmp/svc-config-bkup.xml
echo "Configuration dumped to /tmp/svc-config-bkup.xml"

.

Backing up configuration data

Before a project goes LIVE, what do we usually do? Make sure backup is in place in case disaster kicks in.

So, this is what I am doing this week. I need to have a backup mechanism for the Single Sign-On infrastructure which I have set up for the local education ministry.

This book comes in handy - OpenAM by Indira. There's this chapter on Backup, Recovery and Logging.

The safest way to backup OpenSSO/OpenAM configuration data is non other than filesystem backup. (not mentioned in Sun's documentation)

The critical files and directories that need to be backed up are as follows:
• bootstrap
• OpenDS (whole directory)
• .version
• .configParam
• certificate stores
• config/xml (whole directory; if there is customized service schema)


ssoadmin@node01 $ /usr/sfw/bin/gtar -cvf opensso-bak.tar --exclude "opensso/opends/logs" opensso/bootstrap opensso/opends opensso/.configParam opensso/.version opensso/.configParam opensso/opensso/.keypass opensso/opensso/.storepass opensso/opensso/keystore.jks


If you are lazy, backup the whole configuration directory. But I would suggest discarding the debug and log directories. 


That can take up a huge amount of space if the log is verbose.




.