OpenIG’s improved configuration files, part II

openig-logoGuillaume, Matt, and Violette’s recent work has made OpenIG configuration a lot easier to read and write. To try this at home, grab the latest nightly build of OpenIG. (The changes in the server are backwards compatible, too, so you don’t have to move right away. But you will want to.)

Imagine that you are working with OpenIG 3.0.0, debugging one of your basic routes. You want to capture requests and responses going through your route to see what is going on. Your route definition looks something like this:

{
    "heap": {
        "objects": [
            {
                "name": "LoginChain",
                "type": "Chain",
                "config": {
                    "filters": [
                        "CaptureFilter",
                        "LoginRequest"
                    ],
                    "handler": "ClientHandler"
                }
            },
            {
                "name": "CaptureFilter",
                "type": "CaptureFilter",
                "config": {
                    "file": "/tmp/gateway.log"
                }
            },
            {
                "name": "LoginRequest",
                "type": "StaticRequestFilter",
                "config": {
                    "method": "POST",
                    "uri": "http://www.example.com",
                    "form": {
                        "username": [
                            "george"
                        ],
                        "password": [
                            "costanza"
                        ]
                    }
                }
            },
            {
                "name": "ClientHandler",
                "type": "ClientHandler",
                "config": {}
            }
        ]
    },
    "handler": "LoginChain"
}

Fast forward to last night’s build of OpenIG, taking into account Guillaume’s inlining and capture decorator, Violette’s removal of empty “config” settings, Matt’s streamlining of the “heap” when not necessary and updates to the way decorations can be done.

Here is that same route, seriously improved.

{
    "handler": {
        "type": "Chain",
        "config": {
            "filters": [
                {
                    "type": "StaticRequestFilter",
                    "config": {
                        "method": "POST",
                        "uri": "http://www.example.com",
                        "form": {
                            "username": [
                                "george"
                            ],
                            "password": [
                                "costanza"
                            ]
                        }
                    }
                }
            ],
            "handler": {
                "type": "ClientHandler"
            }
        }
    },
    "capture": "all"
}

Well, almost the same route. You now capture requests and responses at many more points in the flow.

Notice that the very first thing in the configuration is the “handler” that produces a response.

The “Chain” is much easier to read, too.

When you start writing scripts or get stuck with a complex configuration, add a “CaptureDecorator” definition with "captureExchange": true for even more debugging information at each capture point.

You can now go utterly minimalist in your default route, assuming you define a “ClientHandler” in the top-level config.json file.

{ "handler": "ClientHandler" }

For more on what’s happening in the configuration and around OpenIG, see the draft, in-progress What’s New chapter of the release notes.

1 Comment

Filed under Access Management

OpenIDM: Trying the new Admin UI

openidm-logo One of the cool features in the upcoming release of OpenIDM is the new Admin UI. Jake Feasel demonstrated this to several people last week. It already looks like a major improvement for newbies over editing configuration files.

If like me you have been out of the loop for a while, it is reassuring to see that OpenIDM still installs a dream when you are just getting started. Download, unzip, and ./startup.sh.

Here is how you might start OpenIDM with an existing sample. This uses sample2, which is one-way synchronization with OpenDJ. You are not required to start with the samples, but they can quickly bootstrap your evaluation, without requiring you to read much doc or to think through the initial configuration.

$ cd /path/to && mv ~/Downloads/openidm . && cd openidm
$ ./startup.sh -p samples/sample2
Executing ./startup.sh...
Using OPENIDM_HOME:   /path/to/openidm
Using PROJECT_HOME:   /path/to/openidm/samples/sample2
Using OPENIDM_OPTS:   -Xmx1024m -Xms1024m
Using LOGGING_CONFIG: -Djava.util.logging.config.file=/path/to/openidm/samples/sample2/conf/logging.properties
Using boot properties at /path/to/openidm/samples/sample2/conf/boot/boot.properties
OpenIDM version "3.1.0-RC3-SNAPSHOT" (revision: 4297) jenkins-OpenIDM-3746 null
-> OpenIDM ready

OpenIDM’s web based UI is ready for HTTPS out of the box, but it seems you can still use HTTP for evaluation.

For example, you can visit http://localhost:8080/openidmui/ and login as openidm-admin:openidm-admin.

OpenIDM’s UI helps prevent default passwords by prompting you to change your password the first time you login.

