This blog post was first published @ www.fedji.com, included here with permission.

Think of this post as a remake of an earlier one done several months back. Well, just tha, the earlier blog post in reference here was based on a now older version of OpenIDM, ForgeRock‘s Identity Management Solution. As always, I’m grateful to the ForgeRock documentation team for a clean write up on the Configuration of MySQL as a repository for ForgeRock OpenIDM 4.

Related Video/Documentation:
– Video – Setting Up ForgeRock OpenIDM with MySQL (OpenIDM 3.x)
– Documentation – Setting up OpenIDM with MySQL

This blog post was first published @ www.fedji.com, included here with permission.

ForgeRock OpenIDM 4 uses OrientDB as its default datastore, which is good for learning and evaluation, but not suitable for a Production environment. In an earlier post on this space, we looked at the Configuration of MySQL database as the repository for OpenIDM 4. Picking up from there, because a site that I know of uses PostgreSQL instead of MySQL, made a quick demonstration on setting up OpenIDM 4 with PostgreSQL.

Enjoy!

Related ForgeRock Documentation:
Setting up OpenIDM with PostgreSQL

This blog post was first published @ www.fedji.com, included here with permission.

A few months back, I had published a post with a video demonstration on setting up Email in now older version of ForgeRock OpenIDM. If you haven’t seen it and would like to take a look at it, it’s here. Between now and then a lot of things changed, one of which is an improved UI in the recently released OpenIDM 4. If you’ve four minutes to spare, watch the video below to see how good a work has gone into the OpenIDM 4 UI improvement.

Enjoy!

Configuration Changes

This note describes the customizations necessary to use 2 or more security questions for the following OpenIDM features: user self-registration, change security data and forgot password. Please note that this article was originally written for v3.0.

Common Configurations

Add the new user profile attributes under allowed properties.

./samples/sampleSelfReg/script/access.js

Add policies to the newly added security question and answer attributes.

./samples/sampleSelfReg/conf/policy.json

Include the security answer as a managed object.

./samples/sampleSelfReg/conf/managed.json

./bin/defaults/script/ui/securityQA.js

Self Registration

HTML Template Changes

./ui/default/enduser/public/templates/user/UserRegistrationTemplate.html

Edit the template to include another security question as shown here:

If you want questions pre-selected when viewing the registration page, add this script to the page:

<script>
setTimeout(function () {
document.getElementById("securityQuestion").selectedIndex = 1;
document.getElementById("securityQuestion2").selectedIndex = 2;
}, 200);
</script>

JavaScript Changes

./ui/default/enduser/public/org/forgerock/openidm/ui/user/UserRegistrationView.js

Here we setup the registration code such that it allows the user to setup 2 security questions at the time of self-registration.

Change Security Data

HTML Template Changes

./ui/default/enduser/public/templates/user/ChangeSecurityDataDialogTemplate.html

Change the template to include the option of setting up 2 security questions instead of a default of one OpenIDM ships with:

JavaScript Changes

./ui/default/enduser/public/org/forgerock/openidm/ui/user/profile/ChangeSecurityDataDialog.js

In the javascript, we need to ensure that whenever the user wants to change their security questions, the previously configured ones show up as selected:

Note that this demo does not attempt to manage the UI display order of the previous security questions.

Forgot Password

This code change in UserDelegate.js enables randomly showing any of the 2 configured security questions.

./ui/default/enduser/public/org/forgerock/openidm/ui/user/delegates/UserDelegate.js

Testing

When a user has forgotten their password, they need to click on the Forgot Password link. The security question presented to them is randomly selected from the 2 configured list of questions.

User Interface Views

Self Registration

Change Security Data

Forgot Password

Developers

The following REST calls are made to manage a user’s password reset.

List of Questions

The list of security questions can be received via this API call:

GET http://openidm-server:port/openidm/config/ui/secquestions

User Defined Security Question(s)

This pulls up the security question(s) defined for the user indicated by user-name:

POST http://openidm-server:port/openidm/endpoint/securityQA?_action=securityQuestionForUserName&uid=user-name

Submit Security Response

A security response can be submitted to OpenIDM via:

POST http://openidm-server:port/openidm/endpoint/securityQA?_action=checkSecurityAnswerForUserName&uid=user-name&securityAnswer=<user-response>

Reset User Password

