Weird behavior in OpenAM 9.5.3 RC1 when configured with external configuration data store

OpenAM 9.5.3 stable release was released today. The download link is here.

Prior to this stable release, I was using 9.5.3 RC1 for a demo and discovered a weird behavior. Luckily,  it's gone in 9.5.3 stable release.

The issue only happened when an external configuration data store is used. In my case, I was using OpenDJ 2.4.2.

As with any default OpenAM installation, the log level was set to ERROR. I wanted to debug my deployment, thus I went ahead to set the log level from ERROR to MESSAGE via the OpenAM Administration Console.

Set Debug Level to "Message".

Everything ran fine. The verbose logging was output. However, once I restarted the web container, I'll not be able to get to the Login page anymore.

The Session log threw the following error:

**********************************************
amSSOProvider:08/02/2011 04:48:45:718 PM SGT: Thread[main,5,main]
SSO token ldap auth successful for AuthPrincipal: cn=dsameuser,ou=DSAME Users,dc=opensso,dc=java,dc=net
amSession:08/02/2011 04:48:45:777 PM SGT: Thread[main,5,main]
ERROR: SessionService.SessionService(): Initialization Failed
com.iplanet.services.naming.ServerEntryNotFoundException
at com.iplanet.services.naming.WebtopNaming.getServerID(WebtopNaming.java:730)
at com.iplanet.services.naming.WebtopNaming.getServerID(WebtopNaming.java:618)
at com.iplanet.dpro.session.service.SessionService.(SessionService.java:1772)
at com.iplanet.dpro.session.service.SessionService.getSessionService(SessionService.java:448)
at com.sun.identity.authentication.service.AuthD.getSS(AuthD.java:905)
at com.sun.identity.authentication.service.AuthD.initAuthSessions(AuthD.java:938)
at com.sun.identity.authentication.service.AuthD.(AuthD.java:273)
at com.sun.identity.authentication.service.AuthD.getAuth(AuthD.java:560)
at com.sun.identity.authentication.UI.LoginLogoutMapping.initializeAuth(LoginLogoutMapping.java:100)
at com.sun.identity.authentication.UI.LoginLogoutMapping.init(LoginLogoutMapping.java:75)


The fastest workaround was to change the LDAP value in the external configuration data store from MESSAGE back to ERROR.

Change to "ERROR".

Restarted web container. Solved. Everything back to normal. Very weird.  ( I tried Tomcat 6 and Glassfish 2.1, both threw the same error if external configuration data store is used )

Today, I tried OpenAM 9.5.3 with embedded and external config data store. Both work!

Out of curiousity, I tried OpenAM 9.5.3 RC1 with embedded config data store. It works! So it's only with external config data store, then it fails. Hmmmm....

.

 

Permission to perform the edit operation denied

In one of the OpenSSO projects I'm currently in, we have customized attributes defined in Sun DSEE 7. These attributes extend from inetorgperson.

In the Post Authentication Processing module, we would want to update one of the attributes if a certain condition is met. 

So I have the following code segment:

AMIdentity amIdentity = new AMIdentity(ssoToken);

:
Map attrs = new HashMap();
Set values = new HashSet(1);
values.add (valueToSet);
attrs.put (SUNLDAPUser.ATTRIBUTE_MUSTCHGPWD, values);
amIdentity.setAttributes(attrs);
amIdentity.store();

Looks good! But when we run it, we encountered the following error:
"Permission to perform the edit operation denied ..."

Strange! Why?

After much investigation, I then realized we need to loosen the policy in the embedded OpenDS store.

There is a xmlpolicy attribute in ou=SelfWriteAttributes,ou=Policies,ou=default,ou=OrganizationConfig,ou=1.0,ou=iPlanetAMPolicyService,ou=services,o=sunamhiddenrealmdelegationservicepermissions,ou=services,....

So, the trick is to add the attribute that we want to modify into the UserSelfCheckCondition.

Restart OpenSSO. Test. Done.


.

