Notifications in OpenIDM Workflow via Twitter

OpenIDM is one of the markets most flexible platforms for identity management. Embedded as part of the product is a business process engine supporting the industry standard BPMNv2 for defining processes and workflow. Business logic in OpenIDM supports both Groovy and JavaScript which also applies to the business process engine.

In this little sample, i will demonstrate using one of the sample use-cases, how we can quickly and easily extend it, to include integration with a third party solution exposing RESTful APIs. For this i’ve chosen Twitter.

For this simple example to work, i’m starting off fresh with an instance of OpenDJ and OpenIDM 3.1. OpenDJ should be installed and pre-loaded according to the instructions found in $OPENIDM/samples/usecase/README (found once OpenIDM is unzipped).

Usecase1 - Initial reconciliation

   In this step we import the users from OpenDJ to OpenIDM using reconciliation.

   To prepare to run the sample, download OpenDJ directory server from

   http://forgerock.org/opendj.html. Install OpenDJ using QuickSetup:

       * Use "password" as the password for cn=Directory Manager.

       * Import samples/usecase/data/hr_data.ldif during installation.

   1. Start OpenIDM with the configuration for usecase1.

   $ cd /path/to/openidm

   $ ./startup.sh -p samples/usecase/usecase1

   2. Run reconciliation.

   $ curl -k -u openidm-admin:openidm-admin -H "Content-Type: application/json" -X POST "https://localhost:8443/openidm/recon?_action=recon&mapping=systemHRAccounts_managedUser"

   3. Query the managed users created by reconciliation

   $ curl -k -u openidm-admin:openidm-admin "https://localhost:8443/openidm/managed/user?_queryId=query-all-ids"

   

   There should be 23 users created. The default password of the imported users is "Passw0rd"

Groovy support a capability to reference artifacts and resolve dependencies and make it available on the Classpath called Grab. Grab is called upon within your scripts with the @grab annotation. With this support and Groovy, there is no need to compile java code, deploy along with required dependencies and manipulate the classpath. For this capability we need to grab a copy of ivy, extract the ivy-2.4.0.jar and make it available to OpenIDM by copying the jar-file to $OPENIDM/bundle.

At this stage we have OpenDJ up and running and now its time to take a closer look at the createNewUser workflow part of usecase2. This is the workflow i want to extend with an activity to tweet whenever a new user is provisioned, welcoming her to the world.

The integration with Twitter are using OAUTH authentication, so we need create a twitter account for the purpose of this exercise and generate the OAUTH credentials and tokens.

• Consumer Key
• Consumer Secret
• Access Token
• Access Token Secret

To start with, as mentioned above you need a Twitter account unless you already have one. Once created, login to the Twitter Developer Site. Go to Manage my Apps and click “Create a new application”. Fill out the mandatory fields and submit. By completing this process you will be provided the above required information to continue building your scriptTask and utilize it in your workflow.

Now, lets make a copy of the usecase2 folder and perform our edits on the copy, thereby keeping the original for reference.

$ cp -r $OPENIDM/sample/usecase/usecase2 \ $OPENIDM/sample/usecase/usecase2twitter

make the copy your working directory and unzip the bar-file containing the workflow.

$ cd $OPENIDM/sample/usecase/usecase2twitter && unzip newUserCreate.bar

The bar file contains two forms and the actual workflow definition.

createNewUser.bpmn20.xml

nUCDecideApprovalForm.xhtml

nUCStartForm.xhtml

We are going to perform two steps with the createNewUser.bpmn20.xml workflow definition. First add a scriptTask and then wire the transitions to include the new scriptTask before the processes reached its end.

Diagram 1: The unaltered newUserCreate workflow

<scriptTask id="tweet" name="Tweet Welcome" scriptFormat="groovy" activiti:autoStoreVariables="false">

     <script>

       @Grab(group='org.codehaus.groovy.modules.http-builder', module='http-builder', version='0.5.1')

       @Grab(group='oauth.signpost', module='signpost-commonshttp4', version='1.2.1.1')

       import groovyx.net.http.RESTClient

       import static groovyx.net.http.ContentType.*

         

       twitter = new RESTClient( 'https://api.twitter.com/1.1/statuses/' )

       try {

twitter.auth.oauth pom.properties.'twitter.oauth.consumerKey',

    pom.properties.'twitter.oauth.consumerSecret',

    pom.properties.'twitter.oauth.accessToken',

    pom.properties.'twitter.oauth.secretToken'

           println "Sending tweet..."

           msg = "A new user has been created! Hello new user: ${userName}."

           resp = twitter.post( path : 'update.json', body : [ status:msg, source:'httpbuilder' ], requestContentType : URLENC )

           println "Tweet response status: ${resp.statusLine}"

           assert resp.statusLine.statusCode == 200

         } catch (all) {

           out:println "Exception " + all.getMessage()

           out:println "Exception " + all.getStackTrace()

         }

     </script>

   </scriptTask>