Once the user has entered the correct security response, you may change the password via this API call:

POST http://openidm-server:port/openidm/endpoint/securityQA?_action=setNewPasswordForUserName&newPassword=new-password&uid=user-name&securityAnswer=<response>

This blog post was first published @ www.fedji.com, included here with permission.

We have already discussed on this space the installation of ForgeRock Identity Management Solution and further configuring a Database as its repository. But in those discussions, all the critical components of the Solution namely the ForgeRock OpenIDM 4, MySQL Database were a Single Point of Failure. In an environment where business continuity is critical, we ought to build a solution that has no SPOF in the architecture. So I’m going to take you through that route today. Of course, this is a hint and just a way to understand the different options that you might consider in Configuring ForgeRock OpenIDM 4 for High Availability.

I’ve a rather simple example of HA configuration, mainly meant for understanding and learning it. In a sensitive infrastructure, a great deal of planning goes into building a Highly Available Environment. So what’s the small little setup we’ve here for learning:

Two instances of ForgeRock OpenIDM 4 connects to a MySQL Proxy, which in turn talks to a MySQL Replication site. Of course, in this setup, MySQL Proxy is a SPOF, so you should have at least two of it in front of the MySQL Replication site. But if I had attempted to it, the whole thing would have looked a lot more complicated and would have failed the objective of being a learning tool. So if you’ve just under a half an hour to spare, you will know:

– How to use MySQL Proxy
– How to setup MySQL Replication (Master/Slave)
– How to install OpenIDM 4
– How to configure OpenIDM 4 to use a MySQL Database as its Repository
– How to bring up an OpenIDM Cluster environment

Well, the final state is what you get to see in the illustrations above.

Now on to the video. Enjoy!

This blog post was first published @ www.fedji.com, included here with permission.

The video embedded below is quite straight forward. It demonstrates how to configure Database Table Connector in ForgeRock OpenIDM 4 to connect to provision/deprovision Users in a Database Table (MySQL):

Enjoy!

This blog post was first published @ www.fedji.com, included here with permission.

If you’re in a hurry to know what each of the ForgeRock Identity Platform Components is meant to do, try the Full Stack Configuration. In just over fifteen minutes, you’ll see:

– Installation of ForgeRock OpenDJ
– Deployment of ForgeRock OpenAM
– Configuration of OpenDJ as an Identity Repository in ForgeRock OpenAM
– Installation of ForgeRock OpenIDM
– Configuring OpenDJ as External Resource in OpenIDM
– Running a reconciliation in OpenIDM from OpenDJ
– Provisioning a User from OpenIDM to OpenDJ
– Using OpenAM as the Authentication Module for OpenIDM

With a much awaited weekend around the corner, I couldn’t really get over the laziness to create a better illustration than the one below to help visualize what’s mentioned above.

Please watch it, if you have some time. Enjoy!

Thanks: ForgeRock Product Documentation

This blog post was first published @ identityrelationshipmanagement.blogspot.co.uk, included here with permission.

Access request, or authorization management is far from new.  The classic use case is the use of a workflow process that, via approval, updates a profile or account with a persisted attribute/group/permission in a target system.  At run time, when a user attempts to perform an action on the target system, the system locally checks the profile of the user and looks for particular attributes that have been persisted.

A slight variation on this theme, is to provide a mechanism to alter (or at least request to alter) the persisted permissions at near run time.  An example of this, is to leverage OAuth2 and use of a tokeninfo endpoint that can convert access_token scope data into scope values, that are used by resource server to handle local authorization.  Dependent on the content of the scope values, the resource server could provide a route for those persisted entries to be updated – aka an access request.

In the above example, we have a standard OAuth2 client-server relationship on the right hand side – it just so happens we’re also using the device flow pin and pair paradigm that is described here. Ultimately the TV application retrieves user data using OAuth2 – one of the attributes we send back to the TV, is an attribute called waterShedContent – this is a boolean value that governs whether the user can access post 9pm TV shows or not.  If the value is false, the TV player does not allow access – but does then provide a link into OpenIDM – which can trigger a workflow to request access.

Above flow goes something like this:

