söndag 28 maj 2017

Social IdP in OpenIDM 5

The release of OpenIDM 5.0 allows implementors to quickly and efficiently set up integration with three of the major social IdPs; Facebook, Google and LinkedIn. Leveraging a Social IdP for self-service registration and authentication significantly lowers the barrier to enter and gain access to valuable applications and services yet collects valuable and often required information for companies without the end user to manually having to enter the same identity data over and over again.

This article will guide you through the technical setup of setting up and utilize LinkedIn as social IdP for authentication and self-service registration. I will assume that OpenIDM is newly installed.

If you are trying to leverage any of the other supported Social IdPs you need to configure a fully qualified domain name (FQDN) for OpenIDM. LinkedIn accepts Localhost which is why we utilize LinkedIn in this article.

Below are the steps required to perform this setup. Each step will be described in detailed.

  1. Creating an Application in LinkedIn
  2. Configure->Socal ID Providers in OpenIDM
  3. Turn on LinkedIn. Go to dev site and get
    1. Client ID and Client Secret
    2. Insert Redirect URIs
  4. Enable Social Providers authN module
  5. Enable Social Self-Service Registration

Creating an Application in LinkedIn

A prerequisite to being able to set up Social IdP integration in OpenIDM is an existing application in LinkedIn. The LinkedIn developer site allows you to create applications using the LinkedIn API.

  1. Should you not already have a company created, create one.

3. Next step is to create the actual Application. The application will allow you to get two important credentials. Client ID and Client Secret, required for configuring Social IdP integration in OpenIDM. It will also allow you to define Redirect URLs.

Configure->Social Identity Providers in OpenIDM

Next up will are going to configure LinkedIn as a Social Identity Provider. Point your browser to OpenIDM administrative interface and click on Configure->Social Identity Providers in the top menus.

The configuration screen that follows is where the Client ID and Client Secret should be defined.

Make sure you click “save” once the Client ID and Client Secret have been inserted from the LinkedIn Developer Site and the newly created Application in the previous step.

Configure Social Provider as an Authentication module

Since we want to leverage LinkedIn for authentication, we also need to configure Social Identity Provider as an authentication module. The two “Warnings” that pops up will take you straight to the two steps necessary to complete this exercise. Just click on “Social Providers” or via the menu option Configure->Authentication and the the Module tab.

Make sure to select “+ Add”. The default configuration values can be left as is and save the settings by selecting “Submit”.

Ensure LinkedIn is leveraging during Self-Service Registration

To utilize the identity information available in users LinkedIn profiles during registration and thereby lowering the barrier to register make sure you select Configure->Self Service and turn “Social Registration” to ON.

The Social Registration Properties tab outlines how the identity data will populate the managed user object, which in turn is what we can leverage to provision downstream to integrated target resources. Should you want to amend or augment the user with additional identity data, this is the place where you can make the necessary changes and/or additions.

Should we log out at this point, a LinkedIn authentication button will be displayed on both the Administrative user interface as well as the self-service user interface. The Self-service interface also has a link at the bottom of the page to register for a new account.


Summary and conclusion 

The introduction of Social IdP integration in OpenIDM 5.0 allows customers to quickly take advantage of Social Identity Providers for self-service registration and authentication. This lowers the barrier to enter and limits the necessity to register using multiple forms being displayed to users. The information gathered allows for downstream provisioning to marketing solutions, such as Marketo, or to other integrated target resources. Try it out and let me know how it goes!

fredag 3 juni 2016

Common Pitfalls deploying OpenIDM

ForgeRock OpenIDM is built around the concept of flexibility, that in itself provides a powerful platform to solve all kinds of Identity provisioning related problems that organizations and enterprises faces. Whether its for internal-facing users such as employees or contractors or if its external facing identities such as customers or partners leveraging services your company exposes, OpenIDM is the ideal platform to address these challenges.

However, with this flexibility comes a great deal of potential pitfalls the reckless implementer can fall into, and since I recently discussed this at the ForgeRock UnSummit in San Francisco, I thought i'd highlight some of these in my blog. 
  • Isolate each piece of the deployment (e.g. source system, target system, IDM repository, etc..) and measure perf.
    • Weakest link will be the limiting factor for recon performance
Yes! We all know that mainframes integrated via screen-scraping is horribly slow performant. Don't expect anything different. 
  • Ensure recon source/target queries return full objects vs using the default of query-all-ids.  This has a dramatic impact on overall recon time as once the initial source/target queries have executed the recon doesn't need to query those systems again until the target objects are updated
  • For very large source datasets, us paging with recon source queries
  • Isolate audit data within it's own database

    Audit can be useful and needed, but if not needed limit the amount of audit data that is written down. Avoid using the repo for audit data storage as this puts stress on the repo and will slow the performance. Always use its own DB. If your use-case do not require audit at all but require super high performance - turn off audit all together.
  • Be wary of circular updates when using bi-directional mappings.

    This is a dangerous one! The scenario where i have essentially two authoritative sources for the same piece of identity data. E.g. a Database containing a set of identity attributes and the same being stored in OpenIDM as part of the Managed User. When changes occur on the database it should propagate back to OpenIDM and when changes occur on OpenIDM it should propagate to the Database - Implemented thru the use of our hooks, e.g. onUpdate. If not careful, one can easily end up in a circular cascading behaviour of updates!
  • Be wary of mappings which always result in a modified target object.  For example when mapping password -> userPassword via the LDAP Connector. The userPassword attribute in the provisioner MUST have the NOT_RETURNED_BY_DEFAULT and NOT_READABLE flags set otherwise OpenIDM will compare the clear-text password value to the hashed userPassword value returned by LDAP and always push a change.
  • In a cluster, always set schedules to persistent and disable concurrent execution
  • Always use the LDAP connector over that of the .NET Connector unless it is impossible to do otherwise. LDAP Connector performance is far greater than that of the .NET Connector

    If managing only users in Active Directory without the need to do more sophisticated things like running scripts, PowerShell CmdLets, setting ACLs etc - the LDAP integration approach is most suitable and much better on performance.
  • Always use immutable IDs for Managed Objects and remote System Objects
Although it is easier when playing with the REST API thru tools such as Curl, using simplified IDs such as human readable clear text names, this is generally a bad idea outside of demoing capabilities, development etc. Leverage the auto-generated UUIDs each object gets in OpenIDM and you will avoid problems later. 

Should you have experienced issues or pitfalls that is worth describing, feel free to drop me a note! 

måndag 1 juni 2015

How to do ScriptedTask in OpenIDM Workflow

Here is a quick demonstration I compiled after the last post. This was demonstrated at the ForgeRock Identity Summit 2015 in Half Moon Bay, CA as well as in a webinar. For all those who missed out on either of these opportunities, here is a quick summary.

torsdag 23 april 2015

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.


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.

Screen Shot 2015-04-23 at 09.24.30.pngDiagram 1: The unaltered newUserCreate workflow

<scriptTask id="tweet" name="Tweet Welcome" scriptFormat="groovy" activiti:autoStoreVariables="false">
       @Grab(group='org.codehaus.groovy.modules.http-builder', module='http-builder', version='0.5.1')
       @Grab(group='oauth.signpost', module='signpost-commonshttp4', version='')
       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',

           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()

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>

Screen Shot 2015-04-20 at 14.35.27.pngDiagram 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.

Screen Shot 2015-04-23 at 09.33.40.png

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!

fredag 25 juli 2014

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. 

fredag 9 maj 2014

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.

tisdag 6 maj 2014

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.