This blog post was first published @ www.fedji.com, included here with permission.
It’s not for no reason that I picked up ‘Whistling Down the Road’ by Silent Partner (Courtesy: Google YouTube Audio Library) as the audio background for the screen-cast embedded on this blog post. The installation of ForgeRock OpenIDM 4 is one such experience, as in like just whistling away down the road! See it to believe it and don’t forget to try it.
I’ve done a similar screen-cast before, but that’s using OpenIDM 3.x. Be wary of the fact that the software used in this screen-cast is not yet read for Production. But now that the ForgeRock Management have given us this clue on the road ahead for the ForgeRock Products, it makes sense to start exploring it (if not already done).
So in the video below, you’ll see the lightning fast installation of both OpenIDM and OpenDJ and configuration of OpenDJ as an External Resource for OpenIDM.
In the article that I’ve posted yesterday, I’ve outline portions of configuration files for OpenIG. The configuration is actually only working with the latest OpenIG nightly builds, as it leverages some of the newest updates to the code.
One of the feedback that we got after we released was that configuring OpenIG was still too complex and verbose. So, we’ve made changes to the model, simplifying it, removing intermediate objects… The result is much smaller and easier to understand configuration files, but more importantly, easier to read back and understand the flow they represents.
My colleague Mark has done a great job of describing and illustrating those changes in a few articles :
OpenIG’s improved configuration files (Part 1)
OpenIG: A quick look at decorators
OpenIG’s improve configuration files Part 2
Filed under: Identity Gateway
, ease of use
If you want to create a custom OpenAM auth module or a service, then you probably going to end up writing a configuration XML. This XML describes to OpenAM what kind of UI elements to render on the admin console, and what values should be stored in the configuration store for the given module.
Let’s take a look at the following sample XML:
<?xml version="1.0" encoding="UTF-8"?>
PUBLIC "=//iPlanet//Service Management Services (SMS) 1.0 DTD//EN"
<Service name="sunAMAuthMyModuleService" version="1.0">
<SubSchema name="serverconfig" inheritance="multiple">
What you should know about authentication module service XMLs:
- According to this piece of code the service name HAS to start with either iPlanetAMAuth or sunAMAuth, and HAS to end with Service (like sunAMAuthMyModuleService in our case)
- the serviceHierarchy attribute is /DSAMEConfig/authentication/<service-name>
- in the i18nFileName attribute you need to add the name of a properties file, which is on OpenAM classpath (like openam.war!WEB-INF/classes). This internationalization file will be used by OpenAM to lookup the i18nKeys for the various items in the XML.
- You should put the module options into an Organization Schema, this will make sure that the module will be configurable per realm.
- All the attribute schema definitions should be also listed under a SubSchema element (this will allow you to set up two module instances based on the same module type with different configurations).
The AttributeSchema element contains informations about a single configuration item (what name should OpenAM use to store the parameter in the configstore, what kind of UI element needs to be rendered, what restrictions does the attribute have, etc).
Available types for an attribute:
- single -> singlevalued attribute
- list -> multivalued attribute
- single_choice -> radio choice, only one selectable value
- multiple_choice -> checkboxes, where multiple item could be selected
- signature -> unknown, possibly not used
- validator -> if you want to use a custom validator for your attribute, you need to include the validator itself (beware of OPENAM-974).
Available uitypes for an attribute:
- radio -> radiobutton mostly for displaying yes-no selections
- link -> this is going to be rendered as a link, where the href will be the value of the propertiesViewBeanURL attribute
- button -> unknown, not used
- name_value_list -> generates a table with add/delete buttons (see Globalization settings for example)
- unorderedlist -> a multiple choice field in which you can dynamically add and remove values. The values are stored unordered.
- orderedlist -> a multiple choice field in which you can dynamically add and remove values. The values are stored ordered.
- maplist -> a multiple choice field in which you can add/remove key-value pairs
- globalmaplist -> same as maplist, but it allows the key to be empty.
- addremovelist -> basically a palette where you can select items from the left list and move them to the right list
Available syntaxes for an attribute:
- boolean -> can be true or false
- string -> any kind of string
- paragraph -> multilined text
- password -> this will tell the console, that it should mask the value, when it’s displayed
- encrypted_password -> same as the password syntax
- dn -> valid LDAP DN
- numeric -> its value can only contain numbers
- number_range -> see rangeStart and rangeEnd attributes
- decimal_range -> see rangeStart and rangeEnd attributes
NOTE: Some of these syntaxes aren’t really used within the product, so choose it wisely.
Other than these, there is also the i18nKey attribute, which basically points to i18n keys in the referred i18nFile configured for the service. This is used when the config is displayed on the admin console.
This should cover the basics for authentication module service configuration I think.