Musings on Bruno Munari thoughts

Last Sunday I was walking downtown in the historical center of Rome, and as I was strolling along the Tiber river I came across the Ara Pacis Museum. These days the exhibit area inside Ara Pacis is hosting an exhibition on Bruno Munari.
The new museum, designed by the Richard Meier architect is quite charming: I like its pristine structure that is full of light, but what really touched me was the Bruno Munari exhibition.
In fact Munari’s works and his attitude of whimsy and sheer inventive imagination were actually venerated by me when I was a kid.

From the catalog:

“Munari’s life (1907-1998) and career spanned the 20th century, and he was among the most seminal exponents of Italian design and graphic design. Yet he never received the accolades and recognition on an international scale that he so richly deserved. What sets Munari apart from other designers is that he engaged in a quiet, playful revolution, inventing and designing with humorous and modest creativity, challenging all conventions and stereotypes intelligently but without flamboyance.”

But let me tell you why I’m speaking of Bruno Munari in this blog.

Walking along the exhibit set course, I noticed some of Munari’s sentences on the walls, and among them one in particular attracted some attention:

“Progresso è quando si semplifica, non quando si complica”
“Progress is when things get simpler, not more complicated”

I like to use quotes to mix things up: in this case Bruno Munari reminds me of the aggregation (and/or acquisition) processes currently taking place in the Identity Management space.
We, as all vendors, are supporting our customers move from automating infrastructure procedures (that is meta-directory services, basic identity administration and access management) to enabling business processes, towards the satisfaction of the new requirements for Governance, Risk and Compliance (GRC).
Thus most vendors started down that path of adding new features, and new modules; often with the shortcut of specialized company acquisitions.

And the result is. ......Yes, for sure we are allowed to check the coarse grain Role checkbox in RFP's, and if the prospect asks for a POC we can always mask the mess, ..... and in parallel: let’s pump cosmetic marketing campaigns.

So if the product isn’t built, since the beginning, around a data model that is able to natively manage all processes linked to identity, role life cycles and access governance, just two alternatives are available:

• Rewriting from scratch the product around a coherent and complete data model;
• Try immediately to trim the fat, hide the complexity and hope that the discrepancy that exists will definitely be decreased in the next releases and beyond…

What is happening in the present Enterprise Role management vendor acquisition fever is quite typical.

Is it possible to really integrate an Identity Management solution with an Advanced Role Management solution? And what are the risks associated with this two-headed architecture?

I will write more about this in the next post and try to explain our idea of integrated solution that is able to natively support all the needed features in a scenario, where Advanced Role Management capabilities together with strong Authorization Management is gaining momentum

SOA and IAM are growing together

As promised in my previous post I’m introducing a new feature that adds a lot of value to our IDEAS solution: the support of SOA-based integration platform for providing a direct connection to Resource Target systems. This is the starting point for a clear commitment to SOA support, which we hope will continue to grow.
Collaboration between SOA (Service-Oriented Architectures) and Identity Management is an important requirement for many customers that have SOA based applications, and are looking for an application-wide use of identity and authorization data.

What we have done was simply to optimize the synergies with our mother company: Engineering Ingegneria Informatica (EII).
Actually EII is a strategic member and co-founder of the international OW2 Consortium. Within this Consortium, EII is particularly active on the project Spagic that aims at enlarging the OW2 Consortium code-base to support the development of business applications according to the SOA (Service Oriented Architecture) paradigm.

"Spagic is a solution composed by a set of visual tools and back-end applications oriented towards planning, realization, deploy and monitoring of ESB infrastructures adherent to the SOA paradigm. By means of visual tools, Spagic can be easily adopted by different categories of users involved in integration projects, such as: analysts defining the integration processes, developers realising application services, users monitoring and managing the entire system."

