Friday Jan 08, 2010

Born To Change a Configured OpenSSO Host Name

After opensso.war is deployed in a web container, the installed OpenSSO instance is uniquely identified by a URL defined with a protocol (http/https), a host name, a port and a deployment URI; for example, This URL is defined in the OpenSSO bootstrap file as well as in various places in the service configuration data store.

When the web container on which OpenSSO is deployed is restarted, OpenSSO uses the bootstrap URL to locate its system properties in the service configuration data store and start itself. Additionally, almost all federation and web services endpoints contain this URL. Thus, to change the host name on which the instance of OpenSSO has been installed, use the first procedure in this entry. The second procedure documents how to restore the previous host name.

To Change the OpenSSO Host Name
To Restore the Previous Configuration

To Change the OpenSSO Host Name

For this example procedure, assume the current OpenSSO URL is, and the new OpenSSO URL will be
  1. Login to the OpenSSO console as administrator; by default, amadmin.
  2. Click the Access Control tab.
  3. Click / Top Level Realm.
  4. Add the new host name as a value for the Realm/DNS Aliases attribute. For example,
  5. Export the service configuration data to a file named export.xml.
    See Backing Up and Restoring Configuration Data for information.
  6. Copy export.xml to new.xml.
  7. Open new.xml and make the following changes.
    1. Search for <SubConfiguration name=”” id=”server”> and:
      • Change <Value></Value> to <Value></Value>
      • Change <Value></Value> to <Value></Value>
      • Change <Value></Value> to <Value></Value>
    2. Search for <Service name=”iPlanetAMAuthConfiguration” version=”1.0”><Schema i18nFileName=”amAuthConfig” i18nKey=”iplanet-am-auth-config-service-description” propertiesViewBeanURL=”opensso/auth/ACServiceInstanceList”> and change opensso to opensso1.
    3. Search for <SubSchema inheritance=”multiple” maintainPriority=”no” name=”NamedConfiguration” supportsApplicableOrganization=”no” validate=”yes”><AttributeSchema cosQualifier=”default” i18nKey=”a101” isSearchable=”no” name=”iplanet-am-auth-configuration” propertiesViewBeanURL=”opensso/auth/ACModuleList”> and change opensso to opensso1.
    4. Search for <AttributeSchema cosQualifier=”default” i18nKey=”a133” isSearchable=”no” name=”iplanet-am-auth-login-success-url” syntax=”string” type=”list”><DefaultValues><Value>/opensso/console</Value> and change opensso/ to opensso1/.
    5. Search for <AttributeValuePair><Attribute name=”sunOrganizationAliases”/><Value>opensso</Value> and change opensso to opensso1.
    6. Search for <AttributeSchema cosQualifier=”default” i18nKey=”a103” isSearchable=”no” name=”iplanet-am-platform-cookie-domains” syntax=”string” type=”list”><DefaultValues><Value></Value> and change the cookie domain from to
    7. Substitute the following strings:
      • for
      • for
  8. Save new.xml.
  9. Backup the OpenSSO configuration data.
    This backup can be used to restore a previous configuration. If the OpenSSO configuration data store is the default embedded OpenDS, backup the contents of OpenSSO-ConfigDir. OpenSSO-ConfigDir represents the name of the directory specified during initial configuration of OpenSSO as the configuration directory. By default, an opensso directory would be created in the home directory of the user configuring the instance. Thus, if root is configuring the instance, OpenSSO-ConfigDir is /opensso. If any other directory server is used, work with the administrator to back up the OpenSSO configuration data before proceeding.
  10. Import new.xml back into OpenSSO.
    See Backing Up and Restoring Configuration Data for information.
  11. Stop the web container.
  12. Replace with in the OpenSSO-ConfigDir/bootstrap file.
    During OpenSSO deployment, a setup servlet creates a file named bootstrap in the OpenSSO configuration directory. This file contains the information that points to a location from which OpenSSO can retrieve configuration data to bootstrap itself. For more information on this file, see The OpenSSO Bootstrap File Deconstructed.
  13. Change the deploy context on the OpenSSO web container to opensso1.
    Check the your web container's documentation for instructions.
  14. Move OpenSSO-ConfigDir/opensso to OpenSSO-ConfigDir/opensso1.
    Be sure to backup this directory first.
  15. Change to the user-home/.openssocfg directory.
    A file named with the prefix AMConfig is in this directory; for example, AMConfig_usr_local_tomcat_webapps_opensso or AMConfig_opt_jboss-4.2.2.GA_server_fam2_._deploy_opensso.war_. user-home is the home directory of the user who configured the instance of OpenSSO.
  16. Change opensso in the AMConfig\* file to opensso1.
  17. Start the web container.
  18. Log in to OpenSSO using the new URL (and host name) as amadmin.
  19. Click the Access Control tab.
  20. Click / Top Level Realm.
  21. Remove, the old host name, from the Realm/DNS Aliases attribute.

To Restore the Previous Configuration

This procedure is based on the examples and information used in the previous procedure.

  1. Edit OpenSSO-ConfigDir/bootstrap by changing the new encoded URL back to the old encoded URL.
  2. Import export.xml back into OpenSSO.
  3. Change the deploy context on the OpenSSO web container back to opensso.
  4. Move OpenSSO-ConfigDir/opensso1 to OpenSSO-ConfigDir/opensso.
  5. Change opensso1 in the AMConfig\* file (located in the user-home/.openssocfg directory) back to opensso.
  6. Restart the web container.

Now enjoy Patrick Hernandez's one hit Born to Be Alive.

Tuesday Apr 28, 2009

Sweet Soul Revue-ing 'Organizing Data in an OpenSSO Realm'

Notwithstanding Maybe You'll Know: Logging in to the OpenSSO Console, here's another chapter from the Sun OpenSSO Enterprise 8.0 Administration Guide that has been rewritten and wiki-ized.

Organizing Data in a Realm basically takes you through the tabs that are used to configure data in a realm - everything under the Access Control tab. The simpler sections are complete in this entry while the more complex sections link to chapters on (until these chapters are also formatted for wiki).

So what's missing? Is the information organized as you might look for it when using the console? When you read a section are you wanting further information for which there is no link? Remember this is administration information when you read it - not coding or customization.

Thoughts? Comment here or on the wiki.

Coming up: Managing Authentication Using Realms

Sweet Soul Revue is a great pop song from the Japanese band, Pizzicato Five. I had a bunch of P5 albums in the 90s although I never quite knew what most of the lyrics were about. Still got me up on the dance floor!

Monday Apr 27, 2009

Maybe You'll Know: 'Logging In To The OpenSSO Console' Review

Over the next few months, the OpenSSO writer's team will be moving our deliverables from to our new documentation wiki.

I've started rewriting chapters from the Administration Guide to close a myriad of issues filed against the book so I decided to put the wiki URLs with the new text out for public review and comments. Click to read the first (albeit simple) chapter, Logging In To The OpenSSO Console.

I envision the information in Logging In To The OpenSSO Console as an explanation of the login process and what the user might see after logging in. What I am looking for from the reviewers is what other console-related infomration might be worth mentioning. This would only be from an administration/interface perspective. This is not the chapter to refer to customizing the console as that would most likely have already been done by the time an administrator begins to log in.

Thoughts? Comment here or on the wiki.

Coming later this week: Chapter 2: Organizing Data Within Realms

In the meantime, here's Cyndi Lauper as lead singer of Blue Angel performing Maybe He'll Know. She's a charmer!




« February 2017