Monday Apr 07, 2008

Conquering LDAP Redeploy Errors By Using Them Up and Wearing 'Em Out

The lab machines reserved for us writers are none-too-current: hard drive size and RAM are not the correct specifications for deploying Glassfish, OpenSSO, and other agents/web services. Because of this I always have issues re-deploying a new OpenSSO WAR file successfully...until today (actually Friday but I'm writing this today).

When I undeploy the OpenSSO WAR, it leaves some processes running on Glassfish which don't allow for a new WAR to be deployed. (I've seen mainly LDAP and OpenDS errors.) I figured out that I can redeploy a new OpenSSO WAR if I have a new install of Glassfish - which puts the step where I have to jumpstart and wait for a new OS to be installed (and therefore wait for the lab guy to restart the DNS) in the trash. So follow this procedure to find the processes, kill them, uninstall Glassfish, and get it back up.

  1. Run jps at the command line.
    This is the command for discovering running Java processes.
  2. Kill any PELaunch processes you see using the kill -9 process-number command on the command line.
  3. Remove the glassfish directory.
  4. Start all over again using this blog entry.

Voila, I got the whole shebang up and running again. Not too pretty but it works.

And here is something else that works: a cover of (the late 70s dance group) Odyssey's excellent tune Use It Up and Wear It Out by early 90s disc jockeys Pat & Mick - as produced by PWL. Shake your body down!

Monday Feb 04, 2008

Federated Access Manager TOI, Session 1

There is a point in the timeline of a software release where engineers deliver what those in the 'biz' call a TOI or transfer of information. Engineers put together slide decks and spend a few hours telling anyone who will listen what to expect from the upcoming release. Each presentation ends with a question and answer session from the interested parties (documentation writers, QA engineers, training, development engineers, etc.). Today we had the first session for the Federated Access Manager 8.0 TOI and here are my notes.

Supported Software
  • Operating Systems
    • Solaris
    • Linux
    • Windows
    • AIX for WebSphere only
  • Containers:
    • Sun WS
    • Sun AS
    • WebLogic
    • WebSphere
    • Oracle AS
    • JBoss
    • Tomcat
    • Geronimo for Solaris only (Geronimo can install Jetty AS and Tomcat AS; FAM supports only TomCat)
  • Directory servers as user stores
    • Sun DS
    • AD
    • IBM Tivoli DS
Installation and Configuration
Ping, Jon
  • FAM server bits require JDK 1.5 or higher
  • Client of FAM requires JDK 1.4 or higher
  • Single WAR deployment
  • Configuration Wizard guides the users through a seven (or so) screen installation process; it replaces the one page configurator.jsp

Centralized Server Configuration Data
  • An embedded directory server offers centralized server configuration data management
    Previously each configured instance of the product had it's own server configuration data stored local to the server product in and serverconfig.xml. Now each FAM instance has its own branch in an instance of an embedded data store offering ease in managing multiple instances of FAM. Embedded data store can be Sun Directory Server or open source OpenDS. The latter is installed with FAM8.
  • A FAM instance's service configuration data properties used to be stored in and serverconfig.xml. They are now stored in the centralized data store under a sub-configuration of the Platform Service branch.
  • Modify centralized server configuration data using
    1. FAM console: under Configuration -> Sites & Servers click on the appropriate name/hyperlink from the list of servers displayed to view and edit the centralized server configuration data.
    2. famadm CLI using subcommands such as:
      1. list-server-cfg is to list the configuration of an server instance
      2. remove-server-cfg is to remove a configuration’s property values
      3. update-server-cfg is to set configuration’s property values
Bootstrapping FAM

WAR points to bootstrap file which points to centralized server configuration data store which holds bootstrapping data that is retrieved for bootstrapping process