Engiweb Security has built specific components of IDEAS integrating SPAGIC (that includes ServiceMIX), in order to be able to directly support a SOA-based integration platform.
The first output is the capability to access JDBC Resource Target directly via a SOAP adapter.
Using its native JMS interface, the IDEAS platform can now exchange events with SPAGIC and on other side targets are connected to the JDBC Communication Layer provided by the SPAGIC SOA/BPM Enterprise Integration Framework.
So a customer is able to centralize the administration of user identities and their associated access privileges to corporate resources using the central IDEAS module, and using the SOA Interface it allows the synchronization of Identity/roles data with external applications that manage such information in a JDBC environment.
As a matter of fact, in this scenario a consistent state of identity information in connected external systems is provided without the need of a “traditional” resource provisioning systems (e.g. Novell’s Identity Manager connectors).

Extending the Scenario

1. We are working to integrate IDEAS with other SOA Platforms such as JBOSS-ESB and TIBCO.
2. The integration of SOA Platforms will gather in pace and importance in this coming year with the result that events coming in and out from IDEAS will be processed by an orchestration of different services and data integration oriented services, allowing for complex Business Logic implementations and collaborative activities within several Web services.

A pragmatic approach to “Virtualization”

My company, Engiweb Security, is quite small, but I think, has many strengths and is well positioned to play a vital role in the role based identity management and the GRC markets.
One of the innovative aspects that, is worth sharing is our approach to “Virtualization”. Here we don’t want to take sides in the dispute between Meta-Directories versus Virtual Directories: they are both well respected technologies and, looking at our solution IDEAS, I view these technologies as complementary. As a matter of fact we have a hybrid approach.
Most Identity related information is consolidated in the IDEAS master repository (based on a RDBMS) using specific connectors to Target Resources. But there is also an interface to other repositories to provide the required attributes without any need to move information from the existing user repository, thus providing a combined view of all user data.

In other words a sort of “Virtual Directory” or "Identity Virtualization".

The combination of the Master Repository with its strong data model behind (able to manage identity information, policies, business roles, …) and the Virtual data aggregation, allows an external application to have all the needed information to act in a secure way.
For this purpose IDEAS is equipped with API JAVA, API .NET and Web Services which permit an external application to see the required data as one data source, and recover the user security context.
So, applications might require user data that is stored non only in the central IDEAS repositories, but also in scattered different repositories (DB, directories, ..).
This approach makes it possible to keep the central repository lean, no need to fatten it if an application needs some specific data (i.e. external attributes) that are not relevant for other applications.
Furthermore some of these external attributes could also support the internal rule engine processes, where some decisions have to be taken considering specific parameters.

In the next post I’ll introduce another element that, from my point of view, adds a lot of value to our IDEAS solution: the support of SOA-based integration platform for providing a new generation of “Target Resource” connectors.

Do I have an alter ego?

A few days ago I received an e-mail from Courion Corporation: “Register Today: Sept Webinars Now Posted”. … and reading the content, I jumped.


Yes, one of the webinar title was just like the name of this blog: “Roles in Action”.

Of course I will not claim ‘firstborn’ rights. Very often in marketing you can create a catchword using a simple buzzword generator. For example, within my company we recently named a webcast: “Role Management: unlock the complete value of Identity Management, take full control over Compliance”. Not very original, is it?

Anyway, I am looking forward to this webinar. I hope that Courion speaker, Chris Sullivan, will agree with my blog subtitle: “Roles can’t be built in a day”.

No man is prophet in his own country

An Italian crazy approach to Identity Management projects

Preliminary remarks

1. An Organization is launching an Identity Management Project where almost 80% of the foreseen IM processes require an authorization workflow.
2. The Organization has selected an IM technology platform
3. However, the requirements are so complex that it isn’t possible to meet them just with a customization of the web application of the vendor’s IM product
4. Furthermore it is the Organization itself that suggests custom developments for the web application.
5. … thus almost 80% of the IM project requires ex-novo software developments
6. What a crazy world!!

Actual Story
We just received an Identity Management (IM) RfP from a large Italian company.
It seems that they have already done an internal technical evaluation, as they are asking mainly a system integration effort based on Oracle Identity Manager product.

