Monthly Archives: June 2012

OpenAM: Self-Registration with the Membership Auth Module

OpenAM Community LogoLetting users self-register with OpenAM is straightforward. Basically, you set up the Membership authentication module, and then point users to it by specifying the module as one of the query string parameters in your URL to OpenAM.

To configure the Membership authentication module to allow self-registration, follow these steps.

  1. Log in to OpenAM web-based console as amadmin.
  2. Browse to Access Control > Realm Name > Authentication > Module Instances.
  3. Click New to add a new authentication module.
    Name: SelfReg
    Type: Membership
  4. Click OK to save your work.
  5. Log out of OpenAM console in order to try self-registration.

To try self-registration through the Membership authentication module, follow these steps.

  1. Browse to log in to OpenAM, adding the realm and SelfReg module in the query string, such as http://openam.example.com:8080/openam/UI/Login?module=SelfReg&realm=/
  2. Click New User.
    self-reg-home
  3. Enter the new user details on the Self Registration page, and then click Register.
    self-reg-user
  4. Agree to the disclaimer (which can be customized for your site).
  5. Check your new user page in OpenAM, and then log out when you are done.

4 Comments

Filed under Access Management

Docs: Folding review into the normal dev process?

ForgeRock Community Logo Perhaps you have read the recent updates to the community development process page. In a nutshell there’s a push to doing review-then-commit rather than the other way around.

As I described earlier, we currently use a doc-specific review process to ensure technical accurate and complete core docs at the time of release. The doc review process sits alongside the standard development process, and so requires a bit of extra work in management and tracking. Also, as long as the doc review process sits outside the main development process it will not be as easy to track as the rest of the work.

Should we fold the doc review process into the normal development process?

Review-then-commit certainly promises to reduce the additional workload in tracking and managing dev review. In theory if we manage to commit content that is ready for validation testing at the same time as the code it should ease the burden on people doing testing and validation. Perhaps testers will not have to switch context back to features studied much earlier. They might even find the doc useful when working with new features.

The downsides don’t seem insurmountable. Design review, really part of product definition, still needs to be tracked separately. But once design review is done, it can result in JIRA issues that we handle like the rest of the work. For validation testing, quality assurance might prefer that writers track coverage. Or perhaps that will be part of the test plan. Either way seems fine as long as the work is not falling through any cracks. There are also a few documentation updates where IMHO review-then-commit is just overkill. Commit-then-review is no doubt the best approach when fixing typos, for example. Commit-then-review might also be best for editorial fixes and indexing, too.

So I’m tentatively guessing that although it is a significant shift from what we have done so far, folding doc review into the normal dev process will improve quality and save effort. I’ll be trying to stick closer to the standard development process starting with OpenAM 10.1.0 (and associated policy agent and OpenIG docs).

What do you think?

Leave a Comment

Filed under Docs

OpenAM: Permanent Links Between Federated Accounts

OpenAM Community LogoIn reading about SAML 2.0, I see SAML 2.0 federation does not require any sort of permanent or even persistent connection between accounts at the identity provider and the service provider. If however you do want to make permanent connections for a list of identity provider and service provider accounts, then the ssoadm bulk federation commands can help.

Before You Start

Before you can run the bulk federation commands, first establish the relationship between accounts, and also set up the providers including installation of the ssoadm command.

Consider a case where the identity provider is at idp.example.org and the service provider is at sp.example.com. A demo user account has the Universal ID, id=demo,ou=user,dc=example,dc=org, on the identity provider. That maps to the Universal ID, id=demo,ou=user,dc=example,dc=com, on the service provider.

The ssoadm command then needs a file that maps local user IDs to remote user IDs, one per line, separated by the vertical bar character |. Each line of the file looks like this:

local-user-ID|remote-user-ID

In this example, starting on the service provider side, the line for the demo user reads:

id=demo,ou=user,dc=example,dc=com|id=demo,ou=user,dc=example,dc=org

All the users’ accounts mapped in your file must exist at the identity provider and the service provider when you run the commands to link them.

See the OpenAM Installation Guide for details on installing OpenAM and the ssoadm command. The OpenAM Administration Guide describes how to create hosted providers and register remote providers.

Linking Federated Accounts in Bulk

