Open Identity Tech Talks 2016 – Asia Pacific

ForgeRock is hosting the 2016 Asia Pacific Open Identity Tech Talks. To join these informal conversations on latest trends in digital identity tech, across apps, devices and connected things register at the URL as mentioned below. Hurry up, the seats are limited!

Open Identity Tech Talks 2016 – Asia Pacific

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

Addendum to ForgeRock Full Stack Configuration – Using ForgeRock OpenIG

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

AddendumToFullStackConfiguration

Now on to the video.Enjoy!

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

OpenDJ: Uploading a photo over REST

ForgeRock LogoOpenDJ REST to LDAP is based on ForgeRock common REST. ForgeRock common REST handles HTTP multipart requests, so you can upload binary data, such as JPEG photos. This blog entry demonstrates how to upload a JPEG photo as a patch using the curl command.

Before you start, set up OpenDJ server and configure HTTP access to sample directory data, as described in the OpenDJ server dev guide chapter on Performing RESTful Operations. To follow the example below, make sure you have imported data from Example.ldif and that you can read Babs’s resource over HTTP as shown in the documentation.

As of this writing, the default configuration for OpenDJ REST to LDAP does not include a mapping for a user’s jpegPhoto attribute, so you must add a mapping. To add the mapping, edit the "/users" attributes section in the configuration file /path/to/opendj/config/http-config.json to include a "photo" property in user resources. The following line adds a simple mapping from the "photo" property to the jpegPhoto LDAP attribute:

"photo" : { "simple" : { "ldapAttribute" : "jpegPhoto", "isSingleValued" : true } },

When finished, save your changes and restart OpenDJ server or at least the HTTP connection handler to have the connection handler reread the updated configuration file:

/path/to/opendj/bin/stop-ds --restart

To test your changes, copy a JPEG photo to picture.jpg in the current directory and patch Babs’s resource to add the photo:

curl 
 --request PATCH 
 --form 'json=[{"operation": "add", "field": "/photo", 
         "value": {"$ref":"cid:picture#content"}}];type=application/json' 
 --form 'picture=@picture.jpg;type=image/jpeg' 
 'http://bjensen:hifalutin@opendj.example.com:8080/users/bjensen'

The result of the operation should be Babs’s resource with the photo a (potentially very long) base64-encoded string:

{
	"_id": "bjensen",
	"_rev": "00000000160694db",
	"schemas": ["urn:scim:schemas:core:1.0"],
	"userName": "bjensen@example.com",
	"displayName": "Barbara Jensen",
	"name": {
		"givenName": "Barbara",
		"familyName": "Jensen"
	},
	"photo": "_9j_4RZJRXhpZg...AA",
	"manager": [{
		"_id": "trigden",
		"displayName": "Torrey Rigden"
	}],
	"contactInformation": {
		"telephoneNumber": "+1 408 555 1862",
		"emailAddress": "bjensen@example.com"
	},
	"meta": {
		"lastModified": "2016-03-22T09:13:23Z"
	}
}

Notice the curl command form data. When you specify the reference to the content ID, the reference takes the form:

{"$ref":"cid:identifier#(content|filename|mimetype)"}

If you want other attributes to hold the filename (picture.jpg) and MIME type (image/jpeg) of the file you upload, you can reference those as well. In the example above, {"$ref":"cid:picture#filename"} gets picture.jpg and {"$ref":"cid:picture#mimetype"} gets image/jpeg.


ForgeRock OpenAM – Configuring Different Realms to Use Different BaseDNs of an OpenDJ Instance as Identity Repository

The short video log that follows was prepared to answer a question raised in the Forum on the ForgeRock Community Website. It’s an easy one on how to configure two separate BaseDNs of a single ForgeRock OpenDJ instance as Identity Repository for two separate Realms in ForgeRock OpenAM.

Enjoy!

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

OpenDJ LDAP Directory Services update

FR_plogo_org_FC_openDJ-300x86The new version of ForgeRock Directory Services, based on OpenDJ 3.0, was released in January and I’ve already written about the new features here, here and here.

We’ve now started the development of the next releases. We’ve updated the high level roadmap on our wiki, to give you an idea of what’s coming.

The last few weeks have been very active, as you can see on our JIRA dashboard.

Screen Shot 2016-03-18 at 10.56.12

There are already a few new features and enhancements in the master branch of our GIT repository :

A Bcrypt password storage scheme. The new scheme is meant to help migration of user accounts from other systems, without requiring a password reset. Bcrypt also provide a much stronger level of security for hashing passwords, as it’s number of iteration is configurable. But since OpenDJ 2.6, we are already providing a PBKDF2 password storage scheme which is recommended over Bcrypt by OWASP, for securing passwords.

Some enhancements of our performance testing tools, part of the OpenDJ LDAP Toolkit. All xxxxrate tools have a new way of computing statistics, providing more reliable and consistent results while reducing the overhead of producing them.

Some performance enhancements in various areas, including replication, group management, overall requests processing…

If you want to see it by yourself, you can checkout the code from our GIT repository, and build it, or you can grab the latest nightly build.

Play with OpenDJ and let us know how it works for you.


Filed under: Directory Services Tagged: build, directory-server, ForgeRock, java, ldap, opendj, opensource

Scripted SQL Connector in ForgeRock OpenIDM 4

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!

ForgeRock doc tools 3.2.0 released

ForgeRock Logo ForgeRock doc tools 3.2.0 were released today.

This is a minor release, compatible with earlier 3.x releases, with one small exception. See the release notes for details.

ForgeRock doc tools 3.2.0 includes the following components:

  • forgerock-doc-maven-plugin
  • forgerock-doc-common-content
  • forgerock-doc-default-branding

This release brings several improvements and squashes a few bugs.

Big thanks once again to Chris Lee for enhancements to the Bootstrap-styled HTML (the default for draft, in-progress docs to read when trying nightly builds), for identifying problems, and for help debugging.

Thanks also to Joanne Henry, Lana Frost, Lori Goldman, David Goldsmith, Gene Hirayama, and Mike Jang for testing and bug reports.


In flight Authorization Management

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
Triggering a remote workflow (step 3) is pretty trivial – simply call /openidm/workflow/processinstance?_action=create with the necessary workflow you want to trigger.  To work out who to assign the workflow to, I leveraged the new relationship management feature of IDM and used the execution.setVariable(‘approver’, approver) function within the workflow.  The approver was simply an attribute within my initial user object that I set when I created my managed/object.

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