From the RfP, translated from Italian: “(the company) wants to equip itself with an Identity Management system for supporting: the digital identity management processes, the software applications and other platforms authorization processes. To this end (the company): has identified in the Oracle Identity Manager product the technology to be used for implementing the system, has carried out a feasibility analysis, and has defined constrains and requirements for the implementation”.

Thus, just a system integration effort. They have done a rigorous vendor selection, and verified the feasibility of the project using the selected product.

Ok, fine, … but uhmm… they also want to develop new custom clients for specific functionalities not available from Oracle Identity Manager Web Application.

As a matter of fact, they have expressly invited the bidder not to customize the web application interface of the Oracle Identity Manager Administrative and End-User Console, but to implement the web interfaces using a “custom client” approach, i.e. a SW development based on Oracle Identity Manager Software Developer Kit (API).

Again from the RfP:

• “From the (Company) requirements analysis, we want to draw bidder's attention to the following set of remarks pertaining to the requests management:
• Roles (User Manager, Authorization Steward, Operator) of all users involved in a request approval process, need to have different scopes (or views), based on resource object attributes that represent the requested resource. For instance the User Manager doesn’t need to access fields like account identifier; this field, on the contrary, must be set by the AM function that creates the account on the target system. The first access password should be set by AM, displayed for the end user, not available by any other, and so on…”
• A fill-in request process must be guided by specific wizards aimed at effectively supporting the end user. For instance a User Manager that wants to grant the access to an Application for one of his collaborator, must first of all select the user from a predefined list of all his collaborators. Then he must be able to select the application and related profile. The system must be able to guide him, by offering the standard profile (or in case, a list of standard profiles) associated both to the selected application and to the end user belonging Organization Unit.
• ……..........
• A user must be able to submit a request for modifying his assigned profile for application authorization, but the present release of Oracle Identity Manager doesn’t allow out-of-the-box to implement workflow for approval of modify requests of resources attributes already assigned to users.”

The questions is:

• Does exist a product out there able to manage, out-of-the-box the above listed features, or at least able to provide a rich, exhaustive support for these functionalities?

Disclaimer
Yes, Engiweb Security can help with most of the above described missing features. For instance, reading from Engiweb Security IDEAS brochure:
“Administrator scope dynamic association in workflow processes. It is often necessary that workflow figures (delegated or peripherals administrators) have a limited scope both for users (only certain OU users) and Applications (i.e. this administrator only approves profile requests that belong to a specific application).”
There is no reason for me not to talk about it! ...but in short: is there someone who is interested? (certainly nobody in Italy).

Postscript
As soon as I ended this post, I discovered that some bloggers are discussing on FACTs and FUDs here and here.
The above described example well fits into the discussion.
We are a vendor used to face behemoths like ORACLE and SUN. In this post the Oracle products were mentioned, but I can give examples on SUN too. As the saying goes “People who live in glass shouldn’t throw stones!”

How to add "intelligence" to IAM

One of my colleagues just finished up a White Paper that is worth reading: “Let the Good Times Roll: Role Management for Enterprises Is Possible“.
The paper tries to explain how to add “intelligence” to a “classic” IAM solution. It also collects some concepts and examples I have already touched on in this blog.

Here is an excerpt addressing on the concept of Application.

In a large Organization environment there are many "Applications” managing both authentication and authorisation using (for instance) Active Directory groups.
In this context, with a single technological target (AD) connected to the IAM, there are multiple, associated “Applications”. On that level, into IAM environment, “target system” is a technology concept, whereas "Application” is a IAM business concept.

Note that in this context "Application" can be seen as a resources container (in this case AD groups).
Even AD groups set, used for users “Infrastructural” access, could be seen as an "Application". Following this point of view, we can group the “Infrastructural Resources” groups set (Internet, Mail OWA, VPN, FTP etc..) in a container (Application) and give it a name. (e.g. Infrastructure Resources).

This “Application” concept is very important in an IAM environment. Through “Applications” many administrative processes can be easily managed. Especially so are such processes where the “Target” concept does not fit because it is not expressive enough, and the “Resource” concept does not fit because it has too little granularity.
Some examples are:

• Application is a Business language while “Target” or “Resource” are technical languages.
• Dynamic management of IAM administrators “scope” on specific applications (an administrator can only approve requests referring to specific “Applications”).
• Policy writing is much more expressive and simple if referring to Applications instead of always identifying a set of resources.
• Event grouping under an Application is extremely expressive both from operational and auditing aspects.

Most IAM tools refer to technological concepts such as Targets or simple Resources thus resulting in a very low expressivity and administrative complications.
If you want to introduce the Application concept where it is not “out-of-the-box”, you must analyze the impact, define data model and implement all business intelligence associated with the concept.
Instead, with a tool natively supporting this data model, processes implementation related to this concept are direct and prompt.
Referring to the above Active Directory example: with IDEAS by Engiweb Security, once the Active Directory technological connector is created, the creation of an "Application”, its relative “Resources” association and connection to the reference “Target”, is really simple.

Only a few parameters need to be defined, such as:

• Target.
• Synchronisation Options (Automatic, Manual NoSync). It is interesting to note that native Applications management, based on “Sync. Options”, make the synchronisation chain work in a different way. In fact, in the case of Automatic Sync, if a user is assigned an Entitlement or a Role which includes a resource from this application (e.g. an AD group), the system generates an outbound event towards the connector which automatically associates the group with the user. On the contrary, Manual Sync generates an event which is retrieved from a file to run a Batch Synchronisation (everything out-of-box).
• Resources connected.

A new webcast on Role Management

If you are interested in Role Management and in particular in Engiweb Security’s approach to this business issue, you can tune in to a new webcast featuring Roberta Witty - Gartner Research VP, Richard Parisi - Engiweb Security International Customer Support and Alberto Ocello - Engiweb Security General Manager.

For registration to this webcast, click here.

An Italian clichè

A friend of mine sent me an e-mail with a ppt file attachment. It was in Italian, but the translation in English was easy. It was a joke on an Italian cliché, but it was a great illustration of a common Identity management nightmare: role explosion!

Yes, at least in Italy, most customers we work with are very clever at imagining every level of nuance when “theoretically” defining roles in their organization.

But fortunately, we are used to facing their anarchy and we know how to prevent the awkward problem of “role explosion”.
As the picture says, to survive we have been forced to take adequate countermeasures. For example the waitress can simplify the orders by requiring the customers to add their own sugar, milk, liquor, etc. Therefore, by restricting the number of kinds of coffee, requests are delivered in a timely manner while maintaining flexibility.

So, business managers, don’t be afraid: just select the right tools and adopt the appropriate methodology!

New Technical Paper on Role Mining

A new Technical Paper, “Leveraging Lattices to Improve Role Mining”, has been recently accepted and will be presented at the coming SEC 2008 23rd International Information Security Conference, co-located with IFIP World Computer Congress 2008, Milan, Italy, September 8-10, 2008.
Topics of interest of this conference include, but are not limited to:

• Access control
• Security and Content Policies
• Role Mining
• Security Compliance
• Identity and Trust Management

The paper highlights some crucial aspects on which Engiweb Security “IDEAS Role Constructor” module is based.

Abstract:
“In this paper we provide a new formal framework applicable to Role Mining algorithms.
This framework is based on a rigorous analysis of identifiable patterns in access permission data. In particular, it is possible to derive a lattice of candidate roles from the permission powerset.
We formally prove some interesting properties about such lattices. These properties, a contribution on their own, can be applied practically to optimize role mining algorithms. Data redundancies associated with co-occurrences of permissions among users can be easily identified and eliminated, allowing for increased output quality and reduced processing time.
To prove the effectiveness of our proposal, we have applied our results to two existing role mining algorithms: Apriori and RBAM. Application of these modified algorithms to a realistic data set consistently reduced running time and, in some cases, also greatly improved output quality; all of which confirmed our analytical findings.”
Authors: Alessandro Colantonio, Roberto Di Pietro, Alberto Ocello

