x.iamt.draft.spec.09.02.13x - Oasis

splashburgerInternet και Εφαρμογές Web

22 Οκτ 2013 (πριν από 3 χρόνια και 11 μήνες)

98 εμφανίσεις


Contact
:

Radu Marian



Email

radu.marian@baml.com


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 pr
ior written consent of ITU
-
T.


INTERNATIONAL TELECOMMUNICATION UNION

STUDY

GROUP

17

TELECOMMUNICATION

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


-

2

-

Error! No text of specified style in document.


2


Proposed
text
for

draft Recommendation
Identity and Access
Management
Taxonomy

Content
s

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 Over
view

................................
................................
................................
......

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 Extensio
n 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


-

3

-

Error! No text of sp
ecified style in document.


3

1.

Introduction

Currently the enterprise I
dentity and
A
ccess
M
anagement

(
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
not
defined
. The lack of quality in IAM data element definition
s

negativel
y 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 Repor
ting.

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 financi
al 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 d
efiniti
ons 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
e
xisting

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.

-

4

-

Error! No text of specified style in document.


4



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 busi
ness,
application, and data.



Shared
v
ocabulary
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 pr
ocess 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 subj
ect 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 regul
arly 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 aut
hentication 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

(20
1
2
),
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].

A
ccess
C
ontrol
: A procedure used to determine if an entity should be granted access
to

resources, facilities, services, or information based on pre
-
es
tablished rules and
-

5

-

Error! No text of specified style in document.


5

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 de
scribe 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.125
4
].

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.

U
ser
: 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
:

A

human resource container of
Business
Roles

each team member

ha
s

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
:

L
eaf nodes of a Business Process Taxonomy created and maint
ained by
business architects and
business process modellers.

Business Resources
:

L
eaf 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 th
at access

Business Resource
s

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
u
ser
)
.

Access Policy
:

I
s 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
enhance
d Telecom Operations Map

IAM


Identity and Access Management

IP


Internet Protocol

-

6

-

Error! No text of specified style in document.


6

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 objective
s

of this work item is to provide a
common standard mechanism
for

register
ing, referencing, managing
,
defining syntax, and expressing

the
meaning of
IAM
Data Element
s
.

Specifically
:


1.

Provide a
common repository
and service interface for:

a.

Searching IA
M 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 busine
ss meaning
of
IAM data elements.

8.

Approach Overview

There a
re 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)

wo
uld
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)

provide
s

concept identification but lack
s

concept relationship
definition



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.

-

7

-

Error! No text of specified style in document.


7

and does not help meet the two key objec
tives: defining syntax and expressing the
meaning of IAM Data Elements.

The approach taken by this document
incrementally

build
s

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

requirements
,

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.
s
chema.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

vocabulary
4

this approach
will also

have to provide

meaning and syntax
for its

terms.
Th
e
refore 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
input
s

from other related domains
. The foll
owing 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
result
s, making it easier for people to find the right web pages.” from
http://schema.org/


3

Schema.org is an attempt to cover the most popular concept types across many
industries (publishing, health, commerce, etc.) and span
ning 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
p
hrases 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”

-

8

-

Error! No text of specified style in document.


8


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 element
s
.



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

-

Error! No text of specified style in document.


9

9.

IAM Concept Dictionary
Model

Any
controlled

vocabulary

implementation

has an underlying meta
-
model.
The role of
s
uch a

meta
-
model
is to define

the super types
from which other types in the model
extend

from
.
Foremost
IAM Concept Dictionary is
providing
a
n

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 I
AM Concept Dictionary
.


Figure
2
, IAM Concept Dictionary Meta
-
Model


One can assume that a
n 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 unit
s
.
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 im
portant 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, d
ocument 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.

-

10

-

Error! No text of specified style in document.


10

The following table
lists and describ
es
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


a渠楤e湴n晩f爠r潲of䅍⁤A瑡te汥浥湴⁴y灥献†
C潮oe灴pype⁳桯畬搠桡ve⁡⁎ meⰠ䑥晩湩瑩潮Ⱐo
pyn瑡tC潮瑥o琬t
a湤⁖n牳楯渮

InstanceContext


