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.
Run jps at the command line.
This is the command for discovering running Java processes.
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!
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 Ping
AIX for WebSphere only
Geronimo for Solaris only (Geronimo can install Jetty AS and Tomcat AS; FAM supports only TomCat)
Directory servers as user stores
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 Dennis
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 AMConfig.properties 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 AMConfig.properties 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
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.
famadm CLI using subcommands such as:
list-server-cfg is to list the configuration of an server instance
remove-server-cfg is to remove a configuration’s property values
update-server-cfg is to set configuration’s property values
Bootstrapping FAM Dennis
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 Dennis
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 AMConfig.properties. In the absence of code>AMConfig.properties, famadm retrieves server configuration from the centralized depository.
Unzip famAdminTools.zip in temporary directory on server where FAM is hosted and type setup with a value for the installation directory of FAM server
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: http://samples.com:58080/fam/famadm.jsp) 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.
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
create and update datastores (also can be done from console)
export-server and import-server options: exports only properties that had been stored in the late and lamented AMConfig.properties 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
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 Hua
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
AMAgent.properties still exists but has fewer properties - only local bootstrap data Additional info will be stored locally in AMAgentConfiguration.properties (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
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)
Auth calls IdRepo which calls SMS which checks username and PW in Centralized Agent Config data (under FAM config data root)
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 Mrudul
Security Token Service
Web Services Security (API, Framework, Plug-ins) securing client web services, add plug-in without config(?)
Common Tasks Jon
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)
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)
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 stored...um...all 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 opends.zip, 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 AMConfig.properties during setup. But from OpenSSO build 2, AMConfig.properties 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.