Why do you not need a provisioning solution?
In this world of compliance driven provisioning implementation sometimes it may be worthwhile to really think about whether you need a provisioning solution in place. If the requirement is completly driven by the compliance, then how can provisioning solve the issue. Provisioning, most of the time, gives the idea that after implementation, company is going to create user accounts based on the Company's security standards and practices. But it does not provide by its very nature any way to stop rogue administrators from creating accounts, perform operations using that account and then deleting those accounts before the next reconciliation cycle. So it seems that from that point of view only feature that is of any benefit to the compliance driven implementation is provisioning product's ability to reconcile reosurce accounts (either real time or as scheduled task) in conjuction with a policy driven compliance enforcer (that most of the provisioning products are coming out with) which validates the information based on the defined policies.
If the requirement do surround the compliance then the implementation should completely be setup using audit log monitoring and alert products which then again goes to the idea that for that you do not need any provisioning product and instead a multitude of agent which have been installed as part of various security/monitoring initiatives in conjunction with existing BI/reporting products can be leaveraged for achieving the same result. With regards to that the idea would be to develop a good auditing infrastructure (which most of the products come built with) along with a good audit log aggregation and analysis system using some of the existing reporting and/or business intelligence products in the market. This may be better than implementation of provisioning products most of which are fairly new and immature in terms of these technologies.
Besides the incompatibility of compliance with provisioning products, another important aspect is its incompatability with the mordern 'SOA initiatives'. The SOA initiatives are based on the basic idea that access to a service is only through a very well defined interface accessible over well known protocol (like HTTP or Messaging Service). This allows the owner of the systems to create a very well defines interface as per business requirements instead of depending on interfaces provided by native products that they use. So going ahead the directory service group need not allow users to add, delete or modify entry directly into the LDAP. Instead they can provide a simple interface to do that then based on the internal directory structure, the interface will add the information into appropriate location. This allows the abstraction of the entire schema, tree structure and provides a more business centric view (vs technological view) of the service. As these SOA initiatives gain ground and start to grow (especially in this era of IT service outsourcing), it may not be a very crazy idea to stop using a technical interface (like APIs, LDAP protocol, etc) and start using the standards base interfaces (except when all the components are owned by single group or for performance/QOS considerations). In case such a world where the interface to these systems will be standard (to start of within company), the strength of the provisioning product in terms of adapter simply vanishes and we are left with an implementation that has a not so good workflow, rules engines and limited use of huge set of adapters which are not of much use.
Think about that!!
If the requirement do surround the compliance then the implementation should completely be setup using audit log monitoring and alert products which then again goes to the idea that for that you do not need any provisioning product and instead a multitude of agent which have been installed as part of various security/monitoring initiatives in conjunction with existing BI/reporting products can be leaveraged for achieving the same result. With regards to that the idea would be to develop a good auditing infrastructure (which most of the products come built with) along with a good audit log aggregation and analysis system using some of the existing reporting and/or business intelligence products in the market. This may be better than implementation of provisioning products most of which are fairly new and immature in terms of these technologies.
Besides the incompatibility of compliance with provisioning products, another important aspect is its incompatability with the mordern 'SOA initiatives'. The SOA initiatives are based on the basic idea that access to a service is only through a very well defined interface accessible over well known protocol (like HTTP or Messaging Service). This allows the owner of the systems to create a very well defines interface as per business requirements instead of depending on interfaces provided by native products that they use. So going ahead the directory service group need not allow users to add, delete or modify entry directly into the LDAP. Instead they can provide a simple interface to do that then based on the internal directory structure, the interface will add the information into appropriate location. This allows the abstraction of the entire schema, tree structure and provides a more business centric view (vs technological view) of the service. As these SOA initiatives gain ground and start to grow (especially in this era of IT service outsourcing), it may not be a very crazy idea to stop using a technical interface (like APIs, LDAP protocol, etc) and start using the standards base interfaces (except when all the components are owned by single group or for performance/QOS considerations). In case such a world where the interface to these systems will be standard (to start of within company), the strength of the provisioning product in terms of adapter simply vanishes and we are left with an implementation that has a not so good workflow, rules engines and limited use of huge set of adapters which are not of much use.
Think about that!!
Comments