The twitter.oauth.consumerKey, twitter.oauth.consumerSecret, twitter.oauth.accessToken and twitter.oauth.secretToken should be substituted with the secrets provided by Twitter in the previous step where Twitter was set up for this exercise.

The last step is to alter the sequenceFlow to include the new activity we called ‘tweet’. The original sequenceFlow transitioning sendAcceptNotification to end needs to be changed and we need to add another sequenceFlow transitioning our new scriptTask to end.

   <sequenceFlow id="flow1" sourceRef="sendAcceptNotification" targetRef="tweet"></sequenceFlow>

   <sequenceFlow id="flow2" sourceRef="tweet" targetRef="end"></sequenceFlow>

Diagram 2: The modified newUserCreate workflow

Once the changes are saved, its time to package the files into a bar-file and deploy the new workflow.

$ zip createNewUser.bar createNewUser.bpmn20.xml \

nUCDecideApprovalForm.xhtml nUCStartForm.xhtml

Now make sure the createNewUser.bar replaces the old bar in $OPENIDM/sample/usecase/usecase2twitter.

The current openidm instance running is using the usecase1 setup, we need to switch to usecase2twitter. To do this, shutdown OpenIDM and start it again with the -p switch pointing at the usecase2twitter directory.

$ ./startup.sh -p sample/usecase/usecase2twitter

Its now time to test our new workflow with the tweet addition.

To do this, just continue following the instructions provided in $OPENIDM/sample/usecase/README under usecase2 section.

2. Log in to the UI as user.1 (this user belongs to HR department, default password is 'Passw0rd')

   3. Select the User Onboarding Process by clicking on it.

   4. Fill the fields of the form presented by the UI. The fields marked with x are mandatory.

       - Department field:

           By selecting one of the four departments we define which department the new user

           will belong to. Based on this the workflow will select the possible candidate assignees

           for the manager approval user task: it will be either superadmin (as manager of everyone)

           or the manager of the selected department (see description above).

           example: if HR is selected the manager candidates will be user.0 and superadmin.

       - User Type field:

           if the User Type field is Employee then the user will have access to an account called "Business".

               This is represented on the managed user in OpenIDM repository by having the following attribute on

               the managed user:

                   accounts : [ "Business"]

           if the User Type is Contractor then the new user won't have any accounts associated to it in

               managed user representation in OpenIDM.

       - Send Email Notification field:

           If 'No' is selected for this field then no email notifications will be sent.

           Notifications will be added to the OpenIDM repository which will appear on UI.

   5. Start the workflow by clicking on Start button.

   6. Log out and log in as the manager of the department selected in the initial start form

       example: if HR was selected then log in as user.0

   7. Click on the Onboarding approval task appearing on UI as task in the group queue

       and assign the user task to user.0 (select 'Assign it to me'). The task appears now in 'My tasks'.

   8. Click on the Task and then on the 'Details' button.

       - Start Date field:

           filling this field results in the user being created and adding the startDate property

           to the user. Furthermore, the user status will be 'inactive'.

           The field is optional, it will be used by TaskScanner to trigger sunrise workflow.

       - End Date field:

           filling this field results in the user being created and adding the startDate property

           to the user.

           The field is optional, it will be used by TaskScanner to trigger sunset workflow.

       - Manager field:

           Selecting yes will add 'title' field to the new managed user with the value 'manager'.

       - Decision field:

           Selecting 'Reject' terminates the workflow and sends a notification to the start user

           of the workflow.

      Complete the task by clicking on 'Complete' button.

9. If 'Accept' was selected then the user is created as a managed user in OpenIDM.

       The password of the new user is "Passw0rd".

Two OpenIDM notifications are created about this event: one for the start user and one for the new user. Those are visible on the UI after login with the appropriate user - and to view our addition, check the twitter page for a new tweet.

To summarize, OpenIDM provides a flexible way to integrate with third party applications thru the use of Workflow. The possibilities here are endless.

Over and out - TGIF!

In the light of Internet of Things and OpenIDM

I am a hug fan of hotels that meet my standard of living and during ForgeRock's recent IRM Summit in Phoenix, AZ i spent some time aligning ForgeRocks OpenIDM with a rather interesting use-case that could benefit a lot of hotels.