After everything is set up, you can link the accounts using the ssoadm bulk federation commands.

  1. Prepare the data with the ssoadm do-bulk-federation command.
    This example starts on the service provider side.

    $ cat /tmp/user-map.txt
    id=demo,ou=user,dc=example,dc=com|id=demo,ou=user,dc=example,dc=org
    $ ssoadm do-bulk-federation --metaalias /sp \
     --remoteentityid http://idp.example.org:8080/openam \
     --useridmapping /tmp/user-map.txt \
     --nameidmapping /tmp/name-map.txt \
     --adminid amadmin --password-file /tmp/pwd.txt \
     --spec saml2
    
    Bulk Federation for this host was completed. To complete the
    federation, name Id mapping file should be loaded to remote
    provider.
  2. Copy the name ID mapping output file to the other provider.
    $ scp /tmp/name-map.txt idp.example.org:/tmp/name-map.txt
    openam@idp.example.org's password: 
    name-map.txt                     100%  177     0.2KB/s   00:00
  3. Import the name ID mapping file with the ssoadm import-bulk-fed-data command.
    In this example, this step takes place on the identity provider side.

    $ ssoadm import-bulk-fed-data \
     --adminid amadmin --password-file /tmp/pwd.txt \
     --metaalias /idp --bulk-data-file /tmp/name-map.txt 
    
    Bulk Federation for this host was completed.

The accounts are now linked.

Leave a Comment

Filed under Access Management, Tools

ForgeRock welcomes Vanessa Richie

ForgeRock Community LogoA warm if belated welcome to Vanessa Richie, who joined us at ForgeRock last week! As you might have noticed on the OpenAM commit list, Vanessa has already started to fix issues in the OpenAM docs.

Vanessa brings years of experience as a writer to the ForgeRock team. She also brings a fresh eye to spot and correct problems in the documentation, especially problems affecting newcomers to the community. Vanessa’s familiarity with Windows should prove helpful as well as we reach out to those of you who can sometimes work for days without opening a terminal window.

Vanessa’s first focus is ForgeRock’s access management documentation, so you are sure to see her more and more involved in covering OpenAM, policy agents, and OpenIG. Very glad that Vanessa has decided to join ForgeRock.

Leave a Comment

Filed under Access Management, Docs

DocBook XSL: A floating, set-level TOC?

DocBook logoOne of Google’s summer of code projects this year involves work on the webhelp stylesheets. You can make nice looking output with webhelp.

Last time I tried webhelp, it worked with book-sized pieces, however, rather than set-sized pieces. Looking at an issue in my list, I see that a sufficient solution would be a floating, hideable, left-menu, <set>-level table of contents.

I’m imagining separate HTML (one for single-page output, one for chunked) that gets pulled in on the client side. Who has already done this using the open source stylesheets? (Maybe starting with the olink database?)

Leave a Comment

Filed under Docs, Tools

Decoding SAML Messages

SimpleSAMLPHP logoPeter Major mentioned the SAML 2.0 Debugger to me a while ago. It’s a helpful tool when trying to understand what’s happening when you are playing with a Fedlet, for example.

If you notice SAML messages, for example in a POST URL, and want to decode something like SAMLRequest=nVRNj9owEL3vr4h8h4QAgVqAREFVkbbdLKE99DZxJl1Lju3azkL%2Ffe1sFlHtilacLD1PZt7HOAsLjdB03bonucdfLVoXRadGSEu7myVpjaQKLLdUQoOWOkaL9Zd7mg4Tqo1yiilB7nbbJbHpqK7LEifZeArpZIrJvJ7OsBwBZvNsBmU5%2FpDMYDxhJPqOxnIll8S3IdHO2hZ30jqQzkPJKB0k2SCZHEYZTUY0zX6QaOupcQmu%2B%2BrJOU3jWGn0pIZ4gkYLHDLV0HkyT3o8LoqHPVbcIHNxgw7WgoONeaVJ9EkZhp3qJalBWAwkcrCWP%2BMZyXt5H7msuPx53YvypcjSz4dDPsgfigOJ1taiCYw3Stq2QVOgeeYMv%2B3vzxqOx%2BNbATVWAl1%2FgNaCs045Wd0tQi60c8xcJHWdHLwSIat%2Fj13EFyP6gZp%2B9U1321x5Kr9vWZFgeQPuenVAeDWou1LqDEjLUToSFXmY%2F9iC4DVH8z%2FuefuFUMeNQXA%2BU2daJKsXbX%2BrOUvsHwBW3WL4zBye3C1SN6rRYLgNq%2BrZMecHd55eNt4In8oe61tCvFrGKAutPRwW%2BqhMFRbZPwKsDsFRrcxrxu%2FxOXv0rh3erPjtP2P1Bw%3D%3D, copy the value and paste it into the SAML 2.0 Debugger, then click Decode SAML message:

<samlp:AuthnRequest  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="s21ffbbe4635a245e08f57eb1ae6867abb3907a34c" Version="2.0" IssueInstant="2012-06-04T16:01:26Z" Destination="http://openam.example.com:8080/openam/SSORedirect/metaAlias/idp" ForceAuthn="false" IsPassive="false" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="http://www.example.com:8080/fedlet/fedletapplication">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://www.example.com:8080/fedlet</saml:Issuer>
<samlp:NameIDPolicy  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" SPNameQualifier="http://www.example.com:8080/fedlet" AllowCreate="true"></samlp:NameIDPolicy>
<samlp:RequestedAuthnContext xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Comparison="exact"><saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

Still a bit complex, but a lot easier to read than the version above. :-)

1 Comment

Filed under Access Management, Tools

docbkx-tools: Testing DocBook XSL 1.77.0

docbkx-tools logo DocBook XSL 1.77.0 has been out for a couple of weeks. I have not found anything unexpected, yet.

ForgeRock core docs have three layers to build between the stylesheets and the docs that use forgerock-doc-maven-plugin. Here is what I did in order to enable testing:

  1. Get the DocBook Maven project, https://docbook.svn.sourceforge.net/svnroot/docbook/trunk/maven, update the versions to pull the latest stylesheets, and mvn install a local copy.
    $ svn diff
    Index: docbook-xsl/pom.xml
    ===================================================================
    --- docbook-xsl/pom.xml	(revision 9386)
    +++ docbook-xsl/pom.xml	(working copy)
    @@ -5,7 +5,7 @@
       <artifactId>docbook-xsl</artifactId>
       <name>DocBook XSL Stylesheets</name>
       <packaging>pom</packaging>
    -  <version>1.76.1</version>
    +  <version>1.77.0</version>
       <description>These are XSL stylesheets for transforming DocBook XML document instances into various output formats.
       </description>
       <url>http://sourceforge.net/projects/docbook/</url>
    @@ -18,8 +18,8 @@
    
       <properties>
    -    <docbook.xsl.release>docbook-xsl-1.76.1</docbook.xsl.release>
    -    <docbook.xslns.release>docbook-xsl-ns-1.76.1</docbook.xslns.release>
    +    <docbook.xsl.release>docbook-xsl-1.77.0</docbook.xsl.release>
    +    <docbook.xslns.release>docbook-xsl-ns-1.77.0</docbook.xslns.release>
       </properties>
    
       <build>
  2. Get docbkx-tools, http://docbkx-tools.googlecode.com/svn/trunk, update the stylesheet version, and mvn install a local copy.
    $ svn diff
    Index: docbkx-maven-plugin/pom.xml
    ===================================================================
    --- docbkx-maven-plugin/pom.xml	(revision 258)
    +++ docbkx-maven-plugin/pom.xml	(working copy)
    @@ -62,7 +62,7 @@
         <dependency>
           <groupId>net.sf.docbook</groupId>
           <artifactId>docbook-xsl</artifactId>
    -      <version>1.76.1</version>
    +      <version>1.77.0</version>
           <type>zip</type>
           <classifier>ns-resources</classifier>
         </dependency>
  3. Get forgerock-doc-maven-plugin, https://svn.forgerock.org/commons/forgerock-doc-maven-plugin/trunk, update the docbkx-tools version, and mvn install a local copy.
    Update: Thanks to Chris Ridd. Also need to change AbstractBuildMojo.java as shown.

    $ svn diff
    Index: src/main/java/org/forgerock/doc/maven/AbstractBuildMojo.java
    ===================================================================
    --- src/main/java/org/forgerock/doc/maven/AbstractBuildMojo.java	(revision 311)
    +++ src/main/java/org/forgerock/doc/maven/AbstractBuildMojo.java	(working copy)
    @@ -32,7 +32,7 @@
          * Docbkx Tools plugin version to use. Executions seem to hit an NPE when
          * the version is not specified.
          *
    -     * @parameter default-value="2.0.14" expression="${docbkxVersion}
    +     * @parameter default-value="2.0.15-SNAPSHOT" expression="${docbkxVersion}
          * @required
          */
         private String docbkxVersion;
    Index: pom.xml
    ===================================================================
    --- pom.xml	(revision 312)
    +++ pom.xml	(working copy)
    @@ -61,7 +61,7 @@
      </licenses>
    
      <properties>
    -  <docbkxVersion>2.0.14</docbkxVersion>
    +  <docbkxVersion>2.0.15-SNAPSHOT</docbkxVersion>
       <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
       <maven.compiler.target>1.6</maven.compiler.target>
       <maven.compiler.source>1.6</maven.compiler.source>
  4. Use your local Maven installation to build your test documentation.

Leave a Comment

Filed under Docs, Tools