Confusing Oracle/Sun Solaris OS Versioning

I'm always confused when I want to find out the exact release of the Solaris OS which I am working on.
If you do a "$ more /etc/release", you get something like below:

It's still very hard to relate 9/10 belongs to which release. I can relate more to U1, U2, etc... It's easier to track, at least for me.

Luckily, Wikipedia tracks it here.

• Solaris 10 1/06 ("U1")
• Solaris 10 6/06 ("U2")
• Solaris 10 11/06 ("U3")
• Solaris 10 8/07 ("U4")
• Solaris 10 5/08 ("U5")
• Solaris 10 10/08 ("U6")
• Solaris 10 5/09 ("U7")
• Solaris 10 10/09 ("U8")
• Solaris 10 9/10 ("U9")

.

OpenSSO - Installing Policy Agent on Oracle/Sun Web Server 7

I'm deploying a large-scale Single Sign-On infrastructure using OpenSSO for the local education ministry. 

There is a Sun Web Server 7 performing a Reverse Proxy to a backend application, and we intend to deploy the OpenSSO Policy Agent on the web server.

There is a certain sequence to follow to ensure the Policy Agent works:

1. Install Sun Web Server 7

2. Install OpenSSO Policy Agent for Sun Web Server 7

3. Configure Reverse Policy to backend application

If you swap 2 with 3, the Policy Agent will not be able to intercept user access via the reverse proxy, thus render the Policy Agent useless.

Why?

Take a look at the object configuration file in the Web Server config directory.
(Note: Not obj.conf, but -obj.conf)

The /UpdateAgentCacheServlet and /dummypost/sunpostpreserve must precede reverse-proxy-/.

If you swap 2 with 3, you'll find that 

reverse-proxy-/ precedes /UpdateAgentCacheServlet and /dummypost/sunpostpreserve.

If you to manually swap the sequence to make Policy Agent to work.


.

OpenSSO - Weird Policy Agent Naming Convention

I have been playing around with OpenSSO Policy Agent for a few weeks - installing and uninstalling many times.

Policy Agent installer uses the convention Agent_nnn as the Agent instance name. The 1st instance will be named Agent_001; 2nd instance will be named Agent_002.

The weird behavior happens when you uninstall the 2nd instance and then you install again. Logically, one would want this re-installed instance to be named as Agent_002 again. (since this is really the 2nd instance on the same server) 

Logical, no?

Sadly enough, the Policy Agent installer will skip Agent_002. It will rename this new instance as Agent_003, which is not acceptable to me!

What's the trick then?

Look for this hidden file in /sjsws_agent/data/.amAgentLookup

Before uninstall,

# Product Instances Translation Lookup File
Product_Instance_Count= 2
/opt/webserver7/https-ams.sso.mo.sg-1/config|= Agent_001
/opt/webserver7/https-ams.sso.mo.sg-2/config|= Agent_002

After uninstall,

# Product Instances Translation Lookup File
Product_Instance_Count= 2
/opt/webserver7/https-ams.sso.mo.sg-1/config|= Agent_001


The Policy Agent installer program was able to remove the line ending with "Agent_002", but was just to lazy to decrement the Product_Instance_Count from 2 to 1. I feel like kicking the developer who wrote this piece of code.

Nevertheless, to resolve the issue, manually set the value to 1 prior to re-install again.

.

OpenAM from ForgeRock

I have been wanting to install OpenAM for a while, but didn't have the time to do so until now.

Nothing much have changed except the color scheme. It's now orange, instead of the blue which we are used to for a while. :)

A slight difference in one of the OpenAM Configurator steps - User Data Store Settings. 

There are now 6 types of supportable User Data Store Types to choose from. 

Once configuration is done, we are redirected to the Login Page as usual.

It's a nicer page! Welcome to OpenAM!

.

MySQL Latest Price List

Oracle is giving you more support options, thus they need to collect more $ from you.

It's for your own good, my friend. 

Oracle knows better than you.

.

Algorithm DES/ECB is not available from provider Cryptix

I was tasked to port a very old Web Services application to Sun Glassfish Enterprise Server 2.1.1. This application uses a cryptography library from Cryptix. (Cryptix has been dead since 2005.)

 

On my development environment on MacBook, everything runs fine on Glassfish with JDK 1.6.0_16. However, when I ported to the production environment on Solaris 10, I kept getting the following error:


java.security.NoSuchAlgorithmException: algorithm DES/ECB is not available from provider Cryptix
at xjava.security.IJCE.getClassCandidate(IJCE.java:457)
at xjava.security.IJCE.getImplementationClass(IJCE.java:410)
at xjava.security.IJCE.getImplementation(IJCE.java:367)
at xjava.security.Cipher.getInstance(Cipher.java:489)
at xjava.security.Cipher.getInstance(Cipher.java:452)
at com.sun.moe.security.DESEncryptor.decrypt(DESEncryptor.java:133)
at com.sun.moe.login.AppLogin.main(AppLogin.java:80)


Very strange! After a long debugging session, I found the issue was with the JDK 1.6.x version.

I downgraded the JDK to 1.5.0_20 that shipped default with Solaris 10. It works!


I believe there must be some "tightening" done in this file in JRE, but I just cannot figure how to resolve it.

-bash-3.00$ cat /jdk/jdk1.6.0_16/jre/lib/security/sunpkcs11-solaris.cfg