Imagine showing up late at the Waldorf=Astoria Biltmore Hotel straight from a 18 hour journey from across the pond, with no real ambition on queuing to get checked in and all sorted out, what would be more convenient than having your hotel room information texted to your cellphone the moment you land and your NFC enabled smartphone already set up to let you in to your room for a quick shower and instantanteous relaxation?

With OpenIDM, supporting this type of use-case is easy and was in fact demonstrated at the summit using a combination of a lock that opens and locks based on the credentials set up on your smartphone. Provisioning user account information along with devices and things is easy in the RESTful world that we are seeing happening infront of our eyes and Gemalto provides this type of cloud service.

Make sure to check out this video that demonstrates the use and explains the details. 

http://www.youtube.com/watch?v=gToEp3Khd0c

10 min demonstration of Roles in OpenIDM 3.0

In this 10 min video role based provisioning is demonstrated. We will see how to create a new role, assign that role to a user, remove the role from the user and delete the role.

Installing and integrating OpenDJ and OpenIDM in 10 minutes

In this 10 min tutorial, you will learn how to install OpenDJ and OpenIDM, and integrate OpenIDM to reconcile with OpenDJ. 

Using OpenAM Realms for Large Scale Access Management

ForgeRock OpenAM provides a powerful Realms facility, enabling OpenAM to be used in internet scale deployment scenarios. Realms can be used to divide user populations and their associated configurations, with each realm treated as a discrete administrative unit.

For each Realm, an authentication process can be defined, stating the location of the authentication repository for users and groups, such as an Active Directory or LDAP directory, and the type of authentication required. Each Realm also has the ability to have policies defined to determine whether or not an authenticated user is allowed access to a resource protected by OpenAM. Realms allow for the separation of configuration data for the services used per realm as well as for federation purposes.

For administrative purposes, delegated administration enables user populations to be separated and sliced via realms, so that they can be managed in a distributed fashion. Delegated administration is a critical component in the deployment of large user populations, where central administration becomes unwieldy and too complex to be practical.

Service providers can use Realms to centralize authentication and authorization for multiple customers (often referred to as tenants) from different companies. Realms provide the boundaries, separating the tenants from each other and ensuring that they do not authenticate to each other or obtain authorization to access resources from each other. Delegated administration can therefore occur at the tenant level.

The ForgeRock IRM suite shares a common RESTful API, allowing Realms to be created, managed, and configured via REST and also through the CLI and the Administrative Console.

For example, you can create a REALM via REST simply by using an HTTP POST, as follows:

1 2 3 4 5

$ curl --request POST --header "iplanetDirectoryPro: AQIC5w...2NzEz*" --header "Content-Type: application/json" --data '{ "realm": "testRealm" }' https://openam.com:8443/openam/json/realms/?_action=create {"realmCreated":"/testRealm"}

The only required field is realm, however, the realm will not be active unless its status is set.

The caveat to the current Realms implementation in OpenAM, is that logs are not yet separated per Realm. This is something that is being addressed in future product enhancements, as ForgeRock moves towards a full blown multi-tenant architecture.

For the curious and the technically savvy, given the long history and maturity of OpenAM, it’s worth mentioning that Realms were previously called “organizations” (prior to OpenSSO). This is why the OpenAM SDK often refers to an “organization object”, rather than a “realm object”, for backward compatibility.

In summary, OpenAM Realms offer a convenient way to slice up a large scale user population into manageable chunks that can be separated from each other in how they are configured. Realms also enable delegated administration - critical in distributing the administration load and in addressing the challenges of consumer-facing identity and access management for the modern web.

Adaptive Risk Authentication and the IRM Pillar Dynamic Intelligence

The requirements and demands on Identity and Access Management solutions have shifted. With a fresh pair of eyes, the industry calls this Identity Relationship Management (IRM). One of the pillars defining IRM is Dynamic Intelligence rather than Static Intelligence. Static Intelligence covers what we already know about a user, whereas dynamic intelligence includes things that might be spontaneous, such as geographical login location.

In the past, access patterns have been predictable. Employees have logged in from their usual desktop PCs, and have accessed the applications required to perform their job tasks. As the modern world has changed user behavior, predictability is no longer the case. Enterprise users access applications and services from a wide variety of locations and devices, including laptops, smartphones and their traditional desktop PCs. Looking beyond the enterprise at consumers, these users can leverage any device, from their home TV to their car.

A modern IRM solution must be able to cater for these dynamic access patterns and must understand the myriad of circumstances in which a user accesses a particular service, in order to grant access. Ultimately, authorization must also be dynamic and must provide the appropriate content or entitlements “on the fly”. A concrete example is that of a user trying to access services when logged in from a different country. An adaptable IRM system will adjust to the particular circumstances and will potentially ask for additional authentication beyond simple credentials.