openidm-first-login

You find the Admin UI at http://localhost:8080/admin/. This shows the view when running with the sample2 configuration.

openidm-admin-home

The new Admin UI offers a wizard-like approach to setting up provisioning. If you follow sample2, set up OpenDJ with some sample data before you get started. The sample comes with a mapping from OpenDJ accounts to managed/user.

openidm-add-properties

The sample also comes with a configuration for what to do in different situations during synchronization. Most of the policies are defaults.

openidm-sync-config

To run reconciliation and synchronize your source and target, either click the Reconcile Now or schedule reconciliation on the Sync Tab of the Mappings page. When reconciliation completes, you should have a bunch of new managed users. If you schedule reconciliation, subsequent runs might not encounter any changes.

openidm-recon

Click the User View link at the upper left of the page and then the Users tab to view all your managed users.

openidm-users-list

When you change a mapped attribute in the source, in this case OpenDJ, reconciliation updates it in the target, in this case the managed/user. For example, Babs Jensen’s original mail address is bjensen@example.com.

openidm-babs-before

After changing the mail address in OpenDJ to babs.jensen@example.com, reconciliation updates her corresponding managed/user in OpenIDM’s repo. Refreshing the page after reconciliation, you can see the change.

openidm-babs-after

The OpenIDM Admin UI is quite a leap forward, and promises to make it much easier for all of us to create and edit resources and mappings, and to arrange and schedule synchronization. Hats off to the OpenIDM team!

1 Comment

Filed under Identity Management

OpenAM: Policy management improvements

OpenAM logoLast week’s entry summarized new OAuth 2.0 and OpenID Connect related features that you can try in the nightly builds of OpenAM. But those aren’t the only important changes for the next major release. Among the many others are changes to policy management, including a slick new UI for creating and editing policies.

Rest assured that your existing agents and existing policies still work fine after you upgrade your OpenAM servers. Policy evaluation works as it did before. What’s been done is to take full advantage of the newer policy engine implementation that is already in use today behind the scenes, but not made visible in OpenAM 11.

The new policy editor (re)introduces the notion of application. An application serves as a template for policies, and helps you to group policies. When you open the policy editor in OpenAM console, the first thing you see is the list of applications for the realm where you are managing policies. The default application in the top-level realm, geared for web and Java EE policy agents, is named (with a bit of nostalgia for the old folks) iPlanetAMWebAgentService.

PolicyEditor

You can then drill down to create or edit a policy that belongs to this application.

PolicyEditorApplication

Notice the policy for the OAuth 2.0 authorization server & OpenID Provider. It is when you start creating or editing the policies that you see the strongest features of the new UI.

PolicyEditorPolicy

As you see in this excerpt (conditions and response attributes are not shown), the policy editor works like a wizard, guiding you through the steps to build your policy. You can build up subject and environment conditions using the logical operations. The image shows a subject condition for all authenticated users but not the demo user.

One thing to keep in mind if when creating your own applications, especially in sub-realms: OpenAM can now direct policy agents straight to an application, so you don’t always need referrals (unless for example you want to have a policy agent protecting multiple applications). This is done with a couple of new properties in the policy agent profile. Here’s a snapshot of the Policy Client Service section of a web policy agent profile screen showing the new properties.

PolicyClientService

These properties are not actually used by the policy agent, but instead by OpenAM, when it directs policy decision requests to the right realm and application.

Underlying the new UI is a full REST API for policy management and policy evaluation. The REST API opens up additional application types, letting you describe applications where the verbs are not necessarily those of HTTP, and write custom policy enforcement points for such applications.

There are still a few changes forthcoming in the UI, and the documentation is catching up with the code, but this is something you can start playing with already in the latest builds.

Leave a comment

Filed under Access Management

OpenAM: More OAuth 2/OpenID Connect features

OpenAM LogoIf you have not looked at OpenAM development in a while, you might have missed some of the new capabilities now in the nightly builds and coming in the next release. Many areas from STS to policy to REST APIs are involved.

One specific area centers on OAuth 2/OpenID Connect and mobile-oriented deployments.

