Incorrect AVA format

Got this error when trying to create a keystore.

c:\3960\glassfish\domains\domain1\config>keytool -genkey -keyalg RSA -keystore a
mkeystore.jks -validity 365 -alias "fam8" -dname "amqa-x2100-01.red.iplanet.com,
ou=identity,o=sun.com,L=santa clara, ST=CA, C=US"
Enter keystore password:
Re-enter new password:
keytool error: java.io.IOException: Incorrect AVA format

Which was because, i had incorrect dname
Should be "cn=amqa-x2100-01.red.iplanet.co...........

Some not-so-coomon ssoadm examples

ssoadm command line utility that comes with OpenSSO is indeed a very handy little piece of tool
Here are few examples for some not so common usages of ssoadm, which I learnt and want to share

1) Here was a request to the users alias "does someone know the ssoadm command to change signature algorithm for saml2 assertion ( typically to choose RSA-SHA256 ) ? ( corresponding to the gui for the admin console in Configuration/Global/federation/Signature ) "

You should be able to use "ssoadm set-attr-defs" to set the signature algorithm and "ssoadm get-attr-defs" to see the updated value.

./ssoadm set-attr-defs -s sunFAMFederationCommon -t Global -u amadmin -f /usr/tmp/pass -a "SignatureAlgorithm=http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
bash-3.00# ./ssoadm get-attr-defs -s sunFAMFederationCommon -t Global -u amadmin -f /usr/tmp/pass
(Thanks Charles)

del del del..unwanted mails..bites me back

There were series of mails from our IT department warning us about servers being decommissioned. But first I postponed the needed, then forgot, and then ignored the FINAL WARNING.
What happens...
My lack of action bit me back and my solaris box was unusable

Having grown up with windows machines, unix is something I am still getting used to.
So I was so scaared of what happens

But it turns out that, the IT team had done a pretty good document which guided us step by step.
And in course I also learnt a couple of new things

- ypwhich - gives the NIS server the machine is currently using
-- you can also try "ypwhich another-machine-on-nw"

- /etc/resolv.conf - Defines which naming server to use
Eg - nameserver 129.147.9.5, where 129.147.9.5 is the ip address of the naming server used

"No more processes" in solaris machine

Another new error
Product deployment failed in solaris with error some jre lib exception
Googling said I had to increase the number of processes in os level in /etc/system
But even vi failed with "no more processes"
So had to reboot and issue gone!!

First time i saw this.. should remember

Opensso configuration failure - case 2 - UnsupportedClassVersionError