1. User performs OAuth2 consent to allow the TV player access to certain profile attributes (0 is just the onboarding process for the TV via pin/pair for example)
2. OpenAM retrieves static profile data such as the waterShedContent attribute and makes available via the ../tokeninfo end point accessible using the OAuth2 access_token
3. Client interprets the data received from the ../tokeninfo endpoint to perform local authorization (if waterShedContent == true || false for example) providing a link into OpenIDM that can trigger an access request
4. The BPMN workflow in IDM searches for an approver and assigns them a basic boolean gateway workflow – either allow or deny.  An allow triggers an openidm.patch that updates the necessary attribute that is then stored in OpenDJ
5. The updated attribute is then made available via the ../tokeninfo endpoint again – perhaps via a refresh_token flow and the updated attribute is available in the client

The code for the PoC-level TV-player with the necessary OAuth2 and workflow request code is available here.

This blog post was first published @ www.fedji.com, included here with permission.

ForgeRock Identity Management solution includes generic Groovy Connector Toolkit that enables you to run Groovy scripts on any external resource. You can read more about it here. Lifted verbatim from the OpenIDM 4 documentation mentioned above:”To facilitate creating your own scripted connectors with the Groovy Connector Toolkit, OpenIDM provides a scripted connector bundler. ” I followed Instructions in there (as well as in the README file of the ‘sample3’ in OpenIDM installation directory), to build a ScriptedSQL Connector to connect OpenIDM to a MySQL Database and my Video Log is below:

Enjoy!

This is an extension of an earlier post that demonstrated ForgeRock Full Stack Configuration, comprising OpenDJ, OpenAM and OpenIDM. In here we’ll plug in ForgeRock OpenIG to route traffic to/from OpenAM and OpenIDM. In the video log that follows, you’ll see:

– All urls that hit OpenIG, containing a string ‘openam’ getting redirected to OpenAM URL
– All urls that hit OpenIG, that does not contain the string ‘openam’ getting redirected to:

1. OpenAM for Authentication if there is no valid User session and then on to OpenIDM UI
2. OpenIDM UI if there is a valid User session

So here’s the extended illustration

Now on to the video.Enjoy!

This blog post was first published @ www.fedji.com, included here with permission.

Security vulnerabilities have been discovered in OpenIDM components. These issues are present in versions of OpenIDM including 3.x and 4.0.x.

This advisory provides guidance on how to ensure your deployments can be secured. Workarounds or patches are available for all of the issues.

The maximum severity of issues in this advisory is High. Deployers should take steps as outlined in this advisory and deploy the recommended workarounds or resolutions as described within each issue below.

Issue #201602-01: Unencrypted Repo JDBC Password

Product: OpenIDM
Affected versions: 3.0.0, 3.1.0, 4.0.0
Fixed versions: n/a
Component: OpenIDM JDBC Repository Server
Severity: High

JDBC Repository passwords are no longer auto-encrypted by OpenIDM when the repository is activated. As a result, the password stored within the repository configuration as well as those written to the JSON configuration files (repo.jdbc.json or datasource.jdbc-default.json) and the OpenIDM log will appear in clear-text.

Workaround:
Manually encrypt the JDBC Repository password using the OpenIDM Command-Line Interface as detailed in the following Knowledge Article: Repository password is not encrypted in OpenIDM 3.x or 4.x log and configuration files.

Resolution:
None.

Static Assignments

 

Note that, each one of these IDM UI steps can be performed over REST as well.

Dynamic Assignments

Creating assignments dynamically from incoming LDAP groups can also be performed by setting “managed/assignment” and “managed/role” as Recon targets with the help of some scripting involved in the attribute grid.

Begin by creating the following two mappings:

system/ldap/group to managed/assignment

and, system/ldap/group to managed/role

The idea here is to automatically create two managed entities from the LDAP Groups container in OpenDJ.

The first managed entity (“managed/role”) is created to hold the named LDAP group objects – deemed Provisioning Roles – in our use case. These LDAP groups you want the users to be automatically added to (or provisioned to in OpenDJ) whenever “same-named” provisioning roles are assigned to a user. These “same-named” provisioning roles happen to be attached to “same-named” assignment objects! (magically!.. not quite, but via transform-scripting as shown below).

The second managed entity (managed/assignment) is created to hold the “same-named” assignment object that you will setup in such a way that it references (internally) the “same-named” provisioning role!

This will become clearer, read on.

The picture above shows which attributes to map for this particular mapping definition.

For the /attributes map, use the following transformation script:

([{assignmentOperation:'mergeWithTarget',unassignmentOperation:'removeFromTarget',name: 'ldapGroups',value: [ source.dn ]}])

This transformation script sets up the incoming group object as an OpenIDM assignment and also sets up the value of the “ldapGroups” attribute to the DN of the incoming group object.

For /roles, use this one:

([{_ref: 'managed/role/'+( openidm.query('managed/role',{'_queryFilter':'/name eq "' + source.cn + '"'}).result[0]._id)}])
This script queries the managed/role container in OpenIDM for a “named” provisioning role whose CN happens to equal the CN of the incoming group object. This assumes that you reconciled the managed/role objects first- and this is the only dependency for this use case. You cannot really search for a provisioning role’s CN value before you reconcile it from LDAP. After retrieving the correct role object, the script sets the _ref property of the assignment to that particular provisioning role. This is what you would do if you were manually “attaching” a provisioning role to an assignment as shown in the Static Assignments section above.

Demo

Now it is a matter of running reconciliation on sourceLdapGroup_managedRole first, followed by running a reconciliation on sourceLdapGroup_managedAssignment. You should see roles such as:

And you should see assignments as well- these are basically “named” after the LDAP group objects that have an ldapGroup attribute setup and also an “attachment” setup to a provisioning role:

For example, lets look at the impersonation assignment in detail.

This picture shows the mapping for this assignment object, and the description reconciled from the OpenDJ groups org unit.

The picture below shows how the DN of the incoming LDAP group object was mapped to an attribute called “ldapGroups”.

The picture below shows the provisioning role, with the same name of course, that is “attached” to this assignment object.

Now we have an “entitlement” framework for automatically creating assignment and role objects in OpenIDM using single or multiple “source” LDAP group containers, and then attaching these provisioning role objects to assignments. We have simply demonstrated a one-provisioning-role to one-assignment mapping in this use case, but far more complex mappings such as many-to-many or many-to-one are possible. This framework can serve as the foundation for an RBAC type scenario in your deployments! Good luck.

A common workflow process is often the access request scenario – a user requires access to something, and that something requires an approval before the provisioning can be completed. Typically this is done via notifications, a dashboard and perhaps an email notifying the approver that they have a task that requires their attention.

However, what if the approver doesn’t want to, or cannot, access their dashboard to approve the request?  An alternative is to embed workflow approval questions into an email, with fully self-contained links that contain encrypted payloads to approve or reject the request. (NB a further extension to this is to be able to respond to workflow requests directly via email / SMTP).

A way to do this is to simply send an email during the workflow instantiation that contains links to approve or reject the request.  But how can those links be securely created to avoid tampering, replay and misuse?  There a few neat steps in the ForgeRock platform that can simply come to the rescue. (NB this assumes that the email traffic / account is secure, which might not be the case…!).

My use case will look like something like this:

1. Helpdesk operator requests access to impersonate an end user for a set period of time – say 5 minutes
2. The end user will receive an email notification with two links – Approve or Reject
3. Each link will go to two specific OpenIDM custom endpoints – ../endpoint/approveImpersonation or ../endpoint/rejectImpersonation
4. Each endpoint will take a ?payload= argument that will contain an encrypted value
5. That encrypted value will be contain the end user’s Id and a unique reference to their workflow task instance
6. As every request into OpenIDM needs to be authenticated, we’ll route the request via OpenIG to add in an authentication header
7. The custom endpoints will verify the payload, decrypt, find the appropriate workflow task instance and complete the workflow request task
8. If approved…the workflow will provision the end users Id into the helpdesk operators account under an attribute called impersonationId
9. The workflow will then suspend and return n-minutes later, based on the time selected in step 1 and deprovision the attribute in step 8.

The architecture at a high level looks something like this:

The main element of this is the workflow.  This is a simple access request style workflow with two interesting components. First is the sending of an email with the two links – both of which are encrypted using the openidm.encrypt function. The second is a time boundary that removes any changes the workflow makes after a selected time window.  The encrypted email payload contains a unique reference that is attached to the task instance.  The unique reference is created using the openidm.hash function, that takes the requester Id, requestee Id and the current time in ms.

To trigger the workflow, the enduser and a time element are entered.

This triggers the sending of the notification email with the two links.

The end user simply selects the appropriate link.  The link automatically redirects via IG to snowball the appropriate authentication headers and completes against the OpenIDM endpoint.