OpenAM nightly builds now support:

  • GSMA Mobile Connect, especially the OpenID Connect 1.0 profile
    Mobile Connect lets users authenticate with their mobile phones, regardless of the service or the device on which it is consumed, so that Mobile Network Operators can serve as identity providers for their customers. As OpenAM has authenticators needed for GSMA Mobile Connect out of the box, and also has an authentication module SPI, OpenAM can play both the OP and authenticator roles in a Mobile Connect deployment.
    Check out this sample JavaScript client on GitHub for a non-secure but transparent look at how service using Mobile Connect client might work with OpenAM. Also read Using OpenAM with Mobile Connect.
  • Easily setting up OpenAM as a client of an OpenID Provider or an OAuth 2.0 authorization server
    When you first login as OpenAM administrator, there it is on the common tasks page: Configure Social Authentication.
    This makes it a snap to use Facebook, Google, MSN, or another provider as an identity provider for your users, and still protect resources with OpenAM.
  • OpenID Relying Parties registering without first obtaining an access token
    If you can throttle requests, this can streamline registration of OpenID RPs quite a bit. See To Register a Relying Party Dynamically.
  • Self-service management of OAuth 2.0 tokens
    This console feature lets users revoke authorization for applications. Even if you implement a feature like this elsewhere, it can be handy for testing. See User Consent Management.
  • Users authenticating with an OpenID Provider’s ID token
    OpenAM provides an OpenID Connect authentication module for this. See Hints for the OpenID Connect id_token bearer Module.
  • OAuth 2.0 scopes as conditions for OpenAM policies
  • CORS for OpenAM APIs
    Cross-Origin Resource Sharing makes it easier to use all the REST APIs in user-agent based applications. See Enabling CORS Support.
  • JWTs for authentication, and JWTs or SAML assertions to request access tokens
    Check out this sample Java client on GitHub for an example of how to request an access token with client-built JWT.
    The JWT bearer profile support can be handy for example with service accounts where there’s no end user involved. The documentation for this is in review.
    The SAML assertion bearer profile can be useful when integrating OAuth 2.0/OpenID Connect in a deployment that can already do SAML 2.0 federation. See SAML 2.0 Bearer Assertion Profiles.

As always, your input for the documentation on these topics is welcome. At the bottom of the draft docs, you will find a link to JIRA to open a doc issue for example.

1 Comment

Filed under Access Management

OpenIG: A quick look at decorators

openig-logo

Guillaume recently added a cool new feature for the upcoming release of OpenIG: decorators. To use decorators before the release, take a nightly build, or build OpenIG yourself.

Decorators are objects that extend what other objects can do. For example, OpenIG now has a CaptureDecorator that lets Filters and Handlers capture requests and responses as they pass through, and a TimerDecorator that logs how long it takes for Filters and Handlers to do their processing.

You configure decorators in the heap alongside your other objects.

For example, to configure a CaptureDecorator itself that also captures the entity when logging a request or response, you add a configuration object that looks like this:

{
    "name": "capture",
    "type": "CaptureDecorator",
    "config": {
        "captureEntity": true
    }
}

To add decorations to other objects, you have two options. You can either set default “decorations” for all applicable objects in the heap, or you decorate individual objects. The scope of the former is everything in the heap to which the decoration applies. The scope of the latter is only the individual object.

You configure a decoration by using its “name” as a top-level property. For example, to add a “capture” decoration to all Filters and Handlers, capturing at all possible capture points, add the “decorations” to the heap like this.

{
    "heap": {
        "objects": [
            {
                "name": "capture",
                "type": "CaptureDecorator",
                "config": {
                    "captureEntity": false
                }
            },
            ... other objects ...,
            {
                "name": "ClientHandler",
                "type": "ClientHandler"
            }
        ],
        "decorations": {
            "capture": "all"
        }
    },
    "handler": "ClientHandler"
}

The configuration shown here results in a lot more capturing than when you use a CaptureFilter. A CaptureFilter captures only the request and response where it is configured in a chain. When you add capture decorations at all capture points to all your Filters and Handlers, then the capture happens for requests and responses as they enter and leave each Filter, and for requests as they enter and responses as they leave Handlers.

Also, notice that “decorations” is a heap property, rather than a global property of the server or the route.

Once you have narrowed down what you want to observe, and find for example that you only want to capture requests as they enter the “ClientHandler” and responses as they leave the “ClientHandler”, comment out “decorations” and decorate only the “ClientHandler”.