Nice, Friends!, But, pardon me if I find much more pleasant another kind of Lattice: A nice piece of the Rhubarb-Strawberry Lattice Tart really hits the spot!

BTW if you are interested in receiving the full text, please send me an e-mail: my surname at eng dot it.

Inconsistency: the revenge

Before going on to introduce the second inconsistency case study, I just want to stress again that we are not speaking of a sort of “event manager” that monitors the activities performed directly on targets and blocks any possible operation. Here we are introducing a solution (part of a Governance and Compliance framework) that intelligently tries to understand if this operation could be accepted, taking into account presently enforced security policies. As a matter of fact, the realistic situation we are facing is the typical end-user’s requirement for additional access to another application (target). The official way (e.g. following a workflow) is not fast, so he calls his friend that works in the IT administration and bypasses the official procedure, quickly achieving access to his coveted application.

Previous episode: IAM System - Targets inconsistency policies: remove
There is not way to prevent someone (a naive “authorized” administrator ) from removing Profile1 from user John on target1.
Meanwhile, the IAM system must assure a single centralized record of reference, even if the IAM administrator is gambling poolside at Vegas with his new intelligent mobile phone…
To be more clear, take a look at the following diagram:


This Latest Episode: IAM System - Targets inconsistency policies: add!
As already anticipated, if the Administrator, again directly on a target, adds a profile to John, this would be even more difficult to manage as there could be a huge impact on Separation of Duty verification.

Actually managing the already described “remove” scenario, means assuring Security Policies, even if the operation ability of the “involved” user could be somehow diminished, but when the unaware user (John) gets a new profile with a direct action on the target, no preventive compliance control is performed and the real danger could be: Security breaches, failed audits, non-compliance, all the way up to fraud.

One again a sound IAM solution should effectively manage the risks associated with such a scenario, with the objective of assuring compliance with the least operational impact.

The following diagram explains how the Engiweb Security solution (the IDEAS suite) deals with this inconsistency (the offset between the IDEAS core repository and a generic target system) and how the Inconsistency Role Engine goes to work to repair the offset.

In this case, an authorized administrator accesses target1 and adds Profile1 to user John.

If the policies are set to try and accept the profile addition if possible, the first check is performed using a Segregation mechanism on the base OU. A profile is available for assignment to a user belonging to a certain OU only if “visible on that OU”. In this situation, particular profiles having some criticality can be “hidden” to OU’s that do not have the so-called “need to know”.

A second mechanism, used in the next checks, performs profile and role incompatibility management. This mechanism is supported by a powerful incompatibility SoD engine able to make run-time checks on a pre-assigned conflict matrix and contextual information. The system also contains a Role_Policy_Definition module which, starting from high-level incompatible activities, helps the administrator define a matrix of conflicting profiles.

Illegal roles and incompatible role-pair lists are also used by the IDEAS Profile Provisioning for other run-time SoD checks during user provisioning compatibility control. The SoD engine is queried for each new role assignment request. If assigning the role makes the user illegal, different authorization workflow steps can be executed.

Yes, in this case our IAM administrator can spend some more time poolside at Vegas undaunted by any notifications he may receive on his new intelligent mobile phone regarding of what’s happening at work!

IAM System - Targets inconsistency policies

I’m joining Matt Flynn discussion on “Extending the ROI on Provisioning”, where he highlights an intriguing problem: how to manage direct modifications on the targets, where a IAM solution is in charge of providing approval workflow, synchronization, compliance, etc..…

Yes. Most organizations we work with are quite concerned about managing direct access to target resources, getting around workflows and central management (e.g. a profile assignment to a user directly on a target).

They confirm that despite all the precautions, it is always possible for inconsistencies to be created in their IT systems, causing authorization misalignments between the target systems and the IAM system.
Moreover, it is not possible to automatically classify and correct in advance all types of inconsistencies that can occur. However, it is certainly possible to provide a tool to detect and manage misalignments.