The endpoint verifies the payload argument exists, that the encrypted value is in tact, decrypts, finds the appropriate workflow task, compares the two hashed verification codes and completes the appropriate approve or reject action.

The workflow then contains an intermediate timer event that is used to act as a stop watch – to basically reverse any changes that are made, acting like a temporal condition.

<intermediateCatchEvent id=”timer”>
<timerEventDefinition>
<timeDuration>PT${lengthOfImpersonation}M</timeDuration>
</timerEventDefinition>
</intermediateCatchEvent>

The length variable is taken from the submitted workflow form.  After the timeDuration has completed a simple patch removes any values provisioned to the user.

<scriptTask name=”Cleanup User” id=”cleanupRequestingUser” >
<script>

queryParams = [“_queryFilter”: ‘/userName eq “‘+startUserId+'”‘]
userToPatch = openidm.query(“managed/user”, queryParams)

patchParams = [[operation:’replace’, field: ‘idToImpersonate’, value : “”]]
openidm.patch(‘managed/user/’+userToPatch.result[0]._id, null, patchParams)
</script>
</scriptTask>

The code for the above sample is available here.

This blog post was first published @ http://www.theidentitycookbook.com/, included here with permission from the author.

OpenIDM provides a powerful delegated administration model, for both REST endpoint access and workflow process access.

A simple way to provide scoped access into the IDM functions, is to simply wrap a workflow process around it and then delegate access to that workflow to a certain of group of users.

A basic example could be that of role based access control administration.  The basic create, read, update and delete tasks often associated with object management.  So RBAC-CRUD to save a few letters.

Each CRUD function can be wrapped into a workflow, with access to those workflows then given members of the rbac-admins internal authorization role.

I created 5 workflows, four for the role-admins and 1 for the end user:

role-admins: createRole.bar

A simple wrapper that takes two arguments and runs an openidm.create() to create the role.

role-admins: deleteRole.bar

Opposite of create…and does a lookahead using some JS stored within the form HTML to get a list of roles that can be deleted.  Before the openidm.delete() function is called, it clears down the members list first.

role-admins: addRoleToUserTemporal.bar

So we have a role, now we want to add some users.  Again, does a lookahead to create a dynamic select drop down, then free text to add a username.  You could add some checking logic here I guess to make sure the user exists before submission, but I wrap a conditional check in the workflow before I patch the role anyway.

The other attribute is a timer – this is just based on the Activiti Timer element and I’ve set it to take just a time.  In reality you would accept a date, but for demo’s a time is much easier.  So, after the time has been passed, the initial role to user association is reversed, taking the role away.

role-admins: removeRoleFromUser.bar

Simple manual process to remove a role from a user.  Note all the patches in the workflows work against managed/role.  Whilst you can add and remove roles from the managed/user/_id, by using managed/role endpoint, I can restrict the access the role-admins get via access.js more accurately.

openidm-authorized:requestRole.bar

We then have one workflow left – that is available to any user.  Eg it’s a standard end user workflow, and this time for an access request.

This again does a look ahead and performs an approval step before provisioning the role to the user. The default manager approval is in the workflow and remmed out alongside the ability to use any member of the role-admins authorization role.  So you can flip between the two approval journeys.

The use of role-admins leverages the Activiti:Candidate users attribute – eg role-admins could contain 10 users – the approval goes to all 10 and the first one to claim the task can approve.

A couple of points on access.  The workflow access is governed by the ../conf/process-access.json file.  In there add in the pattern of the role _id along with the internal authorization roles that should have access – note internal role and not just managed/role.

The access.js file in the ../script directory also needs updating to allow full control to the managed/role endpoint to the role-admins users.

Code for this set is available here.

Note, thanks should also go to Marek Detko and some code crib from his role collection example.

This blog post was first published @ http://www.theidentitycookbook.com/, included here with permission from the author.

Since I began working with the ForgeRock technology I have been impressed by how much you can do with it in a very short time and from what I have seen this is really underpinned by an philosophy of developer friendliness. There are lots of small features throughout the platform that are solely there to make life for implementors and developers easier.

In this series I wanted to take the opportunity to call out some of these little things that can make a big difference to your day to day experience.

Simulated Attribute Mapping

One of my favourite features in OpenIDM. Say you need to create provisioning integration with a target system. More often than not you need to manipulate or transform source attributes to achieve this.

Below you can see I have created a mapping to Active Directory in OpenIDM. This is a fairly common requirement that comes up time and again. Among other attributes, when you create an Active Directory account you need to define a Distinguished Name (DN).

I have configured the following script to generate a DN:

This is fairly simple, it just takes the userName of the user in OpenIDM and appends the rest of the desired DN as a fixed string. This is all fairly standard stuff. What is really useful, is that I can simulate the output of my DN transformation before I actually provision any accounts. To do this you just need to select an existing OpenIDM user using the Sample Source feature:

You can now see what the target output will actually look like for a given user. This is a really handy timesaver if you need to write complex mappings and enables you to quickly get a feel whether or not your transformation is correct before you have to go back and forth with failed provisioning operations against Active Directory.

This blog post was first published @ http://identity-implementation.blogspot.no/, included here with permission from the author.

Introducing OpenIDM

Overview

 ./startup.sh

 startup.bat

http://localhost.localdomain.com:8080

http://localhost.localdomain.com:8080/admin

You’ll note both pages look similar, but one is for users and one is for admins.

The default username and password for the administrator is openidm-admin / openidm-admin.

Log into the administrator interface, once you have logged in you should see the dashboard:

Over the rest of this series we will explore the functionality of OpenIDM in detail.

This blog post was first published @ http://identity-implementation.blogspot.no/, included here with permission from the author.

Overview

• User: User identities, effectively this is your central identity store.
• Role: An object for modelling roles.
• Assignment: An object for modelling assignments. Assignments are effectively ways of capturing sets of entitlements across mapping. Which can then be associated with roles.

• Users
• Organisations, divisions, teams or other parts of a business.
• Devices and hardware.
• Products and offerings.
• Anything else you can think of! Managed objects are completely configurable.

• Which organisations a user belongs to.
• The devices that a user owns.
• The products a user has.
• The teams that belong to an organisation.
• Anything else you can think of!

Objects

• Details: The name and icon that represents the object in the UI.
• Schema: Properties, their validation rules and their relationships.
• Scripts: Different hooks for running scripts throughout the object lifecycle e.g. postCreate
• Properties: Rules for special attribute behaviors e.g. passwords should be encrypted and private.

Details

Schema

• Property Name: The internal name users within the OpenIDM platform to refer to the property, think of it like a variable name only used internally.
• Readable Title: The name that will be used to refer to the property in the user interface.
• Description: Simple description of the attribute that when populated is used throughout the interface as a tooltip.
• Viewable: Can it be seen in the UI?
• Searchable: Is it indexed and searchable in the UI?
• End users allowed to edit: Used are allowed to update the value using self service.
• Minimum Length: Minimum length of the attribute value.
• Pattern: Any specific pattern to which the value of the property must adhere. e.g. date formats.
• Validation Policies: Rules that can be used to define attribute behavior. We will look at these in detail in a moment.
• Required: Must be populated with a value.
• Return by Default: If true, will be returned when user details are requested via the API. If false, will only be returned if specifically asked for.
• Type: Type of the attribute: String, Array, Boolean, Integer, Number. Object or Relationship. We will look at relationships in a moment.

Relationships

• User’s have a manager. This is a Relationship. It is in fact a reverse relationship. As manager A, has reports X,Y,Z and reports X,Y,Z have the manager A.
• User’s can also have reports. They may have multiple reports. Note this is an Array of Relationships: A manages X, A manages Y, A manages Z. Likewise this is a reverse relationship.

Scripts

1. Script – Inline Script: script defined within the UI.
2. Script – File Path: a script stored within the OpenIDM configuration directory. This is how out of the box scripts work. If you navigate to /openidm/bin/defaults/script/ui you can examine these out of the box scripts to see what they do.
3. Workflow – Event can be used to trigger a workflow.

• Encrypted: The attribute value is encrypted. This means it can be decrypted and the value retrieved if required. 
• Private: Restricts HTTP access to sensitive data, if this is true the attribute is not returned when using the REST API.
• Virtual: The attribute is calculated on the fly, usually from a script.
• Hashed: The attribute is hashed. Hashing is a one way function and the usual way that passwords should be stored. You hash the password when a user registers for the first time. When they log in again subsequently you hash the password that they enter against the original password hash. If they match you know the passwords are the same. Crucially, it is impossible to take a hash and extract the original password from it.

Managed Objects and the REST API

This blog post was first published @ http://identity-implementation.blogspot.no/, included here with permission from the author.

Overview

Connectors

Architecture

• Create: Create a new object ( usually an account ) in a target data store.
• Update: Update an existing object e.g. if a user changes their email address then we may want to update the user record in a target data store.
• Get: Retrieve a specific instance of an object ( e.g. an account) from a target data store.
• Search: Query the collection and return a specific set of results.

• Provisioner configuration: configuration data defining the connector usually containing:
  • Reference to the underlying Java class that implements the connector. This should be populated automatically when you choose your connector type. You can explore the connector source code if you like but for the most part you shouldn’t need to be concerned with the underlying classes.
  • All of the credentials and configuration needed to access the data store. You need to configure this.
  • The data store schema for the object or account. You need to configure this.

• Data Synchronization engine outputs data and a requested operation e.g. create, delete, update or one of several others
• Provisioner engine invokes the connector class with the requested operation and the data from the synchronization engine.
• Connector class uses the configuration parameters from the provisioner file and the data passed in the invocation to actually do the work and push or pull to or from the target.

Connector Example

• Header UID = id
• Header Name = username

• Header Password: We will not be processing any passwords from this CSV, that might be something you want to do, although typically you will have OpenIDM generate passwords for you ( more on that later ).
• Quote Character: If you have an unusually formatted CSV, you can change the character that surrounds your data values. This is used by OpenIDM to successfully parse the CSV file.
• Field Delimiter: Similarly if you are using a delimiter ( the character that splits up data entries ) that is anything other than a “,” you can tell OpenIDM here.
• Newline String: As above.
• Sync Retention Count: Todo

What you should be able to see if a list of all of the attributes in the CSV file. OpenIDM has automatically parsed the CSV and built a schema for interpreting the data. You may also spot “__NAME__”. This is a special attribute, and it maps to the  Header Name attribute we configured earlier.

Again, the concept of Object Type is universal to all our connectors and sometimes additional configuration of the Object Type may be required in order to successfully process data.

Finally, let’s take a look at Sync:

On this page you can configure LiveSync. LiveSync is a special case of synchronization. Ordinarily synchronization is performed through the mappings interface ( or automatically on a schedule ).

However if the connector and target system support it, then LiveSync can be used. With LiveSync changes are picked up as they occur in the target. Ordinarily with a normal synchronization ( often called reconciliation ) all accounts in the target must be examined against the source for changes. With LiveSync, only accounts in the target that have changed will be processed. For this to work the target must support some form of change log that OpenIDM can read. In systems with large numbers of accounts this is a much more efficient way of keeping data in sync.

Connectors And The REST API

As before, we can make use of the REST API here to query our new connector. We can actually use the API to read or write to the underlying CSV data store. Just take a moment to think about what that means. In an enterprise implementation you might have hundreds of different data stores of every type. Once you have configured connectors to OpenIDM you can query those data stores using a single, consistent and centralised RESTful API via OpenIDM. That really is a very powerful tool.

Let’s take a look at this now. Navigate back to the data accounts page from earlier:

Take a look at the URL:

As before, this corresponds to our REST API. Please fire up Postman again.

Enter the following URL

http://localhost.localdomain.com:8080/openidm/system/UserLoadCSV/__ACCOUNT__?_queryId=query-all-ids

You should see the following result

We have just queried the CSV file using the REST API, and retrieved the list of usernames.

Let’s try retrieving the data for a specific user:

http://localhost.localdomain.com:8080/openidm/system/UserLoadCSV/__ACCOUNT__?_queryFilter=/email eq “tgardner0@nsw.gov.au”


Here we are searching for the user with the email address tgardner0@nsw.gov.au.

 

Again, this is just a small sample of what the REST API is capable of, you can learn much more here:
https://forgerock.org/openidm/doc/bootstrap/integrators-guide/index.html#appendix-rest
And more on how queries work here:

https://forgerock.org/openidm/doc/bootstrap/integrators-guide/#constructing-queries

 

Come back next time for a look at mappings where we will join together the managed user and the connector to actually create some users in the system.

This blog post was first published @ http://identity-implementation.blogspot.no/, included here with permission from the author.