Guest Blog: IDaaS – Verifying the ID ecosystem operational p

1. Guest Blog: IDaaS – Verifying the ID ecosystem operational posture Many companies find themselves unable to respond to the emerging ID security threats because of a lack of awareness and maturity in their organization. Identity as a Service (IDaaS) benefits are appealing — enabling organizations to bridge that knowledge gap more quickly. In addition to improved security, IDaaS services can reduce IT costs, enable new services and align IT with best practices [1]. However, the use of IDaaS has not been widespread, sometimes simply because companies don’t really understand the cloud identity offerings that exist. The IDaaS Maturity Framework

2. IT staff should ask for the following crucial questions: IdM/IAM: What is the IdM/IAM maturity level of my organization? OA Maturity: Centralized authentication and shibboleth sso are an important part of service oriented architecture. Identity Ecosystem : To what extend should the solution support Internet standards. ID in the Cloud : How “cloudy” is the solution. A new metric has been developed [2] to define the level of confidence organizations might verify before moving ID to the Cloud. However, looking at the above IDaaS maturity framework, here we want to focus on how organization can mitigate the risks of ecosystem security posture when they decide to implement their own IDaaS model as a consequence of the appraised IdM/IAM and SOA maturity levels. Use Case: Mapping IDaaS to the ID Ecosystem Posture Supposing an IdM/IAM maturity level and a SOA grade and governance applied through the organization can be identified and measured: IdM/IAM maturity: automated maturity level [1]; SOA maturity: systematic maturity level (see Fig. 2) [1].

3. Then an IDaaS model [1] might be defined to move the ID to the Cloud: which IDaaS model could satisfy the organization ID maturity and compliance with respect to the ID ecosystem posture? Here is a practical way to verify the Providers/Participants ecosystem framework federation compliance (vet Federated Sso, standard policies and procedures, schema definition, authentication mechanisms, authorization scopes) and the continuous contribution of autonomous partners. Looking at the figure above, consider the following steps: Value of the organization IdM/IAM maturity level. This value sets the organization confidence in terms of designing authentication and authorization, directory integration service together with the requirements to meet accesses (UMA, OAuth …), performance, availability, compliance, business continuity.

4. Supposing the IdM/IAM maturity level is 40% (Policy based reporting and auditing [1]), the organization could subscribe a Hybrid IDaaS model; Value of the organization SOA maturity level. Supposing the SOA grade of maturity is 30% (Systematic: there exists partnership between technology and business organizations in order to assure that the use of SOA provides clear business responsiveness [1]), the ID Hybrid service might be possible but it should be tested. A scalable multi-parted federated stack [4] maps the ecosystem and so participants to the framework(s) can be accessed and navigated. At this stage, data and credentials should be kept at their locations, both on-premise and in the Cloud; Applying the IDaaS model: does the operational test satisfy the designed ID Hybrid service? If yes, an IDaaS Hybrid contract can be temporary subscribed, although under verification. During the IDaas model proof time, the service should be monitored to meet expectations. If no, then 2 options should be analyzed to: Understand why the operation/mapping is not what expected by design and testing: – What is the gap between the test outcome and the expectations? – Does the gap depend upon providers and participants mapping compliance? – What is the severity of any mismatches detected in the framework(s)? – Could the gap be covered through limited efforts and costs? Evaluate the lower ID Provider Hosted IDaaS model.

5. In any case, the ID in the Cloud scenario appears clear and under control. The scalable multi-parted federated stack plays a crucial role [4]: the way to define the appropriate IDaaS model is unambiguous. Above all, there is awareness in moving ID to the Cloud. Effort, costs and outcomes are measurable and the terms of the IDaaS subscription (the ID clauses in the Cloud contract) can be based upon operational test results and, eventually, operational monitoring. Still, the ID ecosystem framework itself can be classified depending upon participants (and providers) reliability. Conclusion The ID ecosystem framework is a critical step in moving ID to the Cloud. Once the organization is aware of his IdM/IAM and SOA maturity then this is time to understand how to mitigate risks and optimize costs in externalizing ID [3]. Verify the ID ecosystem operative posture is a must and it can be accomplished using open sources multi-party federated stack. Still, outcomes are crucial in setting the contract clauses of the IDaaS subscription. Article resource: http://thegluuserver.wordpress.com/2014/06/16/guest-blog-idaas-verifying-the-id-ecosystem-operational-posture/