Current approaches to IDaaS on one hand enforce trust of consumer data using legal compliance, risk and impact assessment and the other hand require technical implementation of access controls to personal data held by an enterprise. Balancing trust has to be done across all layers, verifying person’s identities, showing the individual and the service is real, creating short term relationships and verifying and maintaining all long the Cloud service the user mapping between the enterprise and the cloud user account in a mesh federation. This makes sense only if enterprises design “on-premise” with MaaS their own flexible ID data model and can verify ID maturity and consistency before moving, and along, the ID service in the Cloud. Based on MaaS, the BYOID concept is a possible solution to ID models for consent policy design, management and deployment. The BYOID model is a means to expressing, tracing and updating consumer’s personal data policy requirements; however enterprise users’ privacy preferences are provided as well. The IDaaS Maturity Framework (IMF) defines and directs the BYOID practice. MaaS guide properties and personal preferences from the consent metamodel design to the ID deployment. Both ensure that ecosystem compliance is achieved and ID in the Cloud meets trustworthy relationships.
IMF supports flexible BYOID design and deployment
IDaaS is authentication and authorization infrastructure that is built, hosted and managed through different models by third-party service providers, resident in ID ecosystem frameworks. IDaaS for the enterprise is typically purchased as a subscription-based managed service. One or more cloud service providers, depending upon the IDaaS model the enterprise deploys, may host applications and provide subscribers with role-based web access to specific applications or even entire virtualized infrastructure. IDaaS makes enterprises responsible in evaluating privacy risks and grade of confidence when moving the ID to the cloud. Accordingly, before externalizing the corporate IdM, consider the different IDaaS models are supported depending upon the maturity levels of:
– IdM/IAM system, in terms of implementation, maintenance and IdM/IAM governance capacity. ID, by its nature is de-centralized and then the maturity rank should consider the whole IdM/IAM system including data protection, data manageability, data security and organization ID awareness at all levels;
– SOA system, to really understand policies by applied processes’ de-coupling (privileges by user role, accreditations, de-accreditations …) and procedures dynamically acting into the organization;
– ID ecosystem reliability and adherence to the frameworks’ security criteria that measure service provider(s) compliance.
However, the levels of maturity gauged along the organization enables the enterprise to design its own ID as a consequence of the appropriate IDaaS model. The enterprise is able to bring in the ID ecosystem a configurable IDaaS model based on MaaS design to satisfy enterprise business rules. Business rules have impact on enterprise identity requirements and they balance and reconcile consumer identities needs. This “fluid” multiple-way enterprises-consumers solution, or BYOID, creates a high assurance level of ID ecosystem participants’ identities that could be used for enterprise access by respecting privacy and security requirements: IDaaS models contain BYOID properties and define “on-premise” BYOID maturity and consistency.
A new concept of ID consent: the BYOID fluid model
When registering to an Identity Platform, users would like represent themselves according to their behaviour having the option to approve selective or discretionary sharing of their private information and looking for the ability to obfuscate, mask or mesh some parts of personal data. So, ID platform and user are creating interactively a bond of trust as a part of the whole ID service. This is possible only if the consent of the individuals, the data protection conditions for processing their personal data and consent policies might be modelled “on-premise” by the enterprise IdM.
Looking at the IMF, the ID metamodel might sprout in the IdM/IAM maturity appraisal stage, according to the properties and requirements the enterprise needs to protect personal data and sensible information. The question now is the following: if the ID metamodel is designed in the company IdM, could the consent model be considered proprietary? The metamodel gathers the properties corresponding to the real enterprise requirements but it will be tested and appraised firstly in IdM/IAM system and then in the SOA maturity system. At that point features like interoperability, expression of functionality and user’s behaviour will be explicit aspects of the BYOID data model such as the following:
1) Trust properties;
3) Scalability and performance;
6) Credential Types;
9) User Centricity/User Control.
The above properties are matter for the ID ecosystem public consent data model structure (basic/incoming tables of the BYOID metamodel). In the beginning, those metadata are properties of the company: the company’s BYOID metamodel. Once the BYOID metamodel has been defined, tested and approved as BYOID company data model, it will be released to the ID ecosystem as an IDaaS model subscription. Despite of different approach, each enterprise may then adopt and release his BYOID. Before deploying BYOID services in the Cloud, the BYOID model should be compared with other BYOID models already running into the ID ecosystem frameworks. To be accepted, BYOIDs have to meet a set of common requirements enforced by the consent public ID ecosystem framework authority: the more adaptive is the public consent model (continuously and rigorously improved), the more flexible, secure and reliable are the BYOIDs shared. It makes interactive, fluid and safe BYOIDs deployed through IDaaS. Still, this enables user’s behaviour can be captured both at high level (enterprise-ecosystem reconciliation) and at low level (personal-enterprise-ecosystem reconciliation). Therefore BYOID can be reconciled, renormalized and constantly trusted at all levels. Since BYOID metamodel contains the enterprise identity requirements, it might include and integrate the ID ecosystem identity properties and, if approved by the user (obligation to maintain the personal data securely), his personal properties. This aspect is very important: in fact, there’s significant risk for a company when both customer/user relationships and company data are stored on personal devices. Using BYOID deployed as an IDaaS subscription, company information is centralized based upon “on-premise” consent metamodels: this means that company information stored on personal devices is minimized and always centrally controlled.
Fig. 2 – Fluid BYOID update and reconciliation: IDaaS User Experience vs. BYOID IDaaS subscription
User’s personal properties might reside on the same company (central) metamodel/consent model or not depending upon user approval and, always possible, withdrawal (i.e. personal data should comply with data protection legislation and, where necessary, the approval of the individual must be obtained). In the figure 2 here is an example. In 1 the User tries a new behaviour (statistically relevant or as a recommender system outcome); in 2 the IDaaS user experience has to be changed and updated. Above we show 3 data models but in the MaaS representation they consist of a unique model containing the BYOID IDaaS subscription (master) that includes 2 sub-models: the company consent model and the user personal model. In 3, the consent model is modified to keep compliance with the company business rules/conduct mapped to the BYOID IDaaS subscription. In 4, finally the update is executed and the User might find his conduct as a new function. However, take note in the figure 2 a relational model-like formalism is applied. This is just a simplification. In effect, we are in a multi-level relational data model that can be represented with NoSQL, Vector or Graph DB else, depending upon the data analytics domain.
USE CASE: the fluid BYOID approach
IDaaS models to move ID to the Cloud enable organizations to externalize identities data more knowingly and securely. Employees and customers behaviour changed: they continuously have business contacts, calls and meetings with personal devices. Since an increasing quantity of employees uses their mobile devices everywhere, identities can be resident and so associated to applications running on different framework in a multi-topology cloud configuration. What should be then the best IDaaS model satisfying this new employees/customers conduct? Could be managed all users, across multiple locations, while securing company data? Because of each identity may be managed by different identity management services, authentication and validation of identities by the cloud infrastructure could not be sufficient. Companies have to verify and control “on-premise” their ID maturity. BYOID based upon IDaaS models allows to identifying and securing identity properties. Further IDaaS models assist ID integrity control over shared topologies with a variety of ID ecosystem frameworks. IMF plays a crucial role in identifying the most appropriate IDaaS model before deploying the BYOID to the Cloud. Then the BYOID is an IDaaS model and can be designed “on-premise” and controlled along deployment and subscription.
Properties and Directions
This use case is concerned with enterprises deploying their BYOID in the Cloud using IDaaS models and IMF. There is a need for evaluating “on-premise” organization IdM/IAM and SOA maturity before moving the ID to the Cloud. Evaluating the organization maturity levels involves three steps:
- IdM/IAM maturity: measure the IdM/IAM maturity level;
- SOA maturity: measure SOA maturity level – policies (privileges by user role, accreditations, de-accreditations …) and processes dynamically acting;
- Identity Ecosystem reliability/maturity: measure the ecosystem maturity/reliability, and above all, the secure service continuity because in hybrid topologies identities may be owned by different cloud providers resident in multi-topologies.
Objectives are the following:
- Enable organization to identify and set the best BYOID through IDaaS model based upon internals levels of IdM/IAM and SOA maturity compared to the ID ecosystem framework’s baseline adherence. This sets maturity in classifying the ID ecosystem framework and in evaluating the reliability the ID ecosystem may provide;
- Deploy the proper BYOID model applying the correct subscription and adherence with respect to the IDaaS ecosystem;
- Periodically measure the organization’s IdM/IAM and SOA maturity levels and verify the ID ecosystem reliability/maturity so to update, and eventually scale, the BYOID deployed.
However, accordingly with the objectives, the value of the ID ecosystem level of reliability/maturity is the outcome the company is expecting to:
– Keep BYOID secure and controlled and supervise the IDaaS service subscription;
– Contribute to the ecosystem as participant and/or as authority;
– Be a participant/counterpart in setting and approving attributes providers, policies and relying party’s decisions and IDaaS ecosystem adherence;
– Contribute to the IDaaS Trustmark definition and to the periodical appraisal and updating.
Table 1 – BYOID Use Case properties and directions
Process Flow along the IMF
Accordingly to this Use Case, the IMF process flow encompasses three steps:
Part 1: Appraise IdM/IAM Maturity Level – To cover definition, maintenance and upgrade of the organization IdM/IAM level of maturity. The IdM/IAM maturity value has to be periodically monitored and controlled to keep coherence with the IDaaS model deployed:
Figure 3 – BYOID: IDM/IAM Maturity Level Appraisal
The Identity and Access Manager verifies the Maturity level of the IdM/IAM system:
- The IdM Manager controls and regulates the accesses to information assets by providing policy controls of who can use a specific system based on an individual’s role and the current role’s permissions and restrictions. This ensures that access privileges are granted according to one interpretation of policy and all users and services are properly authenticated, authorized and audited;
- The BYOID Manager reconciles BYOID metadata and update the BYOID metamodel.
The IAM Manager controls if users’ identities can be extended beyond corporate employees to include vendors, customers, machines, generic administrator accounts and electronic access badges, all ruled by policy controls.
Part 2: Appraise the SOA Maturity Level – To cover definition, maintenance and upgrade of the organization SOA maturity level. The SOA maturity level has to be periodically monitored and controlled to keep coherence with the BYOID released:
Figure 4 – BYOID: SOA maturity level appraisal
The SOA Manager verifies the Maturity level of the SOA system through the SOA interoperability and defines the organization maturity in sharing services among departments:
- The SOA Manager verifies that the map of communications between services is drawn starting from IdM/IAM system and achieved maturity
- The SOA Manager controls and reports about the following crucial aspects:
- SOA reference architecture achievements and evolution;
- education to broaden SOA culture through the organization;
- methods and guidelines that organization adopts to apply SOA;
- policy for SOA appliance and governance.
- The BYOID Practice Manager tests and executes BYOID consent model reconciliation based on metamodel reconciliation and update. If necessary, BYOID Manager renormalizes the consent model by roundtrip with the BYOID metadata at IdM/IAM maturity level.
Part 3: Appraise the ID Ecosystem Reliability/Maturity – To establish the maturity/ reliability of the ID Ecosystem Posture. The comparative maturity of BYOID (Company vs. ID Ecosystem participants vs. user preferences) has to be continually monitored: points of discontinuity, unmatched policies, and untrusted relationships have to be time by time acknowledged. This helps to better qualifying frameworks accountability, federation assets, and participants’ reliability and level of contribution:
Figure 5 – BYOID: ID Ecosystem Maturity/Reliability Appraisal
The Service Manager verifies the Maturity/ Reliability level of the ID Ecosystem framework:
- The Service Manager controls that contribution to the ecosystem by privacy aspects, security components and accountability mechanism settings are congruent
- The Service Manager controls that common guidelines keep coherence with the company policies and standards strategy. Since more than a framework exists inside the ecosystem, rules to ensure that accreditation authorities validate participants’ adherence to the ecosystem requirements are to be verified and updated
- The Service Manager controls adherence to the ID ecosystem of the IDaaS deployed to verify reliability and service continuity;
- The Service Manager verifies that accreditation authority to ensure participants and frameworks are adherent to the identity ecosystem interoperability standards accepted
- The Service Manager controls that the ID ecosystem contains all trusted frameworks that satisfy the baseline standards established and they are compliant with the company maturity level
- The BYOID Practice Manager verifies the framework ecosystem common levels of adherence (baseline) and test and compare BYOID reliability properties;
- The ID Ecosystem Management Service verifies BYOID adherence and security with respect the IDaaS subscription.
The ID Ecosystem Management service provides a combination of criteria to determine the service providers’ compliance among frameworks and ID ecosystem topologies: the combination defines policies, rules and, eventually, a Trustmark. It gives confidence to participants in deciding who to trust in terms of BYOID framework adherence and among all ID providers.
Managing digital identities across ID ecosystems frameworks is crucial to improve efficiency of business collaborations. Using everywhere personal devices is becoming a preferred conduct but before sharing the ID among cloud domains, all involved parties need to be trusted. Still, to meet the demanding needs of security, big data analytics and business intelligence, users and consumers need a more efficient and flexible paradigms. In this paper, we identify how BYOID fluid model satisfies on one hand company security and user data protection and, on the other hand, rapid updating and reconciliation to the user conduct. IMF provides the necessary platform for collaboration in ID ecosystem topologies. We introduce also a USE CASE to point out how BYOID built across ID company consent model and ID ecosystem trusted access model, can be a foundation to gauge and govern BYOID strategies. Further, the paper can be used to compare different BYOID IDaaS subscription to establish what maturity levels the company might support compared with all business partners running existing IDaaS maturity models and to ensure ID in the Cloud meets trustworthy relationships.
I have to sincerely thank Susan Morrow for the precious feedback on contents and Anil Saldhana for the useful comments on the IDaaS Maturity Framework.
N. Piscopo – IDaaS. Verifying the ID ecosystem operational posture
N. Piscopo – A high-level IDaaS metric: if and when moving ID in the Cloud
N. Piscopo – MaaS implements Small Data and enables Personal Clouds
N. Piscopo – Best Practices for Moving to the Cloud using Data Models in the DaaS Life Cycle
N. Piscopo – MaaS (Model as a Service) is the emerging solution to design, map, integrate and publish Open Data
N. Piscopo – MaaS applied to Healthcare – Use Case Practice
N. Piscopo – Applying MaaS to DaaS (Database as a Service) Contracts. An introduction to the Practice
N. Piscopo – Enabling MaaS Open Data Agile Design and Deployment with CA ERwin®
N. Piscopo – ERwin® in the Cloud: How Data Modeling Supports Database as a Service (DaaS) Implementations
N. Piscopo – CA ERwin® Data Modeler’s Role in the Relational Cloud
N. Piscopo – Using CA ERwin® Data Modeler and Microsoft SQL Azure to Move Data to the Cloud within the DaaS Life Cycle
N. Piscopo – Page 16 in Transform2, MaaS and UMA implementation
Disclaimer – This document is provided AS-IS for your informational purposes only. In no event the contains of “ID Consent: applying the IDaaS Maturity Framework to design and deploy interactive BYOID (Bring-Your-Own-ID) with Use Case” 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.