The upcoming express build, build 8 ( as well as the available nightly's) now support only jdk6 at the opensso server container.

This is the exception you see when configuring with jdk5

Symptom:
-----------
Opensso configuration fails

--> Configuration fails at
Checking configuration directory /export/isqa/SJSWS/opensso-8080....Success.
Installing OpenSSO configuration store...Success RSA/ECB/OAEPWithSHA1AndMGF1Padd
ing.
Installing OpenSSO configuration store in /export/isqa/SJSWS/opensso-8080/opends
...Success.
Creating OpenSSO suffix...Success.
Tag swapping schema files....Success.
Loading Schema opends_config_schema.ldif...Success.
Loading Schema opends_user_schema.ldif...Success.
Loading Schema opends_embinit.ldif...Success.
Loading Schema opends_user_index.ldif...Success.
Loading Schema opends_plugin.ldif...Success.
...Success.
Reinitializing system properties.AMSetupServlet.processRequest: errorcom.sun.ide
ntity.security.AMSecurityPropertiesException: AdminTokenAction: FATAL ERROR: Ca
nnot obtain Application SSO token.
Check AMConfig.properties for the following properties
com.sun.identity.agents.app.username
com.iplanet.am.service.password
at com.sun.identity.security.AdminTokenAction.run(AdminTokenAction.java:
258)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.identity.security.AdminTokenAction.run(AdminTokenAction.java:
258)
at java.security.AccessController.doPrivileged(Native Method)
at com.iplanet.am.util.SystemProperties.initializeProperties(SystemPrope
rties.java:450)
at com.sun.identity.setup.AMSetupServlet.reInitConfigProperties(AMSetupS

--> {config dir}/opensso/debug/Configuration shows
amSMS:07/21/2009 02:20:35:953 PM PDT: Thread[service-j2ee-5,5,main]
ERROR: SMSObjectDB: Unable to get amsdkbasedn:

Got LDAPServiceException code=19
at com.iplanet.services.ldap.DSConfigMgr.getDSConfigMgr(DSConfigMgr.java
:162)
at com.sun.identity.sm.SMSObjectDB.getAMSdkBaseDN(SMSObjectDB.java:58)
at com.sun.identity.sm.SMSObjectDB.getRootSuffix(SMSObjectDB.java:112)
at com.sun.identity.sm.ldap.SMSLdapObject.initialize(SMSLdapObject.java:
201)
.....................

The lower level exception message
Connection to the server could not be established
The lower level exception:
com.sun.identity.shared.ldap.LDAPException: Connection to the server could not b
e established (-1)

--> /opends/logs dont report any exception

--> Container logs says "java.lang.UnsupportedClassVersionError: PWC1651: Class com.sun.identity.idsvcs.I
dentityServicesImpl has unsupported major or minor version numbers, which are gr
eater than those found in the Java Runtime Environment version 1.5.0_15
"

So this is the culprit - JDK container is using is - 1.5.0_15

Solution:
-----------
Upgrade container jdk to jdk6 and reconfigure

Other configuration Issues:
http://nithyastechnotes.blogspot.com/2009/07/opensso-configuration-failure-case-1.html
http://nithyastechnotes.blogspot.com/2009/07/opensso-deployment-issue-in-geronimo.html

Opensso deployment issue in geronimo 2.1.4

The opensso nightly builds dont deploy on geronimo 2.1.4

This is due to a the way the webservices-tools.jar is bundled.

rwxr-xr-x 0 26-Sep-2008 13:19:20 1.0/
drwxr-xr-x 0 26-Sep-2008 13:19:22 1.0/META-INF/
-rw-r--r-- 656 28-Mar-2005 12:23:02 1.0/META-INF/MANIFEST.MF
drwxr-xr-x 0 26-Sep-2008 13:19:22 1.0/META-INF/services/
-rw-r--r-- 164 28-Mar-2005 12:22:14 1.0/META-INF/services/com.sun.tools.xjc.CodeAugmenter
-rw-r--r-- 44 2-Nov-2002 16:15:24 1.0/META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory
drwxr-xr-x 0 28-Mar-2005 12:20:58 1.0/com/
drwxr-xr-x 0 26-Sep-2008 13:19:20 1.0/com/sun/
drwxr-xr-x 0 26-Sep-2008 13:19:22 1.0/com/sun/codemodel/
-rw-r--r-- 287 28-Mar-2005 12:20:36 1.0/com/sun/codemodel/CodeWriter.class
...
-rw-r--r-- 1179 28-Feb-2008 18:49:50 com/sun/codemodel/CodeWriter.class

Because of the 1.0 in the package structure.

Geronimo issue opened for this is - https://issues.apache.org/jira/browse/XBEAN-126

Opensso issue opened to document this is - https://opensso.dev.java.net/issues/show_bug.cgi?id=4976

NOTE : opensso works fine on geronimo 2.1.1

Building your own OpenSSO ? Heres how you can quickly test it

I guess not many members of the OpenSSO community are aware of the testing framework inbuilt in the product. This article will help you to understand how you can use this feature to quickly validate your OpenSSO build.

Where is the framework?
It is called qatest and in available under opensso, when you check out the cvs source code.

What is the framework?
It is a pure java based testing framework built using open source tools like testng,ant,jetty

Which aspect of the framework is covered in this article?
Sanity tests all the core features of OpenSSO product. Helps avoiding basic regressions.

How to use it?
What I am covering in this article, is how to quickly sanity test a opensso build.
There is some setup required, gathering all the required jars, as this is not shipped with the product. But the results are worth this effort.
Other than this, with minimalist changes required, you get all the key features of opensso tested.

Prerequisites
1) From Opensso - opensso.war, Deploy the war on a supported container. You dont have to configure it.
2) Ant version 1.7.1 or above
3) Gathering the required jars. Place the following jars /qatest/lib folder.
-- openssoclientsdk.jar,opensso-sharedlib.jar corresponding to the build you are testing
-- testng-5.10beta-jdk15.jar,mysql-connector-java-5.0.8-bin.jar,javaee.jar,jsse.jar,saaj-api.jar,saaj-impl.jar,servlet.jar,webservices-rt.jar
-- Create a folder /qatest/lib/jetty and copy the jetty jars here
-- Create a folder /qatest/lib/htmlunit and copy the htmlunit1.1.4 jars here
-- Create a folder /qatest/lib/xacml and copy the jaxb-impl.jar jaxb-libs.jar
jars here
Click below for a diagrammatic representation of all the lib


4) Go to /qatest/resources
5) Copy the file Configurator-server_name.properties.template, and create a .properties file.
Eg: myserver.properties
6) Edit the file for details matching the setup you planned.
Eg:Below is my file,stripped of comments, which I used to run the sanity tests in my laptop.
com.iplanet.am.naming.url=http://localhost:8080/opensso/namingservice
cookiedomain=
amadmin_password=secret12
com.iplanet.am.service.password=secret123
config_dir=/Users/nithyasrinivasan/opensso-localhost
directory_server=localhost
directory_port=50389
config_root_suffix=dc=opensso,dc=java,dc=net
ds_dirmgrpasswd=secret12

Now what?
You are done.
Goto /qatest, fire the tests.

ant -lib lib/ant-contrib-1.0b3.jar -DSERVER_NAME1=myserver run

If the tests have been executed successfully, the run should finish the following output
[echo] The Automation reports are at <opensso home dir>/qatest//ldapv3/sanity

You can see the reports at this location.

Sample reports -