A context for expressing the Concept

Instance
in a form of
a link
ed

data graph fragment.

SyntaxContext

A context for expressing ConceptType syntax

in form of
a link
ed

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
principles
for the IAM D
omain 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.

-

11

-

Error!
No text of specified style in document.


11



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 E
ntitlement 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, o
r
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 Busin
ess 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
.
-

12

-

Error! No text of specified style in document.


12


Figure
3
, IAM Schema Domain Model
-

13

-

Error! No text of specified style in document.


13

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.

-

14

-

Error! No text of specified style in document.


14

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 data
6

non
-
normative
specification
in final stages
called
JSON
-
LD
7

(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
.


SyntaxContext

from ConceptType

InstanceContext

from 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."


}


}


}

}




6

Wikipedia defines Linked Data as "a term used to describe a recommended best practice for
exposing, sharing, and connecting p
ieces 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
.org/


-

15

-

Error! No text of specified style in document.


15

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
.

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
": {


"@typ
e": "
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.
-

16

-

Error! No text of s
pecified style in document.


16

The Action “accesses” is “constrainedBy” zero or more “Access Policies.” Below is an example of
such a concept instance


“Teller” business role:

{


"@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"


}

-

17

-

Error! No text of specified style in document.


17


]


}


}


}


]


}


}

}

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 t
he above syntax context is used as
an
a
ll 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 busi
ness
resource. In this case this

Business Role
is suff
icient 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 numbe
r of Roles


Teller, Cashier, Financial Analyst, etc.

1.

Display the syntax of the Role

2.

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 hierarchy

ii.

Left pane


the Process/Activity/Task descriptions.

b.

Update taxonomy:

i.

Add/Delete/Drag any Process/Activity/Tasks

-

18

-

Error! No text of specified style in document.


18

ii.

Update descriptions.


4.

Application Logging with subsequent Analytics

a.

Leverage an existent reference web application to:

i.

Configure application logging template to use ConceptIDs.

ii.

Generate log files during applicatio
n 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.

-

19

-

Error! No text of specifi
ed style in document.



Appendix

This appendix does not form an integral part of this Recommendat
ion.

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 Concep
t 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



8

“System for Cross
-
domain Identity Management (SCIM) specification is designed to make
managing user identities in cloud
-
based applications and services easier.” From
http://www.simplecloud.info/


-

20

-





and paste from SCIM overview site with subsequent replacement of
{resource}
to illustrate the
change for

Concept
s or ConceptTypes:



Create = POST
https://example.com/
{v}/
Concept
s



Read = GET
https://example.com/
{v}/
Concept
s
/{id}



Replace = PUT
https://example.com/
{v}/
Concept
s
/{id}



Delete = DELETE
https://example.com/
{v}/
Concept
s
/{id}



Update = PATCH
https://example.com/
{v}/
Concept
s
/{id}



Search = GET
ht
tps://example.com/
{v}/
Concept
s
?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
B
usiness
P
rocess
T
axonomy

Structure D
efinitions


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 f
ollowing extension
profile is proposed:

1.

Introduce a new
XACML
3.0
(Erik Rissanen, 2013)

policy type


Assign Type

P
olicy (circled in with a red solid line)


a policy
evaluated
during Access Request
time
. An example is an Access Policy
to enforce Segregat
ion of Duties
r
ule
s

during
access assign time
.
On the other hand t
he 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 th
e same term name.


1.

Entitlement
Setup Phase

a.

Role and Attribute Governance

b.

Policy Design and Development

c.

Policy Administration Point

2.

Entity
Enrolment

Phase

a.

Application and initiation


b.

Identity Proofing

i.

Identity Verification

c.

Entity Registration

3.

Access Request and Approval

a.

Access Request

i.

Coarse Grained Access

ii.

Fine Grained Access

b.

Access Request Approval Workflow

4.

Provisioning and De
-
Provisioning Phase

a.

Credential Management

i.

Credential Creation

-

24

-





ii.

Credential Pre
-
Processing

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 Replacement

xii.

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 Point

ii.

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 Phase

a.

Security Information

b.

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/downloa
d/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, Decemb
er 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).
eXtensibl
e 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

______________