Embed Size (px)
Citation preview
INTERNATIONAL TELECOMMUNICATION UNION STUDY GROUP 17TELECOMMUNICATIONSTANDARDIZATION SECTORSTUDY PERIOD 2013-2016
TD xxxEnglish only
Original: EnglishQuestion(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 Marian Email [email protected]
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.....................................................................................................................44.1 Terms defined elsewhere................................................................................44.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
Appendix19
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
2
- 3 -Error! No text of specified style in document.
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.
3
- 4 -Error! No text of specified style in document.
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
4
- 5 -Error! No text of specified style in document.
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 RecommendationTeam: 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 acronymsAPQC - American Productivity & Quality CenterCPC - Central Product ClassificationeTOM - TeleManagement Forum enhanced Telecom Operations MapIAM – Identity and Access ManagementIP – Internet Protocol
5
- 6 -Error! No text of specified style in document.
JSON – JavaScript Object NotationJSON-LD - JSON-based Serialization for Linked DataMAC – Media Access ControlOWL - Web Ontology LanguageRDF – Resource Description FrameworkSCIM - System for Cross-domain Identity ManagementSDLC – Software Development Life CycleSKOS - Simple Knowledge Organization SystemXACML - 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:a. Searching IAM data elements.b. Referencing IAM data elements.c. Creating IAM data elements.d. Updating IAM data elements.e. 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 SKOS1 (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
1 SKOS provides basic hierarchical relationships such as broader and narrower however it does not allow more specific ontological relationships that may be required to express IAM data element syntax and meaning.
6
- 7 -Error! No text of specified style in document.
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.org2 (Google, Yahoo, Bing, Yandex, 2011) is a controlled vocabulary that covers the most popular industries and domains3. 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 II). However unlike a vocabulary4 this approach will also have to provide meaning and syntax for its terms. Therefore a more accurate name for this approach would be a dictionary5. 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.
2 “... a collection of schemas, i.e., html tags, that webmasters can use to markup their pages in ways recognized by major search providers. Search engines including Bing, Google, Yahoo! and Yandex rely on this markup to improve the display of search results, making it easier for people to find the right web pages.” from http://schema.or g /
3 Schema.org is an attempt to cover the most popular concept types across many industries (publishing, health, commerce, etc.) and spanning multiple domains (calendar events, reference data, product catalogue, etc.) from http://schema.org/docs/full.html
4 Webster defines vocabulary term as: “a list or collection of words or of words and phrases usually alphabetically arranged and explained or defined”
5 Oxford English Dictionary defines the term dictionary as: “a book that lists the words of a language in alphabetical order and gives their meaning”Webster Dictionary defines the same term as: “a reference source ... containing words ... along with information about their forms, pronunciations, functions, etymologies, meanings, and syntactical and idiomatic uses”
7
- 8 -Error! No text of specified style in document.
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.
8
- 9 -Error! No text of specified style in document.
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.
Note 3: Further research is needed to ensure that such a meta-model has not been already implemented. Specific research areas would be RDF/OWL usage by a SKOS vocabulary.
9
- 10 -Error! No text of specified style in document.
The following table lists and describes key elements of the above meta-model.
Element Name Description
ConceptDictionary
A container for Concepts and Concept Types. Concept Dictionary should have a Name, optional Description, an OrgUnitNamespace and a DomainNamespace in a dot notation for a line of business unit, and a dictionary Version.
Concept The IAM data element reference mechanism. ConceptID is an identifier for referencing IAM data elements. Each Concept is of a corresponding ConceptType. Concept should have a Name, optional Description, Instance Context, and a Concept Version.
ConceptType A type for new or existent Concepts. A ConceptType should have a ConceptTypeID – an identifier for IAM data element types. ConceptType should have a Name, Definition, a SyntaxContext, and Version.
InstanceContext A context for expressing the Concept Instance in a form of a linked data graph fragment.
SyntaxContext A context for expressing ConceptType syntax in form of a linked data graph fragment that specifies how Concepts are created using a corresponding template type format.
10. IAM Domain Model
In order to address the pain points described in the Introduction section the following list identifies key assumptions principles for the IAM Domain model that follows:
• Identifier is an instance of User Identity representation. During Entitlements Assignment process a User can be entitled to execute specific task via Team and Role (80% of the time) or directly as an Exception (20% of the time).
• Team is a human resource container of Roles. The main purpose of the Team type is to speed up and simplify Permission Assignment and Approval process.
• Since IAM Roles are currently created and maintained by IT they do not have a direct traceable business meaning. In many cases relying a on a Role name to convey the business meaning to access reviewer is not sufficient.
• Roles should inherit the business meaning from corresponding Tasks.• Tasks are the leaf nodes of a Business Process Taxonomy created and maintained by
Business Architects and business modellers.• Tasks are usually more granular than Applications that implement them.• Tasks are implemented by corresponding application(s).• Tasks represent the Duties as in Segregation of Duties use cases. • Therefore it is impossible to implement Segregation of Duties without
underlying Business Tasks.
10
- 11 -Error! No text of specified style in document.
• User does not access a Business Resource directly via its Action. Instead User is entitled to execute a Business Task and the Business Task accesses Business Resource on behalf of the User via Action.
• Process-Activity-Task is an abstraction layer expressed and maintained in a business standard way (APQC PCF, 2011) by Business Architects and Business Process Modellers. This is also explained in Appendix II.
• Product Group-Product Class-Business Resource is an abstraction layer expressed and maintained in a business standard way Central Product Classification (CPC Workgroup, 2008) by Business Architects and Business Process Modellers. This is also explained in Appendix II.
• Business Process Taxonomy provides a reference framework to implement Segregation of Duty use cases.
• Process-Activity-Task structure can accommodate not only a Business Taxonomy but also an Operations Taxonomy or else known as SDLC Taxonomy.
• SDLC Taxonomy provides a reference framework to implement Technical Segregation of Duties.
• Assign Policy is an Entitlement Constraint on what Tasks a User can have (at access assignment time)
• Access Policy is an Entitlement Constraint on what Tasks a User can execute (at authorization runtime assignment time)
• Business Resources are concepts such as Loan Account or Checking Account. They are not controlling access to system resources such as Database Table, File, or Dataset but rather are used in context of Tasks to enable fine-grain entitlement assignment.
• Business Entitlements are Task(s) a User is entitled to execute (i.e. coarse-grain business entitlements). A Task can optionally perform an Action on a specific Resource (i.e. Loan Account and its number) in a given Business Context (i.e. fine grain business entitlements).
• Business Permissions are Task(s) that perform an Action on a specific Business Resource constrained by a Policy.
• During Provisioning Business Entitlements are mapped to System Permissions.• System Permissions deal with System Resources such as Database, Table, Column,
File, or Mainframe Data Set.
The relationship between the above IAM Data Element Types is depicted in Figure 3.
11
- 12 -Error! No text of specified style in document.
Figure 3, IAM Schema Domain Model
12
- 13 -Error! No text of specified style in document.
Figure 4 combines a fragment of the iamschema domain model (left), Concept Dictionary meta-model (top-right), and the Concept Dictionary instance model (bottom-right)
Figure 4, IAM Schema, Concept, and Instance Model Combined
One can see that Concept Dictionary is used to express the iamschema model as instances of ConceptTypes. Each concept (“Teller Role”, “Set Up Account”, etc.) is created based on its corresponding syntax template (“Business Role Syntax Template”, “Task Syntax Template”, etc.). The following section will describe the approach taken for expressing SyntaxContext and InstanceContext using linked data graphs.
13
- 14 -Error! No text of specified style in document.
11. Concept Type Syntax Context and Concept Instance Context
In order to meet the last two key objectives – i.e. defining IAM Data Element type syntax, and expressing the meaning of IAM Data Elements – this work item is leveraging linked data6 non-normative specification in final stages called JSON-LD7 (Manu Sporny, 2013).
11.1 Business Task Concept
As already noted in previous section SyntaxContext and InstanceContext concept attributes are expressed as linked data graph fragments. The example below illustrates the concept syntax and concept syntax for “Set up Account” business task.
SyntaxContextfrom ConceptType
InstanceContextfrom Concept (Instance)
{
"@context": "http://iamschema.org",
"@graph": {
"@type": "Business Process",
"consistsOf": {
"@type": "Activity",
"consistsOf": {
"@type": "Task",
}
}
}
}
{
"@context": "http://iamschema.org",
"@graph": {
"@id": "51430000",
"@type": "Business Process",
"name": "Origination",
"consistsOf": {
"@id": "51573000",
"@type": "Activity",
"name": "Originate / Open Account(s)",
"consistsOf": {
"@id": "51587300",
"@type": "Task",
"name": "Set up Account",
"description": "Set up the customer account with all the required details."
}
}
}
}
As one can see from the column on the left the JSON-LD graph fragment specifies syntax for creating a “Task”. It says that in order to create a “Task” its parent “Activity” and grand-parent nodes “Business Process” need to be referenced.
6 Wikipedia defines Linked Data as "a term used to describe a recommended best practice for exposing, sharing, and connecting pieces of data, information, and knowledge on the Semantic Web using URIs and RDF." from http://en.wikipedia.org/wiki/Linked_data
7 JSON-LD is a lightweight Linked Data format. It is easy for humans to read and write. It is based on the already successful JSON format and provides a way to help JSON data interoperate at Web-scale. from http:/ / json-ld. o rg/
14
- 15 -Error! No text of specified style in document.
Note 1: The colouring is used in the following ways: green colour for depicting entity concept types (ex. “Task”) and yellow colour for depicting relationship concept types (ex. “consistsOf”).
11.2 Business Role Concept
A more complex example is based on a Role concept type. The SyntaxContext for Role is displayed below:{
"@context": "http://iamschema.org",
"@graph": {
"@type": "Business Role",
"consistsOf": {
"tasks": [
{
"@type": "Task",
"permforms": {
"@type": "Action",
"accesses": {
"business resources": [
{
"@type": "Business Resource"
}
]
},
"constrainedBy": {
"access policies": [
{
"@type": "Access Policy"
}
]
}
}
}
]
}
}
}
So the above SyntaxContext says that a Role concept can be created and it would “consistsOf” zero ore more Tasks. Tasks in its turn could “perform” an “Action” that “accesses” business resources. The Action “accesses” is “constrainedBy” zero or more “Access Policies.” Below is an example of such a concept instance – “Teller” business role:{
15
- 16 -Error! No text of specified style in document.
"@context": "http://iamschema.org",
"@graph": {
"@id": "556430000",
"@type": "Business Role",
"name": "Teller",
"consistsOf": {
"tasks": [
{
"@id": "51587300",
"@type": "Task",
"name": "Set up Account",
"permforms": {
"@id": "54387300",
"@type": "Action",
"name": "Open",
"accesses": {
"business resources": [
{
"@id": "58687300",
"@type": "Business Resource",
"name": "Checking Account"
}
]
},
"constrainedBy": {
"access policies": [
{
"@id": "58647300",
"@type": "Access Policy",
"name": "Multi-Factor Authentication Access Policy"
},
{
"@id": "58647321",
"@type": "Access Policy",
"name": "Segregation of Duties Check Access Policy"
}
]
}
}
16
- 17 -Error! No text of specified style in document.
}
]
}
}
}
The above JSON-LD code describes the meaning of “Teller” business role. It states that the Teller role “consistsOf” the “Set Up Account” task and that this task performs “Open” action on “Checking Account” business resource and that the “Open” action is constrained by two access policies.
Note 1: Even though the above syntax context is used as an all nodes to be required template in reality not all the sub-nodes would be required during Teller role creation. For example the Teller role can stop at Task node without defining what action is performed on particular business resource. In this case this Business Role is sufficient to be used by a coarse-grained Segregation of Duties policy during access assignment phase of the IAM lifecycle.
Note 2: One can notice that JSON-LD graphs closely follow the iamschema model – hence the reason of combining fragments from iamschema model, concept dictionary model, and instance model into one diagram.
Note 3: Further refinement is needed to express required, optional, and cardinality attributes.
12. Use Cases
1. Access Assign:a. Leverage Concepts in the dictionary to create:
i. A number of Roles – Teller, Cashier, Financial Analyst, etc.1. Display the syntax of the Role2. Display the meaning of the Role
ii. A coarse grained (Tasks based) SoD policy.1. Evaluate the SoD policy to say that you can or cannot assign new
tasks to a role based on policy decisioning result.
2. Access (Entitlements) Reporting:a. Leverage Task Concepts to improve readability and meaning of the current Business
Language Entitlements Description effort.b. Leverage Business Resource Concepts to improve readability and meaning of the
current Business Language Entitlements Description effort.
3. Business Taxonomy:a. View the taxonomy – similar to windows file explorer
i. Nav pane – the Process-Activity-Task hierarchyii. Left pane – the Process/Activity/Task descriptions.
b. Update taxonomy:i. Add/Delete/Drag any Process/Activity/Tasks
ii. Update descriptions.
4. Application Logging with subsequent Analyticsa. Leverage an existent reference web application to:
17
- 18 -Error! No text of specified style in document.
i. Configure application logging template to use ConceptIDs.ii. Generate log files during application runtime
b. Consume app log files with an Analytical tool i. Correlate transaction events based on Task conceptID.
ii. Produce analytical reports indicating threat level.
18
Appendix
This appendix does not form an integral part of this Recommendation.
I. SCIM 2.0 Extension Profile Proposal
In order to expedite the implementation of the IAM Concept Dictionary Services the SCIM 2.0 8 REST web service protocol (C. Mortimore, Ed., 2013) is suggested as a base.
Since the two main SCIM types User and Group are extending the CoreResource it is suggested that Concept and ConceptType also extend CoreResource.
Figure 5, SCIM Profile Extension with IAM Concept Dictionary
Subsequently similar REST web service methods should be used for Concept and ConceptType retrieve, create, update, and delete operations. Once the extension is implemented the following SCIM REST operations will be inherited for managing Concepts and ConceptType. Below is copy and paste from SCIM overview site with subsequent replacement of {resource} to illustrate the change for Concepts or ConceptTypes:
8 “... a collection of schemas, i.e., html tags, that webmasters can use to markup their pages in ways recognized by major search providers. Search engines including Bing, Google, Yahoo! and Yandex rely on this markup to improve the display of search results, making it easier for people to find the right web pages.” from http://schema.or g /
- 20 -
Create = POST https://example.com/{v}/Concepts Read = GET https://example.com/{v}/Concepts/{id} Replace = PUT https://example.com/{v}/Concepts/{id} Delete = DELETE https://example.com/{v}/Concepts/{id} Update = PATCH https://example.com/{v}/Concepts/{id} Search = GET
https://example.com/{v}/Concepts?filter={attribute}{op}{value}&sortBy={attributeName}&sortOrder={ascending|descending}
Bulk = POST https://example.com/{v}/Bulk
II. Examples of Business Taxonomies
This work item referenced at least two types of Business Taxonomies: Business Process Taxonomy and Business Product Taxonomies. These terms are coined by Business Process Management standard bodies such as TeleManagement Forum enhanced Telecom Operations Map (eTOM) and CPC — Central Product Classification.
Figure 6, Business Process Taxonomy Structure (Oracle)
The next example from Process Classification Framework (PCF) illustrates how processes can be classified.
- 21 -
,m
Figure 7, PCF Business Process Taxonomy Structure Definitions
The following link is an example of a PCF banking business process taxonomy.
- 22 -
III.x.XACML-3 Extension Profile Proposal
In order to achieve IAM data quality objectives outlined in this work item the following extension profile is proposed:
1. Introduce a new XACML 3.0 (Erik Rissanen, 2013) policy type – Assign Type Policy (circled in with a red solid line) – a policy evaluated during Access Request time. An example is an Access Policy to enforce Segregation of Duties rules during access assign time. On the other hand the Access Type Policy (circled with a red dashed line) is a policy evaluated during run time and it is usually more complex (fine grained).
Figure 8, IAM Schema Fragment emphasizing Assign Policy
2. Enable business semantics for XACML model:
a.Reference Resource attributes via a Business Resource concept id. Business Resource is the leaf node of the Business Product Taxonomy.
b.Reference Action attributes via a Task and Action concept id. Task is the leaf node of the Business Process Taxonomy. Action is the operation performed by Task on the Business Resource.
- 23 -
c.Reference Environment attributes via a Business Context and Session Context concept id. Business Context could provide fine grain business attributes such as account number filter. Session Context that is aware of Authentication state (credentials and device meta-data) could provide information such as IP address and MAC device address for technical fine grain authorization.
Figure 9, Proposed Semantic Extension to XACML Model
IV. IAM Life Cycle Taxonomy
Objective: Create an IAM Context Taxonomy to help disambiguate the IAM Glossary entries that use the same term name.
1. Entitlement Setup Phase a. Role and Attribute Governance b. Policy Design and Development c. Policy Administration Point
2. Entity Enrolment Phasea. Application and initiation b. Identity Proofing
i. Identity Verification c. Entity Registration
3. Access Request and Approval a. Access Request
i. Coarse Grained Accessii. Fine Grained Access
b. Access Request Approval Workflow4. Provisioning and De-Provisioning Phase
a. Credential Management i. Credential Creation ii. Credential Pre-Processing
- 24 -
iii. Credential Initialization iv. Credential Binding v. Credential Issuance vi. Credential Activation vii. Credential Storage viii. Credential Suspension ix. Credential Revocation x. Credential Destruction xi. Credential Renewal and/or Replacementxii. Credential Record-Keeping
5. Runtime Phase a. Runtime Authentication
i. Runtime Session Management 1. Simplified Sign On
ii. Interoperability Services b. Runtime Authorization
i. Policy Decision Pointii. Policy Enforcement Point
c. Resource Access Logging d. Resource Access Monitoring
6. Access Review and Audit Phase a. Access Analysis b. Access Reconciliation c. Application Certification d. Audit Reporting
7. Access Reconciliation Phasea. Security Informationb. Security Event Management
The above taxonomy is striving to be as much chronological in nature as possible. However activities could happen in parallel in the Entitlement Setup and Entity Enrolment phases for example.
- 25 -
Bibliography
Antoine Isaac, E. S. (2009, August 18). SKOS simple knowledge organization system primer. Retrieved August 7, 2013, from w3: http://www.w3.org/TR/skos-primer/
APQC PCF. (2011, June). BANKING PROCESS CLASSIFICATION FRAMEWORK. Retrieved August 7, 2013, from American Productivity & Quality Center (APQC): http://www.apqc.org/knowledge-base/download/33193/PCF_Banking_Ver_5.0.1_2011.pdf
C. Mortimore, Ed. (2013, April 15). System for Cross-Domain Identity Management: Core Schema. Retrieved August 7, 2013, from IETF: http://tools.ietf.org/html/draft-ietf-scim-core-schema-01
CPC Workgroup. (2008, December 31). Central Product Classification, Ver.2, Detailed structure and explanatory notes. Retrieved August 7, 2013, from United Nations Statistics Division: http://unstats.un.org/unsd/cr/registry/regcst.asp?Cl=25
Erik Rissanen. (2013, January 22). eXtensible Access Control Markup Language (XACML) Version 3.0. Retrieved August 7, 2013, from OASIS: http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html
Google, Yahoo, Bing, Yandex. (2011). schema.org. Retrieved August 7, 2013, from schema.org: http://schema.org
Manu Sporny. (2013, August 6). JSON-LD 1.0, A JSON-based Serialization for Linked Data. Retrieved August 7, 2013, from JSON-LD.org: http://json-ld.org/spec/latest/json-ld/
Mohammad, A. (2011, March 7). Ontology-Based Access Control Model for Semantic Web. Retrieved August 7, 2013, from World Academic Union: http://www.worldacademicunion.com/journal/1746-7659JIC/jicvol6no3paper03.pdf
Ray GATES. (2013, February 2). 11179-3: Registry metamodel and basic attributes. Retrieved August 7, 2013, from metadata-standards.org: http://metadata-standards.org/11179/#A3
______________
