Certification in ForgeRock OpenIDM – Concluding Episode

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

This blog entry picks up from my earlier blog post around Certification facility in ForgeRock OpenIDM. Like many of my other video demonstration, this one also is based on the neat ForgeRock documentation on OpenIDM. So without any further ado, let me present unto you my video log on Certification in ForgeRock OpenIDM.


Certification in ForgeRock OpenIDM Episode I: Initial Reconciliation

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

If this was a book, what we have here is a prologue. Just as you don’t expect the prologue to throw a full story at you, so does this web log unveil absolutely no details around Certification in ForgeRock OpenIDM. What it does though is to setup a ‘plot’ for a possible video demonstration on Certification facility in ForgeRock’s Identity Management Solution. And that’s coming soon…

So in the video log, that’s actually a visual representation of the brilliant ForgeRock Documentation on OpenIDM, you’ll see:
– Installation of ForgeRock OpenDJ
– Configuration of OpenDJ as an external resource managed by OpenIDM (using sample files)
– Performing the initial reconciliation using REST to load users from OpenDJ to OpenIDM

Soon we’ll put all those users in action for Certification in OpenIDM. For now, just as you’d skim through the prologue of a book, take a quick look at the ~5 minute video

Who Has Access -v- Who Has Accessed

The certification and attestation part of identity management is clearly focused on the 'who has access to what?' question.   But access review compliance is really identifying failings further up stream in the identity management architecture.  Reviewing previously created users, or previously created authorization policies and finding excessive permissions or misaligned policies, shows failings with the access decommissioning process or business to authorization mapping process.

The Basic Pillars of Identity & Access Management

  • Compliance By Design
The creation and removal of account data from target systems falls under a provisioning component.  This layer is generally focused on connectivity infrastructure to directories and databases, either using agents or native protocol connectors.  The tasks, for want of a better word, are driven either by static rules or business logic, generally encompassing approval workflows.  The actual details and structure of what needs to be created or removed  is often generated elsewhere - perhaps via roles, or end user requests, or authoritative data feeds.  The provisioning layer helps fulfill what system level accounts and permissions need creating.  This could be described as compliance by design and would be seen as a panacea deployment, with quite a pro-active approach to security, based on approval before creation.
  • Compliance By Control
The second area could be the authorization component.  Once an account exists within a target system, there is a consumption phase, where an application or system uses that account and associated permissions to manage authorization.  The 'what that user can do' part.  This may occur internally, or more commonly, leverage an external authorization engine, with a policy decision point and policy enforcement point style architecture.  Here there is a reliance on the definition of authorization policies that can control what the user can do.  These policies may include some context data such as what the use is trying to access, the time of day, IP address and perhaps some business data around who the user is - department, location and so on.  These authorization 'policies' could be as simply as the read, write, execute permission bits set within a Unix system (the policy here is really quite implicit and static), or something more complex that has been crafted manually or automatically and specific to a particular system, area and organisation.  I'd describe this phase as compliance by control, where the approval emphasis is on the authorization policy.
  • Compliance By Review
At both the account level and authorization level, there is generally some sort of periodic review.  This review could be for internal or external compliance, or to simply help align business requirements with the underlying access control fulfillment layer.  This historically would be the 'who has access to what?' part.  This would be quite an important - not to mention costly from a time and money perspective - component for disconnected identity management infrastructures.  This normally requires a centralization of identity data, that has been created and hopefully approved at some point in the past.  The review is to help identify access misalignment, data irregularities or controls that no longer fulfill the business requirements.  This review process is often marred by data analysis problems, complexity, a lack of understanding with regards to who should perform reviews, or perhaps a lack of clarity surrounding what should be certified or what should be revoked.

SIEM, Activities and Who Has Accessed What?

One of the recent expansions of the access review process has been to marry together security information and event monitoring (SIEM) data with the identity and access management extracts.  Being able to see what an individual has actually done with their access, can help to determine whether they actually still need certain permissions.  For example, if a line manager is presented with a team member's directory access which contains 20 groups, it could be very difficult to decide which of those 20 groups are actually required for that individual to fulfill their job.  If, on the other hand, you can quickly see that out of the 20 groups, twelve were not used within the last 12 months, that is a good indicator that they are no longer required on a day to day basis and should be removed.

There is clearly a big difference between what the user can access and what they actually have accessed.  Getting this view, requires quite low level activity logging within a system, as well as the ability to collect, correlate, store and ultimately analyse that data.  SIEM systems do this well, with many now linking to profiling and identity warehouse technologies to help create this meta-warehouse.  This is another movement to the generally accepted view of 'big data'.  Whilst this central warehouse is now very possible, the end result, is still only really trying to speed up the process of finding failures further up the identity food chain.

Movement to Identity 'Intelligence'

I've talked about the concept of 'identity intelligence' a few times in the past.  There is a lot of talk about moving from big data to big intelligence and security analytics is jumping on this band wagon too.  But in reality, intelligence in this sense is really just helping to identify the failings faster.  This isn't a bad thing, but ultimately it's not particularly sustainable or actual going to push the architecture forward to help 'cure' the identified failures.  It's still quite reactive.  A more proactive approach is to apply 'intelligence' at every component of the identity food chain to help make identity management more agile, responsive and aligned to business requirements.  I'm not advocating what those steps should be, but it will encompass an approach and mindset more than just a set of tools and rest heavily on a graph based view of identity.

By analyzing the 'who has accessed' part of the identity food chain, we can gain yet more insight in to who and what should be created and approved, within the directories and databases that under pin internal and web based user stores.  Ultimately this may make the access review component redundant once and for all.

By Simon Moffatt