Incompatible Sun Message Queue Version

I have been trying to scale a old Sun Access Manager deployment from 2 nodes to 4 nodes.

In trying to yield better performance, I made some minor upgrade to each dependent components. I knew that Sun Message Queue 4.x has better performance than the old 3.6 version.

So, I made a weird decision to deploy a hybrid of Sun Message Queues - 3.6 mixed with 4.4.

No good. You'll see this error in the MQ log during startup of AM SFO:



[29/Jun/2011:14:21:36 SGT] ERROR [B3098]: Configuration mismatch: Aborting connection with broker [ mq://10.10.10.15:7878/?instName=imqbroker&brokerSessionUID=null ] because following configuration properties do not match -
imq.queue.deliverypolicy=round-robin,single

[29/Jun/2011:14:21:36 SGT] ERROR [B3098]: Configuration mismatch: Aborting connection with broker [ mq://10.10.10.16:7878/?instName=imqbroker&brokerSessionUID=null ] because following configuration properties do not match -
imq.queue.deliverypolicy=round-robin,single


Update on 27th Jul 2011:


I realized hybrid deployment of Sun MQ works! In fact, the new deployment of different version of MQ has been running LIVE for a few weeks without any problem. (will continue to monitor though ...)

.

I talked about the wonderful ESSO solution from PasswordBank some time back. Read here.

This product differentiates itself by being able to support Desktop Platforms like Windows, Linux and Mac OS. This is something great! ESSO product has always been very Windows driven.

It has caught the attention of Oracle. PasswordBank is now Oracle's partner of choice for heterogeneous environment deployment.

This is something Passlogix v-GO SSO was not able to provide. By the way, Passlogix was aquired by Oracle just some months back. Read here.

Will PasswordBank be Oracle's next target? :)

.

SaaS SSO Vendors

The following is a list of SSO vendors that provides SaaS:

• Okta
• PasswordBank
• PingIdentity
• Secure Auth
• Simplified
• UbiSecure

How about OpenAM?

Not so soon ... Still on the roadmap... we need to wait a little longer...



Replication over WAN

I have a customer that has a server farm of Directory Servers. These directories are deployed in multiple sites, thus WAN replication is required to keep data in-sync.

In one of the directory instances, binary data are stored. Thus resulting in huge entries (some are as huge as 20MB per attribute value).

They were using Sun Directory Server 5.x happily before they were switched to Sun DSEE 6.x due to EOL of DS 5.2. Replication starts to break for those instances with huge entries.

In this particular case, customer was trying to replicate from a Wins2k3 box to a Solaris Sparc box.

We raised a Support Case with Oracle Support and were told the following:

I would consider your customer setup as a corner case which is a mixture of all the following:

* replication over SSL
* replication over a slow WAN link
* replication of huge entries
* replication topology mixing different versions
* replication not using compression
* replication timeouts not correctly set

AFAIK, the best performance of the Directory Server is obtained with the following combination:

* DS 7.0.1
* Solaris x86
* ZFS

Oracle kept suggesting getting Professional Services people to "take a look and make suggestion".

But to the customer, the equation is so simple:
* There were no change in topology, OS, and data
* DS 5.x works
* Why would DSEE 6.x breaks? Shouldn't 6.x be a enhanced version of 5.x?

It's definitely a limitation in DSEE 6.x which Oracle refuses to admit.



By the way, we always do our own homework and below are some findings:

1. 5.2 SP6 (wins 2k) -> 5.2 SP6 (solaris sparc) ==> OK
2. 5.2 SP6 (wins 2k) -> 6.3.1 (solaris sparc) ==> NOT OK
3. 6.3.1 (windows) -> 6.3.1 (solaris sparc) ==> NOT OK
4. 6.3.1 (solaris) -> 6.3.1 (solaris sparc) ==> NOT OK
5. 7.0.1 (solaris) -> 6.3.1 (solaris sparc) ==> NOT OK
6. 7.0.1 (solaris) -> 7.0.1 (solaris sparc) ==> NOT OK


In the end, I called upon my friend (OpenDJ) for help. Looks good!

To the customer, slow is not important as long as the data is kept in-sync. Simple requirement.

The next step is to deploy a test-bed in the customer's environment to confirm replication over WAN works using OpenDJ. The past few months have been very miserable, especially talking to those people.

.

OpenDJ: Replication Setup Error Message

Today, I hit into some issues with OpenOSSO multi-servers setup. I am suspecting there's something not correct with the OpenDS configuration in a multi-servers deployment. Nothing concrete yet, am still investingating.

In order to provide some facts, I think setting 2 instances of OpenDJ in MMR mode would be good. At least, I have something to compare with.

So, the installation of OpenDJ was a breeze. (Do I re-broadcast so many times on this fact? :>)


Setting up replication is not hard if you have the following command line as a template. (No GUI yet to set up replication.)

[opendj@think bin]$ ./dsreplication enable --host1 think.sg.forgerock --port1 8888 --bindDN1 "cn=directory manager" --bindPassword1 password --replicationPort1 8989 --host2 think.sg.forgerock --port2 7888 --bindDN2 "cn=directory manager" --bindPassword2 password --replicationPort2 8989 --adminUID admin --adminPassword password --baseDN "dc=sg,dc=forgerock" -X -n


Establishing connections ..... Done.


You have provided the same replication port (8989) for two servers located on the same machine (think.sg.forgerock).


So, am I done or not done? Initially, I thought I'm done. But ... actually, it's not done.

Wouldn't the following be better?

ERROR: You have provided the same replication port (8989) for two servers located on the same machine (think.sg.forgerock).


.

java.lang.OutOfMemoryError: unable to create new native thread

I have been driven crazy for the past 2 weeks performing load tests for the Single Sign-On infrastructure in a local ministry.

Today, one of the customized application threw the following error:

java.lang.OutOfMemoryError: unable to create new native thread

While searching for a solution, I came across the following diagram. I think it's good to share as it's very clear in illustrating how to tune a 32-bit JVM. 

I had set the request processing thread (thread-count) to a high number of 500. (Ya! I was crazy to do that) At the same time, I set the Xmx and Xms to 2GB.

So the math was rather bad (if you can follow the diagram above). Ha!

In the end, we settled for Xmx and Xms to 512MB with thread-count being 200. The application flies!


.

Goodbye, Sun Messaging Server!

 Last Saturday, we finally decommissioned the Sun Messaging Server in our data center.

As everyone knows, Sun's software used to be free to use, even in production. Customers only need to pay if they require support. Well, that was yesterday and history. :)

Salute to Sun Messaging Server!

SSL handshake

There has been a lot of discussions on how to configure SSL-enabled OpenAM servers to communicate with one another via self-signed certificates.

Actually, honestly speaking, it's not an OpenAM issue. It's a JDK key-store issue. One needs to understand how SSL works. As mentioned in my blog some times back, I found this link a good start.

These days, I am using SSLPoke pretty often. This is the most wonderful tool to have. I'll make sure SSLPoke pass before I continue to configure the 2nd and subsequent OpenAM server.

Or you can set the following JVM-option:
"-Djavax.net.debug=SSL,handshake,trustmanager"

This will show why SSL handshake fails.


.

Sun Java System Web Server 7 Policy Agent Issue

I spent almost 1.5 weeks trying to resolve a Policy Agent issue in one of my customers' environment.

Even though they have Sun Java System Web Server 7, their configuration is "ancient" type. We know that there is a modern in-built Reverse Proxy plugin in Web Server 7. But the customer is still using the legacy Glassfish Load-Balancer plugin.

Cross-Domain Single Sign-On

There is this scenario where the Web Server is residing in a different domain from OpenSSO Server.

In CDSSO mode, the agent for SJSWS does not reset the protocol version to the one from POST-request [HTTP/1.1] (received from the CDCServlet), but to a HTTP-Request version 0.9 [HTTP]. This scenario only happens in CDSSO mode due to the handling of the assertion the agent got from the CDCServlet.

Step-by-Step

1. Policy Agent intercept "GET /hello/ HTTP/1.1"
2. Since this is CDSSO, Policy Agent attempts to reset protocol version ( from HTTP/1.1 to HTTP )
3. Policy Agent then allow the request to pass to the plugin

Note: A HTTP without any version should be interpreted as HTTP 0.9, according to W3C.

This is what W3C has to say with regard to HTTP Protocol Version:

The Protocol/Version field defines the format of the rest of the request.. At the moment only HTRQ is defined. If the protocol version is not specified, the server assumes that the browser uses HTTP version 0.9.

So, what's the issue then?

Load Balancer Plugin (Web Server Access Log)

192.168.1.47 - - [13/Apr/2011:17:30:55 +0800] "GET /hello/ HTTP/1.1" 302 0
192.168.1.47 - admin [13/Apr/2011:17:31:02 +0800] "GET /hello/ HTTP" 505 0

Reverse Proxy Plugin (Web Server Access Log)

192.168.1.47 - - [14/Apr/2011:10:28:48 +0800] "GET /hello/ HTTP/1.1" 302 0
192.168.1.47 - admin [14/Apr/2011:10:28:55 +0800] "GET /hello/ HTTP" 200 327

The issue is:

a. LB-plugin: Not able to respect HTTP version 1.0 and below ("HTTP Error 505 HTTP version not supported' error)

b. RP-plugin: Able to respect HTTP version 1.0 and below

Clearly, there is something wrong with the Load-Balancer plugin. According to W3C, it has to honor HTTP and let the request to pass-through.

And, although it is fairly rare that any software/application will send a HTTP with protocol version lower than 1.0 these days, it is totally "legal" to do so.

In this case, the Policy Agent chooses to swallow a request with HTTP/1.1, but passes a request HTTP to the plugin. Rightfully, it would be ideal to swallow HTTP/1.1, and passes the same HTTP/1.1 to the plugin.




PS: Btw, I need to thank Bernhard for helping me with this issue. Thanks, Bernhard!
.

OpenDJ Directory Server

ForgeRock has done a great job with OpenDJ Directory Server so far.

So what does OpenDJ provides, in a nutshell? A diagram will be best for illustration.

For anyone interested in the details of OpenDJ, here is the latest product sheet for your reference.

.

Web Agent Caching Behavior

I have been asked a few times by customers on how Policy Agent manages its internal cache. I think I might as well make a note of this so that I can make reference to this question again much easier next time.

There is actually a documentation on this topic here.


Summary

1. Policy agent caches users' policies
2. 2 mechanism are utilized: notification and/or polling
3. Each cache entry expires in 3 minutes, by default

Firewall Consideration

The challenge comes when there is a firewall between the Policy Agent and OpenSSO Enterprise Server. In such circumstance, notification should be turned off. (Otherwise, you'll get a lot of error on the OpenSSO debug log complaining about non-contactable agents.)

Production Scalability Consideration

1. Policy changes are frequent
2. Sites need to accept the fact that there will always be latency to reflect policy changes
3. No hard rule on this latency time as long as it's acceptable for the site's specific needs

The guideline when setting the Policy Cache Polling Period property is to set it to the lower of the two:

• The session idle timeout period
• Site’s accepted latency time for policy changes

.

Unable to find active Access Manager Auth server

If a protected application is running (with Policy Agent), but the backend OpenAM/OpenSSO server is down, you'll get "Forbidden" error on the web browser.

"Your client is not allowed to access the requested object"

The following will be captured in the amAgent log:

am_web_get_url_to_redirect: unable to find active Access Manager Auth server.

.

ERROR: Invalid Agent: Could not get agent for the realm

Sometimes, when CDSSO is configured, one will encounter HTTP Status 500 after a successful login.

1. Access protected application 

2. Redirect to OpenSSO Login Page

3. Upon successful login, redirect back to protected application

Step 3 is not happening. Instead, user encounters HTTP Status 500.

If you take a look at the amAgent log on the protected application side, there is nothing unusual. All seems good. 

Something is definitely wrong on the OpenSSO server end. 

The problem is "Unknown Host Exception".  Add the FQDN to the /etc/hosts resolves the issue!

.

OpenAM 9.5.2 CLI Configuration

I was trying to install a new install of OpenAM 9.5.2 for a POC using the GUI Configurator. (Read here)

The problem then was the embedded OpenDS 2.3 will always create a Administrator Connector Self-Signed Certificate using the hostname. If this hostname is not defined in /etc/hosts, configuration will bomb.

ERROR: AMSetupServlet.configure: error
org.opends.server.types.InitializationException: The administration connector self-signed certificate cannot be generated because the following error occurred: openam: openam
at org.opends.server.admin.AdministrationConnector.handleCertifExceptions(AdministrationConnector.java:776)
at org.opends.server.admin.AdministrationConnector.createSelfSignedCertifIfNeeded(AdministrationConnector.java:757)
at org.opends.server.admin.AdministrationConnector.initializeAdministrationConnector(AdministrationConnector.java:181)


Today, I tried to find out whether or not this can be workaround by using CLI configuration.


SERVER_URL=http://openam.sg.azlabs:9080
DEPLOYMENT_URI=/openam71
BASE_DIR=/home/openam952/openam71
locale=en_US
PLATFORM_LOCALE=en_US
AM_ENC_KEY=wKO7mExvCqVXETTtsgU4HgtvqBXrFzSW
ADMIN_PWD=password
AMLDAPUSERPASSWD=amldapuser
COOKIE_DOMAIN=.sg.azlabs


DATA_STORE=embedded
DIRECTORY_SSL=SIMPLE
DIRECTORY_SERVER=openam.sg.azlabs
DIRECTORY_PORT=51389
DIRECTORY_ADMIN_PORT=8888
DIRECTORY_JMX_PORT=1689
ROOT_SUFFIX=dc=opensso,dc=java,dc=net
DS_DIRMGRDN=cn=Directory Manager
DS_DIRMGRPASSWD=password


## Leave (blank) will default to embedded DATA_STORE
USERSTORE_TYPE=


No use.

The OpenDS is still trying to create the Administrator Connector Self-Signed Certificate using the hostname.

By the way, in OpenAM 9.5.2, with the upgrade of OpenDS from 1.x to 2.3, the following 2 attribute-value pairs are required:

DIRECTORY_ADMIN_PORT=8888

DIRECTORY_JMX_PORT=1689

Quite a painful experience as the documentation wasn't there. I had to read the source code and trace what was required by the configurator.

For those interested, I was looking at the method runOpenDSSetup (...) in EmbeddedOpenDS.java

setupCmd[2] = (String) map.get(SetupConstants.CONFIG_VAR_DIRECTORY_ADMIN_SERVER_PORT);
setupCmd[4] = (String) map.get(SetupConstants.CONFIG_VAR_ROOT_SUFFIX);
setupCmd[6] = (String) map.get(SetupConstants.CONFIG_VAR_DS_MGR_DN);
setupCmd[8] = (String) map.get(SetupConstants.CONFIG_VAR_DIRECTORY_SERVER_PORT);
setupCmd[13] = (String) map.get(SetupConstants.CONFIG_VAR_DIRECTORY_JMX_SERVER_PORT);


Then I went to SetupConstants.java to find out what attribute names are required:

/**
* Configuration Variable for directory server admin port.
*/
String CONFIG_VAR_DIRECTORY_ADMIN_SERVER_PORT = "DIRECTORY_ADMIN_PORT";


/**
* Configuration Variable for directory server jmx port.
*/
String CONFIG_VAR_DIRECTORY_JMX_SERVER_PORT = "DIRECTORY_JMX_PORT";




.

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.




.