famadm CLI
  • amadmin CLI will ship for two more releases only; over this time will be deprecated and replaced by famadm CLI
  • famadm CLI supports all commands of amadmin
  • famadm still works with In the absence of code>, famadm retrieves server configuration from the centralized depository.
  • Installation
    1. Unzip in temporary directory on server where FAM is hosted and type setup with a value for the installation directory of FAM server
    2. Must be setup for each instance of FAM - no global properties (although, in general, all global properties are reproduced in the instance service configuration data)
  • amAdmin password must always be in a separate file and pointed to during CLI input
  • Legacy DITs can use famadm CLI
  • If you don't specify -protocol option - defaults to SAMLv2
  • DON'T DOCUMENT: there is also a web-based CLI purely for internal usage that will not be supported for release (ie:
    I don't believe the fact that I am mentioning this web-based CLI here is documenting. If it is, I'm sure I'll hear about it.
  • New subcommands
    1. backup and restore server configuration data by exporting from DS to file or importing file to DS; SMS info that is exported here is global to FAM
      encryptsecret option, used for purposes of export and import, takes any string and is stored only in the head of the person who entered it - NOT part of service configuration data
    2. create and update datastores (also can be done from console)
    3. export-server and import-server options: exports only properties that had been stored in the late and lamented and serverconfig.xml; server config data that is exported here is per FAM instance
  • famadm is used for agent config

  • Secure Attribute Exchange
  • New SAML2 profiles (ECP, AttributeQuery, AuthnQuery, X509 Profile, IDP Proxy, ...) all should be supported by the time of release
  • WS-Federation
  • SSO/SLO across multiple protocols
  • Bulk Federation preassigns a name identifier for a list of users at both ends of federation transaction
    Only for IDFF or SAML2
    AM71 is PERL-based; FAM 8 is Java-based
Centralized Agent Management and Agent 3.0
  • Agent install/uninstall via agentadmin CLI packaged with agent ZIP/WAR and installed on agent server
  • Centralized agent management - agent config data is now in service config store not IDRepo store (Data Stores) which was under realm tab - now under Configuration tab
  • still exists but has fewer properties - only local bootstrap data
    Additional info will be stored locally in (local configuration data) while embedded server configuration data store will hold centralized configuration data
  • Support local config for backward compatibility and centralized config
    Benefit of choosing local config - 2.2 agent customers deploy FAM8; agents are sometimes controlled by org's partners and thus they can have local control over centralized org control
    1. Agent starts up and reads local bootstrap properties and gets Naming URL and makes call to Auth Service (agent needs to authenticate to server first)
    2. Auth calls IdRepo which calls SMS which checks username and PW in Centralized Agent Config data (under FAM config data root)
    3. Gets SSOToken then returns to agent config data to get agent's config data location (local or central depending on config of agent)
    NOTE: Find out about Attribute service on Wednesday (REST)
  • agent config hot swapping - if property is hot swappable and I change the value of it during runtime the value changes on the fly
  • can enable notification and polling
  • agent grouping - share common config properties among multiple agent instances (ease of mngt feature)
  • no admin specific to agents (like policy and amadmin)
  • agent upgrade - new feature that automates the upgrade process

Web Services Security

  • Security Token Service
  • Web Services Security (API, Framework, Plug-ins) securing client web services, add plug-in without config(?)

Common Tasks
  • New tab in console to access feature setup wizards (aka workflows) for easy customer configuration
  • Initial tasks are federation-based (supports SAML2 currently; will support IDFF by release)
    • Simplified IDP/SP setup (minimal customer input, can take input from URL or file)
    • COT setup
    Wizrds also offer SSO verification between IDP and SP


  • 6.3 console is no longer available for legacy mode install; only Directory Management tab will show up for legacy support (Jon)
  • Identity Services - ???
  • 3rd Party Integration
    • FAM + CA's SiteMinder (SSO, Federation)
    • FAM + Oracle's Access Manager

Tuesday Jan 15, 2008

OpenSSO & OpenDS Sitting in a Tree, K-I-S-S...

In case you hadn't noticed, OpenSSO build 2 (the soon-to-be christened Federated Access Manager) now stores its configuration data in a data store rather than a flat file. OpenDS is the new embedded configuration store, replacing the previous flat file implementation where configuration files were over the place (okay, there was sms). Now, OpenDS is installed with OpenSSO and the configuration data is stored.

The installed version of OpenDS is not complete (for example, the bin scripts have been removed to make the opensso.war as small as possible). But you can always download, explode it and point the script parameters to the configuration directory (config_dir_specified_in_configurator/opends). This will most probably change as the OpenDS builds stabilize.

Some things based on this move have already changed. For example, famadm is a utility that lets you manage your OpenSSO installation from the command line. When famadm was developed you needed to point to during setup. But from OpenSSO build 2, is now stored in an instance of OpenDS. So during setup you need to point famadm to a bootstrap file named, appropriately enough, bootstrap. bootstrap is located under the directory defined during configuration as the Configuration Directory.

The concept is that the CLI will read the bootstrap file, contact OpenDS, fetch the appropriate properties, and bootstrap itself.

So to bring it full-circle, and to tout what I will be doing on my long holiday weekend (which starts as soon as I publish this entry), here's KISS.




« July 2016