{
    "heap": {
        "objects": [
            {
                "name": "capture",
                "type": "CaptureDecorator",
                "config": {
                    "captureEntity": false
                }
            },
            ... other objects ...,
            {
                "name": "ClientHandler",
                "type": "ClientHandler",
                "capture": [ "request", "response" ]
            }
        ],
        "_decorations": {
            "capture": "all"
        }
    },
    "handler": "ClientHandler"
}

Notice what has changed in the configuration. “ClientHandler” now has the “capture” decoration, this time with an array of capture points rather than a single string. The field “_decorations” now employs Guillaume’s famous underscore commenting convention. (When OpenIG does not recognize a JSON field name, it ignores the field. The leading _ is a nice toggle.)

Decorators are likely to take the place of older, more cumbersome ways of configuring some capabilities. The CaptureFilter is deprecated starting in the next release, for example. For more about OpenIG Decorators see the draft OpenIG Reference.

Leave a comment

Filed under Access Management

ForgeRock doc tools 2.1.5 released

ForgeRock doc tools 2.1.5 is now available. This is a maintenance release, adding an option to stop the build after pre-processing DocBook XML sources and fixing some bugs. Thanks to Gene and Chris for their fixes, and to Lana for testing.

See the release notes for details about what has changed.

You do not need to make any configuration changes to move to this maintenance release from 2.1.4, except to update the version number in your POM.

See the README for more about how to use the doc tools.

Leave a comment

Filed under Docs, Tools

OpenDJ: LDAP Controls

OpenDJ LogoLDAP controls are a standard mechanism for extending basic LDAP operations. For example, you can use a control to ask the LDAP server to sort search results before returning them, or to return search results a few at a time.

OpenDJ directory server supports a fairly long list of controls. Let’s take a look at three of them.

“Only do this if…”

The Assertion Control tells the directory server only to process the operation if a specified assertion is true for the target entry. You can specify the assertion as a filter to match.

As an example, let’s replace Babs Jensen’s street address, but only if it is the one we are expecting. Notice the assertion filter passed to the ldapmodify request. If Babs’s street address is not “500 3rd Street”, the request does not have an effect:

$ ldapmodify \
> --port 1389 \
> --bindDN uid=kvaughan,ou=people,dc=example,dc=com \
> --bindPassword bribery \
> --assertionFilter "(street=500 3rd Street)"
dn: uid=bjensen,ou=people,dc=example,dc=com
changetype: modify
replace: street
street: 33 New Montgomery Street

Processing MODIFY request for uid=bjensen,ou=people,dc=example,dc=com
MODIFY operation successful for DN uid=bjensen,ou=people,dc=example,dc=com

“Make the modification, and shut up”

The Permissive Modify Control is handy when you want to make a modification no matter what. It lets you add an attribute that already exists, or delete one that is already gone without getting an error.

As an example, let’s make sure user.0 is a member of a big static group. It doesn’t matter whether user.0 was already a member, but if not, we want to make sure user.0 is added to the group.

$ ldapmodify \
>  --port 1389 \
>  --bindDN uid=user.1,ou=people,dc=example,dc=com \
>  --bindPassword password \
>  --control 1.2.840.113556.1.4.1413
dn: cn=Static,ou=Groups,dc=example,dc=com
changetype: modify
add: member
member: uid=user.0,ou=people,dc=example,dc=com

Processing MODIFY request for cn=Static,ou=Groups,dc=example,dc=com
MODIFY operation successful for DN cn=Static,ou=Groups,dc=example,dc=com

“Delete the children, too”

The Subtree Delete Control lets you delete an entire branch of entries.

As an example, let’s delete ou=Groups,dc=example,dc=com and any groups underneath. The user doing this needs an access to use the tree delete control, as in aci: (targetcontrol="1.2.840.113556.1.4.805") (version 3.0; acl "Tree delete"; allow(all) userdn ="ldap:///uid=user.1,ou=people,dc=example,dc=com";).

$ ldapdelete \
>  --port 1389 \
>  --bindDN uid=user.1,ou=people,dc=example,dc=com \
>  --bindPassword password \
>  --deleteSubtree \
>  ou=Groups,dc=example,dc=com
Processing DELETE request for ou=Groups,dc=example,dc=com

DELETE operation successful for DN ou=Groups,dc=example,dc=com

As mentioned above, OpenDJ directory server supports many LDAP controls. So does OpenDJ LDAP SDK. If you want to use one in your application, see the Dev Guide chapter on Working With Controls.

Leave a comment

Filed under Directory Services and LDAP