Building metrics to decide how and whether moving to IDaaS means considering what variables and strategy have to be taken into account when organizations subscribe identity as a service contracts. Before moving any IdM to the Cloud, organization should balance costs and risks. Accordingly, metrics adopted should be enough flexible to be applied from both a company that is developing an IdM system and a company that already has a IAM in operation but is considering to move the ID to the Cloud. The metric introduced below is included into a coming IDaaS Best Practices helping companies to understand, evaluate and then decide if and how moving ID to the Cloud.
IDaaS: Measure Maturity
IDaaS metric definition starts from on-premise IdM/IAM acquisition and implementation costs. Take into consideration the following parameters:
1) COSTS – IdM/IAM costs are mainly based upon Infrastructure, Personnel, Administration (Access, Help desk, Education/Courses, ..), Attestation and Compliance (including personnel certification and upgrading), Business Agility expenditures;
2) RISKS – Risks are based upon expenditures to cover by order:
2.1 Implementation risks (the risk that a proposed investment in technology may diverge from the original or expected requirements);
2.2 Impact risks (the risk that the business or technology needs of the organization may not be met by the investment in the IAM solution, resulting in lower overall total benefits);
2.3 System protection (perimeter defence, audit and surveillance).
The risk/confidence the company is dealing with depends mainly upon the combination of:
– IAM maturity, in terms of implementation, maintenance and evolution capacity;
– SOA maturity, to really understand policies by applied processes (privileges by user role, accreditations, de-accreditations, …) and dynamically acting into the organization;
– Adherence to the criteria that measure service provider(s) compliance with the identity ecosystem framework.
Figure 1 – IDaaS Maturity Framework to IDaaS Best Practices
Accordingly, the metric should be based upon the organization maturity grade. The gauge proposed is made the simplest possible, designed to be flexible: if necessary, this metric can be enriched and applied to more complex systems (more parameters by maturity levels, more maturity levels according to the company’s policy). The metric measures what is the confidence/risk when organizations moves to IDaaS by adopting the following models:
1) ID On-premise – ID is outsourced but infrastructure is kept inside the company. In this case ID personnel manage tools and infrastructure but expertise is coming from the outsourcer;
2) ID Provider Hosted – A private Cloud for IDaaS is managed. Personnel managing the private Cloud (tools) are shared with the service Provider. In this case administration, tools and infrastructure are in the private Cloud and ID management is shared;
Figure 2 – IDaaS properties and possible path to the Cloud
3) ID Hybrid – IDaaS is in the Cloud although sensitive information is yet managed internally. ID Hybrid means subscribing private, community and/or public Cloud services. Tools and infrastructure are shared through the Cloud. ID administration is managed in the Cloud.
4) ID in the Cloud – The ID is in the Cloud. Only personnel managing contract and service conditions (all aspects: policy, framework, SLA …) are kept internally.
These aspects are important on one hand considering what risk (and countermeasures) may be taken when moving the ID to the Cloud and on the other hand which takings could be expected in terms of cost savings. Companies have to balance the real business value of the risks based upon on-premise ID maturity and the eventual cost reduction, model by model. In the following picture, an example shows how 3 companies having 3 different levels of maturity for IdM, SOA and Ecosystem adherence, meet 3 scenarios in term of Cost/Saving and Confidence/Risk when decide to move to IDaaS.
Figure 3 – IDaaS: 3 cases of companies having different level of maturity and risk
Company A – Company A manages advanced projects to implement and maintain high levels of maturity for IdM and SOA. Still, attention is paid to the Cloud identity ecosystem: the Company applies specific criteria to assess services provisioning in the Cloud. By applying IDaaS Best Practices based on Maturity levels, Company A might moderate the risks if decides to move ID in the Cloud. Criteria to adopt Cloud services are enough stable to manage on-demand and full provisioning IDaaS. Cost saving is another aspect should be taken into consideration. By externalizing IDaaS, the expected savings might be impressive (about 70% of CapEx invested) and, in this case, moving to the Cloud can be balanced with a path that further moderates the risk.
Company B – Company B has an intermediate maturity and work in progress projects through the IdM and SOA implementation. The ecosystem interface knowledge also is increasing although it is not yet disciplined. Confidence to move ID to the Cloud is low with respect the Company A and the risk is growing with the above IDaaS models. Considering the CapEx to implement internal IAM and BPM procedures, IDaaS cost saving is lower (about 30% of CapEx invested) then Company A. Company B should mitigate the risk by moving to the appropriate IDaaS model. The right path to subscribe IDaaS should be starting from the most proper IDaaS model to progressively increase levels of maturity.
Company C – Company C has a different challenge to get, with respect Company A and B. Company C is not organized to set defined levels of maturity for IdM and SOA. Still, there is not enough interest or experience to classify proper requirements and accountability mechanisms typical of an identity Cloud ecosystem structure. Identity and SOA cultures exist but they are jeopardized. In this case without CapEx to cover, it seems highly attractive saving soon by moving to IDaaS. However, cost saving only is not the best way, generally speaking, to move to the Cloud, neither to subscribe IDaaS contracts. The risk to move ID in the Cloud is really high. The Company C should ask for:
– how IDs are provisioned, authenticated and managed (IdM, IAM);
– who retains control over ID policies and assets (SOA);
– how are stringent peer to peer security standards (ID ecosystem);
– how and where are employed data encryption and tokenization (ID ecosystem);
– how and where are employed federated identity policies (for example: check if they are regularly backed by strong and protected authentication practices) (SOA);
– what about availability, identity data protection and trust on third parties (ID ecosystem);
– how is employed transparency into cloud operations to ensure multi-tenancy and data isolation (IdM and ID ecosystem).
Could Company C provide the above answers before movingthe ID to the Cloud? This essential information should be an asset for any company that decide to migrate to the Cloud. Prerequisites above are only a part of the full requirements subscribers should assert before acquiring Cloud ID services. No Company can improvise to move to IDaaS: consequently, possible choices for Company C may be the following:
1) starting from the low risk ID on-premise model;
2) moving in any case ID to the Cloud being aware of the risk by trying to balance IDaaS cost saving (OpEx) benefit and Cloud environments introducing transient chains of custody for sensitive enterprise data and applications.
Defining the Metric
The metric that should best describe the above scenarios is based on the products of exponential functions depending upon parameters setting the organization maturity levels. In practice, the general mathematical relationship is the following:
Here is the meaning of variables and indexes:
R is the Risk/Confidence value defining the range maturity forward the IDaaS model above described;
Pcis the percentage of completion of each maturity range;
V is the variable corresponding to the magnitudes chosen to measure the maturity of the specified range. To calculate the level of IDM, SOA and Ecosystem maturity, 2 variables have been chosen: the project cost (Cm is the current cost and CM the estimated budget cost) and the project time completion (Tm is the current project time and TM the estimated project completion time);
N is the number of maturity ranges considered (IdM, SOA, Ecosystem …).
Constraints: the exponential function is a pragmatic risk estimation based upon the concept of density of probability. To compute the risk/confidence there is no average technique included: the max of the series of the calculated risks has been preferred with respect to the statistical averages models. Looking at the above metric, it requires the following constraint: 3 maturity ranges should be at least considered to estimate the best IDaaS model. They are: IdM, SOA and Ecosystem Framework. Further, the above metric is extensible and it is enough flexible to consider more ranges of maturity and, inside each one, more variables to be added to projects costs and times. Finally, R (risk/confidence) is computed as the max value among maturity series’ risks. In practice, consider the following test rates:
IdM Maturity: Percent of completion 30%, Cm = 25.000,00 $, CM = 75.000,00 $, Tm = 6 months and TM = 24 months
SOA Maturity: Percent of completion 40%, Cm = 55.000,00 $, CM = 90.000,00 $, Tm = 8 months and TM = 24 months
Ecosystem Framework Maturity: Percent of completion 15%, Cm = 10.000,00 $, CM = 30.000,00 $, Tm = 2 months and TM = 6 months
Risk/confidence outcomes based upon the above values are the following and the max value is:
Could the company accept the risk of 98% in moving to the Cloud with the ID system? What is the main pain looking at the maturity ranges and the risk rates? What is the appropriate IDaaS model could moderate the risk and reduce the costs? The solution in the figure below might be a measured solution to get confidence and awareness before subscribing an IDaaS contract.
Figure 4 – Snapshot based upon the above maturity rates and risk/confidence values
Companies could apply a systematic approach by adopting the gauge above exploited. The metric can help in deciding whether balancing risks and OpEx advantages is appropriate in subscribing an IDaaS contract forward security and business benefits. Looking at the cost saving for Company C, the above cutbacks could be modest (about 20% or less with respect the actual CapEx) although the ROI would be faster. It depends upon the IDaaS strategy the Company decides to implement.
 N. Piscopo – Applying MaaS to DaaS (Database as a Service) Contracts. An introduction to the Practice http://cloudbestpractices.net/profiles/blogs/applying-maas-to-daas-database-as-a-service-contracts-an
 N. Piscopo – Best Practices for Moving to the Cloud using Data Models in the DaaS Life Cycle
 N. McEvoy – IDaaS Identity-as-a-Service best practices http://CanadaCloud.biz
 E. Baize et al. – Identity & Data Protection in the Cloud
 F. Villavicencio – Advantages of a Hybrid Co-Sourced IDaaS Model
 Identity in the Cloud Outsourcing Profile Version 1.0 – OASIS Committee Note Draft 01 /
Public Review Draft 01
 N. Piscopo, N. McEvoy – IDaaS – Introduction to the Identity in the Cloud
 WG-CloudIDSec IDaaS (Identity as a Service) www.cloud-identiy.info
Disclaimer – This document is provided AS-IS for your informational purposes only. In no event the contains of “A high-level IDaaS metric: if and when moving ID in the Cloud” will be liable to any party for direct, indirect, special, incidental, economical (including lost business profits, business interruption, loss or damage of data, and the like) or consequential damages, without limitations, arising out of the use or inability to use this documentation, regardless of the form of action, whether in contract, tort (including negligence), breach of warranty, or otherwise, even if an advise of the possibility of such damages there exists. Specifically, it is disclaimed any warranties, including, but not limited to, the express or implied warranties of merchantability, fitness for a particular purpose and non-infringement, regarding this document use or performance. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies/offices.