My instance of OpenSSO Enterprise Express Build 7 was installed with the option to use the embedded data store as a user data store. This option is for proof-of-concepts only and should not be used in real-time deployments. I wanted to check out some stuff regarding roles and, as the roles portion of OpenSSO only works with an installed Sun Directory Server, I installed Directory Server EE 6.3.
If you haven't installed OpenSSO yet, check out OpenSSO Build 2 and Glassfish: Ready to Go. It's an older entry but still works - despite the old screen shots. Once complete, proceed with the following tasks.
Decompress the file. gunzip DSEE.6.3.Solaris-Sparc-full.tar.gz
tar xvf DSEE.6.3.Solaris-Sparc-full.tar
For some reason, executing gunzip and tar with one command did not work on this compressed file.
Make a directory named /opt/dsee.
Install the Directory Server EE software into the /opt/ds directory. /ds/DSEE_ZIP_Distribution/dsee_deploy install -i /opt/dsee
Press Enter until you reach the end of the license agreement.
Type Yes when asked Do you accept the license terms? and press Enter to execute.
Make a directory in which to store Directory Server EE instances. mkdir /opt/dsee/instances
Change to the directory that contains the dsadm command-line interface. cd /opt/dsee/ds6/bin
Create a new instance of Directory Server. ./dsadm create -p 389 -P 636 /opt/dsee/instances/ example
You will be prompted to enter a password for cn=Directory Manager.
Start the example instance. ./dsadm start /opt/dsee/instances/example
Create the dc=example,dc=com suffix. ./dsconf create-suffix dc=example,dc=com
Type Y to accept the server certificate.
Enter the Directory Manager password.
In the next steps, you will load the OpenSSO schema and add the Directory Server instance as a user data store with the OpenSSO console.
Because my installation initially used the embedded data store as a user store I was not able to select this Directory Server instance during configuration so I had to follow the instructions, Loading the OpenSSO Schema into Sun Java System Directory Server.
Finally, add the data store to a realm. I created a sub realm to the /Top Level Realm and added the data store to the sub realm.
Login to the OpenSSO console as the administrator.
Click the Access Control tab.
Click New under Realms, enter the appropriate values and click OK to create a sub realm.
Click the name of the new sub realm.
Click the Data Stores tab.
Remove the embedded data store, if applicable.
Click New under Data Stores.
Enter a name, select Sun DS with OpenSSO Schema, and click Next.
Enter the appropriate server information and click OK.
At this point, I was able to create users using the OpenSSO console and the instance of Directory Server. I did have a some issues though viewing users I had imported from an LDIF file. Trainer extraordinaire David Goldsmith gave me these tips which worked.
Use the fully qualified host name as a value for LDAP Server when configuring the data store.
Set the Persistent Search Scope attribute to SCOPE_SUB as it is the default when you connect to an external LDAP directory during configuration.
Remove ou and people for the LDAP people container naming value and attribute. David wrote "I have no idea of why I had to blank out the 2 people container naming fields. I tried it because I used to have to do it in 7.0/7.1 but I have not had to do it in 8.0." The interesting thing about this tip is the values for those attributes are back. Maybe during restart, the attributes were repopulated?
So in honor of David and his bicycling ways, here is Queen with Bicycle Race, complete with footage from the bicycle race that was filmed especially for this video...back in the day. Those who were around...back in the day...might remember this footage. To you others, some quick elements are NSFW.
Thanks to OpenSSO members Christopher and Michel for this information.
OpenSSO uses an LDAP server for persistence of its configuration data so the LDAP server that contains this configuration data must be available when OpenSSO is running. After a default installation OpenDS, which is embedded with OpenSSO, will stop and start as OpenSSO does. If OpenSSO is installed pointing to an instance of Directory Server for its configuration data, Directory Server needs to be stopped and started on its own. The best way to do this is to stop the underlying OpenSSO web container first and Directory Server second - reversing the order for the imminent restart. This insures that the configuration data is always available for the OpenSSO web application.
That said, I've noticed a few people (externally and internally) asking about an Invalid Domain - No such Organization found error that is displayed when attempting to log in to the console using the default URL (http://web-server-host:port/opensso/UI/Login) after restarting an instance of Directory Server 5.2 configured as the OpenSSO configuration data store. If you see this error message, do the following:
Login to the OpenSSO console at http://web-server-host:port/opensso/UI/Login?org=LDAP-DN-root.
Under the Access Control tab, click the / (Top-level Realm).
Add another host name to the Realm/DNS Alias property of the / (Top-level Realm) and click Save. The information will be removed so MacGuffin text is fine.
Restart the deployment as previously detailed.
Login to the OpenSSO console using the default URL and remove the host name you just added.
This workaround forces OpenSSO to export the Realm/DNS Alias values to the external Directory Server. The following search returns zero results before the workaround and should return one result after it.
SRCH base="ou=services,DN" scope=2 filter="(|(&(objectClass=sunRealmService)(&(|(sunxmlkeyvalue=sunidentityrepositoryservice-sunOrganizationAliases=hostname.site.com)(sunxmlkeyvalue=sunOrganizationAliases=hostname.site.com))))(&(objectClass=sunServiceComponent)(&(|(sunxmlkeyvalue=sunidentityrepositoryservice-sunOrganizationAliases=hostname.site.com)(sunxmlkeyvalue=sunOrganizationAliases=hostname.site.com)))))" attrs="o"
While you're waiting for the restart, enjoy Stop, the ABBA-esque version of the Erasure song by Björn Again.
A number of command line interfaces originally developed for the products that have been integrated into OpenSSO have been EOL'ed. So here is some information on the new commands and options that can be used instead.
Although the legacy command line interface amadmin is still bundled with OpenSSO, certain LIberty Alliance Project Identity-Federation Framework (Liberty ID-FF) related options are no longer supported because of a change in the metadata format. Use the following ssoadm commands to import and export metadata. Be sure to append --spec idff to the command.
The command line interface saml2meta (originally developed for the Sun Java System SAMLv2 Plug-in for Federation Services) is not supported in OpenSSO. Use the corresponding ssoadm commands instead. Note that some of the new commands must have --spec saml2 appended.
import-entity with --spec saml2 option
export-entity with --spec saml2 option
create-metadata-templ with --spec saml2 option
delete-entity with --spec saml2 option
list-entities with --spec saml2 option
The command line interfaces saml2bulkfed (originally developed for the Sun Java System SAMLv2 Plug-in for Federation Services) is not supported in OpenSSO. Use the following ssoadm commands for SAMLv2 bulk federation. Be sure to append --spec saml2 to the command.
do-bulk-federation performs bulk federation.
import-bulk-fed-data imports the bulk federation data generated by the do-bulk-federation command.
The command line interface ambulkfed (originally developed for Access Manager to bulk federate using the Liberty ID-FF protocol) is not supported in OpenSSO either. The ssoadm commands that take the place of the SAMLv2 bulk federation CLI (above) can also be used for Liberty ID-FF bulk federation by appending --spec idff to the command rather than --spec saml2.
And now some new music (on this side of the pond anyway) from Alison Moyet. The Turn was just released in North America and features the single, A Guy Like You.