- 2 -
Error! No text of specified style in document.
INTERNATIONAL TELECOMMUNICATION UNION / STUDY GROUP 17TELECOMMUNICATION
STANDARDIZATION SECTOR
STUDY PERIOD 2013-2016 / TD xxx
English only
Original: English
Question(s): / 10/17 / Geneva, 26 August – 4 September 2013
TD
Source: / Editor
Title: / Current working text of x.iamt – Identity and Access Management Taxonomy
Objectives
This contribution develops text for x.iamt.
Proposal
Discuss the provided text and adopt agreed upon text in the August meeting of SG 17
Contact: / Radu MarianMBNA / Tel: +001 613 291 3253
Email:
Attention: This is not a publication made available to the public, but an internal ITU-T Document intended only for use by the Member States of ITU, by ITU-T Sector Members and Associates, and their respective staff and collaborators in their ITU related work. It shall not be made available to, and used by, any other persons or entities without the prior written consent of ITU-T.
- 2 -
Error! No text of specified style in document.
Proposed text for draft Recommendation Identity and Access Management Taxonomy Contents
1. Introduction 3
2. Scope 3
3. References 4
4. Definitions 4
4.1 Terms defined elsewhere 4
4.2 Terms defined in this Recommendation 5
5. Abbreviations and acronyms 5
6. Conventions 6
7. Objectives 6
8. Approach Overview 6
9. IAM Concept Dictionary Model 9
10. IAM Domain Model 10
11. Concept Type Syntax Context and Concept Instance Context 14
11.1 Business Task Concept 14
11.2 Business Role Concept 15
12. Use Cases 17
Appendix 19
I. SCIM 2.0 Extension Profile Proposal 19
II. Examples of Business Taxonomies 20
III. x.XACML-3 Extension Profile Proposal 22
IV. IAM Life Cycle Taxonomy 23
Bibliography 25
1. Introduction
Currently the enterprise Identity and Access Management (IAM) data element definitions (e.g. entitlements, roles, attributes, resources, resource actions, constraints, etc.) are not consistent in nature, overlapping, out-of-date, cryptic, overly-technical, or even blanknot defined. The lack of quality in IAM data element definitions negatively affects the work throughout all IAM life cycle phases: Entitlement Design, Enrolment, Provisioning, Access Request Approval Workflow, Credential Management, Runtime Authentication and Authorization, Logging and Monitoring, Access Review, Audit, and Reporting.
The above deficiency has a compound negative effect on phases towards the end of IAM life cycle. Specifically due to the lack of business meaning in reported entitlements as well as the fear of being out of compliance access reviewers “rubber stamp” their decision to either grant or revoke user access rights. The high rate of access review false grants results in:
• Increased risk of reputational harm
• Increased risk of financial loss
• Regulatory concerns
• Negative operational and productivity impact
• Inability to deliver large scale enterprise solutions such as process, application, and role rationalization.
Below are the identified root causes:
• IAM data elements definitions are captured and referenced by various tools in different proprietary formats, in multiple un-synchronized repositories, not adhering to standards, and lacking governance process.
• IAM data element definitions are maintained in different domains (e.g. Business Process, Application, Information, Risk, Security domains, etc.) as separate and unrelated concepts (i.e. never to be merged together for a cross domain search and analytics to address the above pain points)..
• Throughout all IAM “end to end phases” Subject Matter Experts (SMEs) do not have a common place to reference security data element definitions for accurate, consistent, and efficient communication and collaboration throughout IAM phases, across other domains, lines of business, and the enterprise.
2. Scope
The scope of this contribution is limited to developing a formal Ontology to express Identity and Access Management (IAM) domain element relationships with a corresponding Control Vocabulary based on existing ITU-T IAM definitions.
The following assumptions will further limit the scope of this formal Ontology:
· IAM Ontology will model concepts and relationships pertaining to the IAM domain.
· Business concepts such as party, account, and their relationships will not be modelled in the IAM Ontology.
· IAM Ontology should be merge-able with other ontologies to provide answers to analytical questions that span across different domains such as business, application, and data.
· Shared vocabulary will be used to capture data element definitions for all domains to enable ontology merging for the purposes of cross domain analytical query execution.
This Recommendation will enable finding, analysing, and referencing accurate and consistent IAM data element definitions throughout the IAM lifecycle.
An IAM data element governance process is out of scope for the initial phase of this work item.
3. References
The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
[ITU-T X.1254] Recommendation ITU-T X.1254 (2011), Information technology — Security techniques — Entity authentication assurance framework.
[ITU-T X.1252] Recommendation X.1252 (2010), Baseline of identity management terms and definitions.
[Note] The normative references will be added
Since the following Temporary Document is not a Recommendation it is listed separately:
[in TD 2802 Rev.1] temporary document TD 2802 Rev.1 (2012), Enterprise Security Registry.
4. Definitions
4.1 Terms defined elsewhere
Credential: Set of data presented as evidence of an asserted or claimed identity and/or entitlements [ITU-T X.1252].
Access Control: A procedure used to determine if an entity should be granted access to resources, facilities, services, or information based on pre-established rules and specific rights or authority associated with the requesting party [ITU-T X.1252].
Context: Environment with defined boundary conditions in which entities exist and interact [ITU-T X.1252].
Role: A set of properties or attributes that describe the capabilities or the functions performed by an entity [ITU-T X.1252].
NOTE – Each entity can have/play many roles. Capabilities may be inherent or assigned.
Entity: Something that has separate and distinct existence and that can be identified in a context [ITU-T X.1252].
Attribute: Information bound to an entity that specifies a characteristic of the entity.
Identifier: One or more attributes that uniquely characterize an entity in a specific context [ITU-T X.1254].
Identity: Set of attributes related to an entity [ISO/IEC 24760].
NOTE – Within a particular context, an identity may have one or more identifiers to allow an entity to be uniquely recognized within that context.
User: Any entity that makes use of a resource, e.g., system, equipment, terminal, process, application, or corporate network [ITU-T X.1252].
4.2 Terms defined in this Recommendation
• Team: Ais is a human resource container of Business Roles each team member has in common.
• Business Role: A collection of Tasks or Business Permissions a user can be entitled to perform.
• Business Entitlements: A set of Tasks or Business Permissions a user can be entitled to perform.
• Tasks: Leaf nodes of a Business Process Taxonomy created and maintained by business architects and business process modellers.
• Business Resources: Leaf nodes of a Business Product Taxonomy accessed by a corresponding Task via specific Action.
• Action: is the operation performed by Task on corresponding Business Resource.
• Business Permissions: Tasks that access Business Resources on behalf of the user, where access is constrained by corresponding Access Control Policies.
• Assign Policy: A permissions assignment constraining mechanism (i.e. what Tasks can be assigned to a user).
• Access Policy: Is an access control constraining mechanism (i.e. what Business Permissions a User can execute during run-time).
5. Abbreviations and acronyms
APQC - American Productivity & Quality Center
CPC - Central Product Classification
eTOM - TeleManagement Forum enhanced Telecom Operations Map
IAM – Identity and Access Management
IP – Internet Protocol
JSON – JavaScript Object Notation
JSON-LD - JSON-based Serialization for Linked Data
MAC – Media Access Control
OWL - Web Ontology Language
RDF – Resource Description Framework
SCIM - System for Cross-domain Identity Management
SDLC – Software Development Life Cycle
SKOS - Simple Knowledge Organization System
XACML - eXtensible Access Control Markup Language
6. Conventions
[TBD]
7. Objectives
The main objectives of this work item is to provide a common standard mechanism for registering, referencing, managing, defining syntax, and expressing the meaning of IAM Data Elements. Specifically:
1. Provide a common repository and service interface for:
- Searching IAM data elements.
- Referencing IAM data elements.
- Creating IAM data elements.
- Updating IAM data elements.
- Deleting IAM data elements.
2. Provide a mechanism for defining and managing the syntax of IAM data elements.
3. Provide a mechanism for expressing the business meaning of IAM data elements.
8. Approach Overview
There are a number of possible approaches that may address the root causes presented above. The most comprehensive approach (as well as the most complex one) is to develop a formal IAM ontology. While a formal ontology approach (Mohammad, 2011) would provide necessary features such as capturing concept syntax and meaning through rich relationships, fact discovery via an inference engine, ability to merge different domains, as well as a standard way to manage and search concepts and relationships it will take a considerable effort to develop a proper solution. On the opposite side of a complexity spectrum, a controlled vocabulary would require much less effort but the feature set becomes more limited. A controlled vocabulary solution such as SKOS[1] (Antoine Isaac, 2009) or a standard based approach such as Metadata Registry (Ray GATES, 2013) provides concept identification but lacks concept relationship definition and does not help meet the two key objectives: defining syntax and expressing the meaning of IAM Data Elements. The approach taken by this document incrementally builds on a controlled vocabulary based solution and will provide for necessary objectives of this work item.
There are multiple ways to implement a controlled vocabulary. It largely depends on the scope of the industry (e.g. health-care, agriculture, manufacturing, financial, etc.) and corresponding domains (e.g. business, data, security, services, applications, etc.) as well as desired applicationsrequirements, use cases, and outcomes (e.g. supply chain contracts, search results accuracy, term meaning accuracy, etc.). For example schema.org[2] (Google, Yahoo, Bing, Yandex, 2011) is a controlled vocabulary that covers the most popular industries and domains[3]. Its main use cases and outcomes are geared towards accurate web search results. schema.org has proven to yield substantial benefits to a growing sector of Internet users and web page masters.
Similar to a controlled vocabulary this proposed approach will provide a mechanism to define IAM domain concept types as well as a mechanism to reference concepts from related domains such as Business Taxonomy (see Appendix III). However unlike a vocabulary[4] this approach will also have to provide meaning and syntax for its terms. Therefore a more accurate name for this approach would be a dictionary[5]. Hence from now on we will use the name – IAM Concept Dictionary.
IAM Concept Dictionary is purposed as an industry agnostic (i.e. catering to either financial, health-care, government sectors) with a specific emphasis on IAM domain that takes possible inputs from other related domains. The following picture describes possible enterprise domains that provide input to IAM Concept Dictionary.
Figure 1, IAM Concept Dictionary Domains Relationships
In Figure 1, the IAM Domain depends on the input from the Business Domain –specifically the business concept of type Task called “Set Up Account”. In fact not only IAM Domain needs to reference this concept but also Application Domain, Reference Data Domain, etc. The “12345” number symbolically represents a unique Concept ID that is common across enterprise domains.
In addition to providing a mechanism for registering IAM data elements as concepts this controlled vocabulary will also:
· Provide a mechanism to capture IAM data element syntax with corresponding context.
· Provide a mechanism to enforce the IAM data element syntax when creating and updating IAM data elements.
· Provide a mechanism for triggering the evaluation of corresponding IAM policies when creating and updating IAM data elements.
· Provide a mechanism to generate a human readable description of IAM data elements based on business meaning.
· Provide a mechanism to capture concept metadata such as industry and domain information, organizational unit information, versioning, and ownership.
The primary use cases and desired outcomes are listed in Section 12: Use Cases.
9. IAM Concept Dictionary Model
Any controlled vocabulary implementation has an underlying meta-model. The role of such a meta-model is to define the super types from which other types in the model extend from. Foremost IAM Concept Dictionary is providing an implementation of such a controlled vocabulary meta-model. Figure 2 describes in simple terms the common data about any IAM Data Element to be persisted in IAM Concept Dictionary.
Figure 2, IAM Concept Dictionary Meta-Model
One can assume that an enterprise can have many federated Concept Dictionaries. In turn each line of business (hence OrgUnitNamespace) can have its own dictionaries for corresponding domains (hence DomainNamespace such as business, data, services, security) as needed for particular line of business units. At the core each dictionary consists of a certain limited number of ConceptTypes describing the domain at hand and required Concepts (i.e. instances of the corresponding ConceptTypes).
Note 1: The model in Figure 2 is provided for illustrative purposes to describe the three main components of the IAM Concept Dictionary. The other important meta-data elements such as date created and concept ownership are purposely not shown and deemed implementation specific.
Note 2: The persistence mechanism and physical model would vary by specific implementation such as fast read key-value pair, document oriented, relational, and other corresponding types.