In our solution (the IDEAS suite), this problem is referred to as "Inconsistency Management". Within IDEAS' internal multilayer model, such actions can lead to the modification of many relations with decisions depending on many factors that must be shaped into appropriate policies.
Thus, whenever an inconsistency occurs (an offset between the IDEAS core repository and a generic target system) the Inconsistency Role Engine goes to work to repair the offset.

But what is the meaning of repairing?

Often there are difficult decisions to be made.

For instance, an authorized administrator accesses target1 and removes Profile1 from user John. Unfortunately Profile1 was assigned to John via a higher level Role: "Role1", which is actually composed of many other profiles on several targets (including of course Target1). Thus how should the IAM solution react?

The simplest policy could be to state that the central system is authoritative and thus everything must be reset back to original settings.
Another alternative policy could state that if the administrator is trusted, the modification must be accepted. But in the central repository of reference, John is assigned Role1, NOT Profile1. So alignment could mean the following:

• remove the entire Role1 from John, or
• verify if there is another available Role composed of all Role1 profiles except Profile1 (e.g. name this Role 2). If so, remove Role1 from John and assign Role2. If Role1 is part of a hierarchy and a lower level Role without Profile1 is available, it could be possible to assign this Role to John instead of Role1. In this case, while there is no impact on compliance, there could be a possible limitation on user access rights
• Notify the relevant people (e.g. IAM administrator, Role1 owner and all actors involved in Role1 authorization workflow, etc..) that there is an offset between the central DB and the target. The policy could state that if there will be no remediation activities within a defined time period, the original settings will be restored.

If the Administrator, again directly on a target, adds a profile to John, this would be even more difficult to manage as there could be a huge impact on Separation of Duty verification. I'll try to write a specific post on this item very soon.

P.S: IDEAS ( IDEntity and Access management Suite) is a solution addressing the full gamut of Enterprise Role Management needs in multiple IdM solutions.

“User lock/unlock” management scenario

In my previous post I was raising doubts about the fact that implementing lock/unlock account procedure might not be so easy. Here I’m trying to explain why.

Preliminary remarks: although this requirement is rarely present in IAM project RfP’s, it is obvious that any large organization already has a procedure disciplining the user lock/unlock processes. Let’s try to imagine it in detail.

A user can be locked for various reasons. For example:

1. Technical lock (a user is locked because he or she has exceeded max wrong passwords or due to extended inactivity).
2. Administrative lock (specific events coming from HR determine a temporary or definitive user lock i.e. maternity leave or grace period before expiration).
3. Security lock (a user is locked by a security manager).

It is also obvious that unlock procedures must follow hierarchy rules, such as:

1. A Technical lock on a user can be removed by any administrator (Head of Unit, Help desk etc..).
2. A Security lock on a user can only be removed by a Security Officer.
3. An Administrative lock on a user CANNOT be removed by any administrator. His or her unlock is determined only by an HR event (return after long leave or expiration interruption etc..).
4. To complete complexity, if a user’s Security or Administrative lock is directly removed by the target (e.g. using AD console), then the IAM system must react in real time by resetting the unlock.

These processes must be managed by the IAM system since access systems (e.g. MS Active Directory) do not have the “intelligence” for this purpose and therefore cannot “assist” such management.
If this type of requirement, even though not particularly complex, is not directly supported by the tool’s data model, a custom development consisting of "data model” definition managing would be required.
The data model shall support data, relations between them and other already available data as well as necessary developments to implement policies.

In conclusion:

• When the product data model itself already supports these processes, mapping of the said process is reduced to pure and simple configuration in no time. Maintenance and changes are made by high level administrators
• In case native support is not available, the following should be expected: detailed technical specification definition, Data Model updating, policy writing (usually at low level) and tests, changes, complex management, etc….

RBIA: The Great Unknown

An Identity and Access Management project is not always an easy job. It is very difficult to describe in few words why, but one reason for sure is that in the IAM environment procedures are always more important than technology. In other environments, (e.g. Document Management), technology can drive procedures, thus the right technology choice is the most important aspect.

Conversely, in the IAM environment it is quite impossible to find customers willing to change procedures because technology is unable to map these procedures into the product (or achievable only with huge software customisation). Procedures are important and relevant processes have to be mapped into technology without compromises.