#
# Configuration file to allow the SunPKCS11 provider to utilize
# the Solaris Cryptographic Framework, if it is available
#


name = Solaris


description = SunPKCS11 accessing Solaris Cryptographic Framework


library = /usr/lib/$ISA/libpkcs11.so


handleStartupErrors = ignoreAll


attributes = compatibility


disabledMechanisms = {
CKM_MD2
CKM_MD5
CKM_SHA_1
CKM_SHA256
CKM_SHA384
CKM_SHA512
CKM_DSA_KEY_PAIR_GEN
# KEY_AND_MAC_DERIVE disabled due to Solaris bug 6306708
CKM_SSL3_KEY_AND_MAC_DERIVE
CKM_TLS_KEY_AND_MAC_DERIVE
# the following mechanisms are disabled due to performance issues (Solaris bug 6337157)
CKM_DSA_SHA1
CKM_MD5_RSA_PKCS
CKM_SHA1_RSA_PKCS
CKM_SHA256_RSA_PKCS
CKM_SHA384_RSA_PKCS
CKM_SHA512_RSA_PKCS
# the following mechanisms are disabled to ensure backward compatibility (Solaris bug 6545046)
CKM_DES_CBC_PAD
CKM_DES3_CBC_PAD
CKM_AES_CBC_PAD
}


Anyone has an idea?

.

OpenSSO - High-Available Data Stores

In a highly available setup, the OpenSSO Enterprise Server should connect to at least a pair of Data Stores.

When a failover kicks in, the following will be captured in IdRepo log file:

IdCachedServicesImpl.getAttributes(): null found all attributes in Cache.
LDAPv3EventService:11/10/2010 02:50:10:642 PM SGT: Thread[LDAPv3EventService,5,main]
WARNING: LDAPv3EventService.run() LDAPException received: randomID=1490605490
com.sun.identity.shared.ldap.LDAPException: Server or network error (81)
at com.sun.identity.shared.ldap.LDAPConnThread.networkError(LDAPConnThread.java:782)
at com.sun.identity.shared.ldap.LDAPConnThread.run(LDAPConnThread.java:567)
at java.lang.Thread.run(Thread.java:619)


LDAPv3EventService:11/10/2010 02:50:10:651 PM SGT: Thread[LDAPv3EventService,5,main]
LDAPv3EventService.dispatchAllEntriesChangedEvent() psIdKey=ds2.sso.mo.sg:1389 ds1.sso.mo.sg:1389o=Edu,c=SGo=Edu,c=SG(objectclass=*)
LDAPv3Repo:11/10/2010 02:50:10:651 PM SGT: Thread[LDAPv3EventService,5,main]
LDAPv3Repo.objectChanged: dn=null; changeType4; psIdKey=ds2.sso.mo.sg:1389 ds1.sso.mo.sg:1389o=Edu,c=SGo=Edu,c=SG(objectclass=*); allObjChanged=true; clearCache=true
idrepoListener:11/10/2010 02:50:10:652 PM SGT: Thread[LDAPv3EventService,5,main]
**********************************************
idrepoListener:11/10/2010 02:50:10:652 PM SGT: Thread[LDAPv3EventService,5,main]
IdRepoListener: allObjectsChanged Called!
amIdmJAXRPCServer:11/10/2010 02:50:10:679 PM SGT: Thread[LDAPv3EventService,5,main]
**********************************************




The failover works! Cool!


However, when the primary Data Store is up again, the OpenSSO Enterprise Server does not switch back from the secondary Data Store.

.

OpenSSO - Policy Agent Issue with Time Sync

I was debugging a OpenSSO Policy Agent issue for a customer. He has deployed the Policy Agent for Sun Java Systems Web Server 7.

The application which resides on the Web Server 7 gets protected Policy Agent and redirected to the OpenSSO Login Page. However, when he keyed in valid username and password, the browser kept hanging on the OpenSSO Login Page.

From the Policy log in OpenSSO Enterprise Server, I noticed that there was lot of communications between the agent and the server (even though the browser looks "hang" on the Login Page). The following segment keeps repeating.

From the amAgent log, I noticed the following:

2010-11-09 14:41:47.618 Warning 25919:815c858 ServiceEngine: Service::getPolicyResult():Result size is 0,tree not present for http://ok.sso.mo.sg:8080/index.html

2010-11-09 14:41:47.618MaxDebug 25919:815c858 AM_POLICY_SERVICE: am_policy_compare_urls(): compare usePatterns=true returned 0
2010-11-09 14:41:47.618MaxDebug 25919:815c858 AM_POLICY_SERVICE: am_policy_compare_urls(): compare usePatterns=true returned 4
2010-11-09 14:41:47.618 Debug 25919:815c858 all: Policy time stamp for resource http://ok.sso.mo.sg:8080/* is (1289284876056000)2010-11-09 14:41:16.056.
2010-11-09 14:41:47.618 Info 25919:815c858 all: Policy node http://ok.sso.mo.sg:8080/* marked stale due to time out.


Something is fishy. This has something to do with time sync.

I checked and confirmed that the 2 servers (OpenSSO Enterprise Server and the Web Server) were in different time zone. I tweaked with NTP and made them sync with the same clock.

Re-run and the policy agent works like a charm!

.