This use-case is something that can be addressed with the latest release of ForgeRock OpenAM (introduced in OpenAM 10), which provides an adaptive risk authentication module. Adaptive Risk Authentication is not an authentication mechanism but rather identifies potential risks (such as logging in from a different country in the sample above), assigns a risk score and then determines whether logging in should require additional means of authentication. The additional authentication requirement can be anything from requiring a one time password to using some type of hardware mechanism.

An authentication mechanism that adapts to specific circumstances is a perfect example of the IRM pillar of “Dynamic Intelligence” and adds additional assurance that a user really is who she claims to be.

Some of the risks that can be defined and dealt with dynamically include IP Ranges, IP History, known cookies (and values), time since last login, profile attributes and their values or geographical location.

Pioneering risk-based, adaptive authentication has always been the domain of the financial sector. However, as this technology has become mainstream, more and more organizations are deploying adaptive authentication to deal intelligently with the growing number of mobile users, to mitigate the risks of users who fraudulently claim to be someone else in order to potentially commit malicious actions.

Two-factor authentication for mobile with OATH

Nearly all major vendors of smartphones and tablet platforms, such as Apple, Google, Microsoft and Blackberry, support software tokens to provide an inexpensive yet secure way to perform two-factor authentication. The majority of these vendors leverage OATH HOTP for this service, and the fact that ForgeRock OpenAM supports OATH HOTP, is a good reason to drill into this a little deeper.

Two-factor (or multi-factor authentication) is nothing new and is commonly found in various applications where the basic authentication process of providing just a password, a pin code, or the swipe of a card isn’t enough. The purpose of multi-factor authentication is to lower the probability of the user trying to authenticate to provide false credentials as evidence of his identity. The rationale goes, the more factors, the higher the probability that the user is who he or she claims to be.

In the case of two-factor authentication, the two factors are typically something the user knows (such as the classic password, and some private identity details such as mother’s maiden name or first pet’s name) and something the user has (such as an access card or a cellular phone). A third factor might be something the user is, such as biometric data of the face or fingerprint, or voice characteristics.

Now, OATH (short for Open Authentication) is a collaborative effort of various members of the IT industry to provide a reference architecture for universal strong authentication across all users and devices over all networks. OATH is open and royalty free, for anyone to implement and use. HOTP is short for HMAC based One Time Password. The idea behind OATH is to reduce complexity and lower the cost of ownership by allowing customers to replace proprietary security systems, which often are complex and expensive to maintain.

ForgeRock OpenAM can be configured to support OATH-based HOTP for two-factor authentication. For the technically savvy, who like to try things out, there is an easy to follow guide to configure OpenAM in this way. On a side note, OpenAM can also support TOTP or Time based one time passwords. Both TOTP and HOTP are standards described in RFC 4226 and RFC 6238.

There are a number of use-cases where this added security comes in handy.

• Self-service password resets

One of the most common problems users encounter is when they forget their passwords and are unable to login to work or to purchase goods and services. The traditional approach to address these issues is to leverage what is called challenge/response questions - a set of predefined or user-defined questions with answers to reset the password. In the light of what people tend to share on social media sites these types of questions typically introduce a weakness in the security perimeter. In fact, the U.S. Federal Financial Institutions Examination Council (FFIEC) and the U.S. Federal Deposit Insurance Corporation (FDIC) strongly cautions financial organizations against adopting authentication methods that use personal information for authentication purposes. With OATH tokens, an easy second factor can be introduced, thereby mitigating some of the associated risks.

• Accessing cloud applications via single sign-on
  In the new and modern world without boundaries, moving freely between on-premise applications and off-premise cloud applications might cause your company security experts sleepless nights. Introducing a stepped up authentication with an OATH HOTP when accessing cloud apps could be one precaution to make the security experts sleep better.

• Step up or risk-based authentication

Assume that, from within an application, you are accessing sensitive information or you are logging in using an unknown pattern (for example, from a different network or a new device). Providing a second authentication factor in this case again mitigates some of the risks and OATH is a cost-effective solution to this problem.

To conclude, we have discussed what OATH is, and some of its typical use-cases. OpenAM provides the necessary capabilities to implement a cost effective two-factor (or multi-factor) authentication process that increases user or consumer acceptance for stronger authentication. OATH allows your organization to be compliant and to follow the guidelines set out by FFIEC, FDIC and others, while reducing the risk and implications of identity theft. It does so by offering multiple factors of authentication, allowing users and consumers to more accurately prove that they are who they claim to be.