On the flip side of the coin, there is another aspect to consider.
AM technology is still evolving. Most “official” IAM technology vendors are coming from the User Provisioning environment; in essence, coming from the bottom. Pure technology. Of course vendors are adding features trying in attempts to raise the bar but they are still conditioned by original sin – They want to add intelligence to technology instead of adding technology to intelligence.

Intelligence, as in many other IT contexts, is represented mostly by the conceptual model standing behind the product and a data model representing the conceptual model.
The secret of product “intelligence” lies in the conceptual model and its relevant data model.
Technology features like a beautiful, rich graphical interface for workflow design or the huge standard support are all important aspects, …. but I suggest that customers intending to acquire an IAM solution verify how complex it could be to implement simple procedures (e.g. user lock/unlock levels or procedure). It turns out to be a mess with customized software development and the writing of many, many technical policies: even if within a nice graphical environment.

This situation has encouraged the founding of companies who start from RBAC and progressively enrich the model to reach complete RBIA (Role based Identity Administration).
The RBIA model intends to integrate all concepts of User Management (including Credential Management), Role Management, Role Engineering, SOD compliance, Audit and Reporting all the way up to Unified Identity Approach, in order to unify Logical and Physical Access Management views.

According to my understanding, customers’ important expectation of an IAM project that easily supports present and future Identity Management procedures and processes, indicates that a field proven RBIA product is a “must”.

Addition of RBIA functionalities could result in an increase in license costs with respect to the budget sum. However, in our experience, this is greatly offset by tremendous savings of time and cost of project implementation along with a heavy reduction of project risks.

BTW, in a following post I’ll try to justify why implementing a lock/unlock account procedure might not be so easy.

Power is nothing without control

As Italian tyre giant Pirelli's advertising reminds us, "Power is nothing without control." But managing identity, roles and access control is often worthless or at least can be a nightmare without the right tools and handling ability.

Last Monday (yes January the 2nd, during Christmas holidays which, in Italy, officially end on January 6th), one of our largest customers decided to activate a complex internal shake-up.
The reorganization consisted of selling-off one of their companies and merging several internal divisions to form new companies. To summarize, 700 new Business Units (out of 20000) were created, and more than 8500 users (out of 85000), mainly employees, were reassigned with modified business responsibilities and access rights.

Of course the IAM system is directly linked to the company HR system, and role management is integrally aligned with identity management. The solution is quite HR-oriented, incorporating business structure and responsibilities. The viable Role management solution addresses resource/responsibilities association and SoD, and is supported by 3 rule engine environments which implement administrative and security policies.
Since HR is directly connected to the IAM systems, each modification in the HR system usually activates an update in the Role management internal repository. The Resource-Provisioning functions then start synchronizing with the relevant target systems (SAP R/3, AD, etc).

Do they like the automatism advantage of such an IM implementation?
The answer is yes and no. In general, if the operation exceeds a certain complexity threshold, the customer wants full control over all the complete chain of input and output events. As this was the case, they wanted to verify, ahead of time, the impact of this complex reorganization.

Specifically, HR modifications instantly affected the model within the Role/IM infrastructure, but the customer deactivated resource provisioning. They wanted more time to evaluate the final reorganization results. Analyzing the new organization model within the IM repository was sufficient enough to evaluate these effects.

Since they were quite concerned about the number of users to be removed across the several targets, they blocked the massive HR-driven operations and then printed a specific report listing users to be removed along with the action type and justification (reason) codes.

This helped them determine whether or not the HR input was correct and if the policies implemented had any bugs. As it turned out, they discovered that a policy rule was, in fact, not well written.

Even though this all happened during Christmas holidays, they used the tools available inside the Role management infrastructure without any intervention from the System integrator.

Of course, while the HR operations were blocked during the analysis, all modification on roles and business responsibilities arriving from the authorization workflow carried on as normal, including the activation of modifications on the targets via Resource Provisioning modules.

Again, as Pirelli’s mantra goes: power is nothing without control…