SlideShare a Scribd company logo
1 of 27
Download to read offline
50 data principles for loosely coupled identity management v1 0
“50 Data Principles for Loosely-Coupled Identity Management”
Version 1.0, May 2013
© Ganesh Prasad
This work is licensed under Creative Commons Attribution-No Derivs 3.0 Australia
http://creativecommons.org/licenses/by-nd/3.0/au/
Table of Contents
The Importance of the Data Model for Identity Management..............................................................................................................................................................4
Domain, Entity, Identifier and Attribute................................................................................................................................................................................................ 5
Illustration...................................................................................................................................................................................................................................... 6
Identity Federation............................................................................................................................................................................................................................. 7
Identity Life-cycle............................................................................................................................................................................................................................... 8
Merging of Entity Identities............................................................................................................................................................................................................ 9
Splitting of Entity Identities........................................................................................................................................................................................................... 10
The Life-cycle of External Identifiers............................................................................................................................................................................................ 11
Identity Establishment, Degree of Trust, Credentials and Authentication..........................................................................................................................................12
Illustration.................................................................................................................................................................................................................................... 13
The Life-cycle of Credentials....................................................................................................................................................................................................... 14
Single Sign-On – A Poster Child of Access Management.................................................................................................................................................................16
Access Management – Intra-Domain (Data Stores and Data Flows)...........................................................................................................................................17
Access Management – Inter-Domain (Data Stores and Data Flows)...........................................................................................................................................18
Identity Management and Provisioning – Intra-Domain....................................................................................................................................................................19
Illustration.................................................................................................................................................................................................................................... 20
Identity Management and Provisioning - Inter-Domain.....................................................................................................................................................................21
Illustration.................................................................................................................................................................................................................................... 22
Authorisation / Entitlements.............................................................................................................................................................................................................. 23
Propagation of Role Identity........................................................................................................................................................................................................ 24
Domain Models and the Identity of Domain Entities.........................................................................................................................................................................25
Miscellaneous Aspects of Security................................................................................................................................................................................................... 26
Summary and Conclusions.............................................................................................................................................................................................................. 27
About the Author.............................................................................................................................................................................................................................. 27
The Importance of the Data Model for Identity Management
Our previous publication (“Identity Management on a Shoestring”) introduced the concept of loose coupling in the domain of Identity and Access Management
(IAM) and described in detail the architecture of a lightweight, low-cost, loosely-coupled corporate IAM system.
With the advent of Cloud Computing, “Identity Management in the Cloud” has become a hot topic, and many standards have emerged to deal with the challenges
of IAM at Web scale. The older XML-based trio of protocols – SAML for authentication, XACML for authorisation and SPML for provisioning – have achieved only
mixed success, with only SAML having gained some traction in enterprise systems. But in the new world of the cloud, more lightweight alternatives are in
demand. The “OAuth2 family” of protocol standards promises to deliver what the industry is asking for.
The OAuth2 protocol itself, as a means of enabling constrained delegated authorisation of access, is an excellent base technology to protect other IAM APIs
(protocols), – specifically, such APIs as OpenID Connect for Authentication and SCIM for User Provisioning1
.
However, the OAuth2 family of protocols is by itself only a necessary and not a sufficient enabler. A well-designed protocol requires a flexible data model
underpinning it, and both need to be based on sound principles.
The most common mistake made by practitioners is the assumption that Identity Management is a technology problem. Regrettably, the transition from corporate
IAM to cloud-based IAM has not changed that mindset. Solutions are almost always sought in the realm of technology products and protocols, and data models
are relatively neglected. IAM projects therefore generally incur significant cost, but their record of success is not very encouraging. The irony is that identity-
related problems can be effectively sorted out, and at far lower cost to boot, if the focus is placed where it belongs, i.e., on data. Identity management is primarily
a data problem, not a technology problem.
In this document, we will talk about important data principles and end by summarising the most common industry mistakes relating to data modelling.
In a separate article (“Don't SCIM over Your Data Model”), we pointed out specific examples in the SCIM (System for Cross-domain Identity Management)
provisioning standard where a data model based on certain principles could greatly improve the protocol. Here, we attempt to enunciate as many data-related
principles as possible to support all the major aspects of Identity and Access Management. Some of these principles may appear trivial and obvious, while others
may appear counter-intuitive or unnecessary. Nevertheless, we have found these principles useful in our own practice. They are unfortunately not commonly
applied, which is why Identity and Access Management is often such a bugbear. We believe IAM (and not just Cross-domain Identity Management) will become
much simpler if this model is followed.
1SCIM used to stand for “Simple Cloud Identity Management” but now stands for “System for Cross-domain Identity Management”, which is more generic.
4
Domain, Entity, Identifier and Attribute
Principle 1 (All Identity is contextual): An Entity's Identity is not an absolute concept but is only meaningful within a Domain or a Universe of Discourse, i.e., within
some well-defined area of interest. (“John” in a social Domain is a different Identity from “Mr. Smith” in a corporate Domain, and is different again from “dad” in a
family Domain. All of them could be the same person, but trying to distil some fundamental Identity that exists outside all these Domains is generally neither
feasible nor worthwhile. Domain-specific Identities are more natural to model, and it is much more practical to simply associate these Domain-specific Identities
with one another when required. In other words, an Identity (for any Entity) that is independent of a Domain or that exists outside of all Domains is a chimera.
Principle 2 (Uniqueness is the essence of Identity): Domains may contain many types of Entities, and within each type, there could be many individual Entities, or
instances. These instances need to be distinguished from others of the same type, i.e., Entities (or more correctly, Entity instances) have unique Identity. If
something does not have a unique Identity, then it is by definition not an Entity (e.g., “Value Objects” in Domain-Driven Design).
Principle 3 (Identity is independent of Attributes): Entities have properties or Attributes with business meaning, and these Attributes are what make Entities
“interesting” to the Domain in the first place. So it will seem counter-intuitive to assert as we do here that an Entity really has no inherent Attributes with business
meaning! However, this principle aids flexibility by not imposing constraints. An analogy is the Standard Model of Particle Physics (recently validated through the
confirmation of the Higgs boson's existence). A core aspect of the Standard Model is that particles do not inherently have mass. Some of them acquire mass
through interaction with the Higgs field, which explains why other particles like photons have no mass. A loosely coupled model for Identity similarly decouples an
Entity from all its meaningful Attributes. This is extremely useful in cases where anonymous Identity is to be tracked analogous to persistent cookies in browsers.
Principle 4 (Identifiers must have no business meaning): The only inherent Attribute of an Entity is a unique and meaning-free Identifier that serves only to
distinguish it from other Entities in the Domain. It is critically important that the identifier be free of all business meaning, because it will otherwise have to change
when the business context changes. E.g., using a person's email address as their identifier would require changing the identifier when the user changes ISPs. A
meaningless string of characters is a much better identifier, because there would be no reason to change one for another. Identities are more “stable” when
Identifiers are meaningless.
Principle 5 (An Entity needs at least one “private” Identifier): An Entity's inherent Identifier attribute is private to the Domain in which the Entity is known and is
never visible outside the Domain. There can be additional identifiers that are made public and explicitly designated as External Identifiers (described under
Federated Identity). However, revealing a private identifier to third parties creates dependencies that can prevent necessary housekeeping operations such as
splitting and merging identities (as will be discussed in a later section). The existence of external (public) Identifiers does not obviate the need for a private one.
Principle 6 (Attribute model): All Attributes of an Entity (including all its External Identifiers) are associated with the Entity through its Domain-private Identifier.
Attributes may be simple (a name-value pair), multi-valued/repeating (a name with multiple values of the same type) or composite (a collection of dissimilar
Attributes). Combinations of these are also possible, to any arbitrary level of complexity.
Principle 7 (Every attribute value must have its own unique Identifier): For non-repeating Attributes, the attribute's name is itself its unique Identifier within the
namespace of the Entity. This is true for simple attributes (e.g., “date-of-birth”) as well as composite attributes (e.g., “address.post-code”). Similarly, each element
of a multi-valued (repeating) Attribute must also be assigned a unique, meaning-free Identifier of its own (i.e., not a mere positional index). The reason for this
Identifier will become clearer when we see how it can be used to support provisioning operations.
5
Illustration
6
Example
Domain: “Asia-Pacific Region”, “Small & Medium Businesses”,
“Employees”, etc.
Entity: “Customer”, “Product”, “Employee”, etc.
Domain-private, meaning-free Identifier:
“0d72c8ca-8b97-416c-9e2e-6f1695011e9e” (a UUID)
External Identifier:
“0800200c9a66” (some unique string)
“ad28ce96-aea2-41f0-bdfd-c926682ad37f” (another UUID)
Simple Attribute: Date of Birth
Repeating Attribute: Email addresses – {UUID, address
string}* (Note the per-value identifier, the UUID)
Composite Attribute:
Full name (Title, First name, Last name)
Repeating, composite attribute:
Addresses – {UUID, Address type (home/business), Street
number, Street name, Street type, Suburb, Post code, State,
Country}* (Note the per-value identifier, the UUID)
Domain X
Entity
Composite Attribute
Domain-private
Identifier
Simple
Attribute
Attribute 2 Attribute 4
Attribute 1
Attribute 3 Attribute 5
Name Value
N
N
N
N
N
V
V
V
V
V
V
Identifier
V
Identifier
N
Repeating
Attribute
Identifier
V
N
V
External
Identifier 1
External
Identifier 2
Visible to
Domain Z
Visible to
Domain Y
Identity Federation
Entities must often be referenced outside their Domain. Some of these references may be to associate Entity instances in two or more Domains because they
refer to the same logical Entity.
Principle 8 (Federated Domain model): No Domain is the “centre of the universe”. All Domains are co-equal, and no Domain can dictate any aspect of an Entity's
identity within another Domain, although they may notify one another of Entity life-cycle events (i.e., creation, deletion/deactivation or a change in attributes).
Domains cannot make assumptions about how other Domains will act on an Entity's life-cycle events.
Principle 9 (Federated Identifier model): External Identifiers are special Attributes that also uniquely identify an Entity within a Domain (like “candidate keys” in
relational database tables). When Entity instances are associated across two Domains, the Domains should share a common External Identifier for the Entity and
map/associate this External Identifier to their respective Internal Identifiers. Neither Domain must see the other's Internal Identifier for the Entity.
7
Staff Member as Customer
Domain: Customer
Domain-private Identifier:
a224dadc-bb7b-4011-97ec-c8ba1336e65f
Attributes: Customer category (Platinum, Gold, Silver), etc.
External Identifier:
f6302ada-aece-4869-aeba-43a735f081a3
Domain: Staff
Domain-private Identifier:
c0e790e4-6466-43f3-8d52-253c3f75349b
Attributes: Employee number, etc.
External Identifier:
f6302ada-aece-4869-aeba-43a735f081a3
Same person
Domain A
Entity X
Domain-private
Identifier 'x'
Attribute(s)
External
Identifier 'q'
Domain B
Entity Y
Domain-private
Identifier 'y'
Attribute(s)
External
Identifier 'q'
External
Identifier 'p'
External
Identifier 'r'
Shared
reference
Identity Life-cycle
Apart from the standard life-cycle events of creation, modification and deletion that apply to an Entity, there are events that are peculiar to its Identity. These
require special rules and special processes.
Principle 10 (Identifiers are forever): The life-cycle of an Entity's Identifiers (both Domain-private and External) is independent of the life-cycle of the Entity itself.
Once created, an Identifier exists in perpetuity. An Entity may cease to exist, but the Identifier must not be recycled, i.e., used to refer to another Entity thereafter.
Identifiers are created to be used for one Entity only, and form a useful reference to historical data even after the deletion of the Entity. (Of course, an Entity can
be referred to by more than one Identifier, simultaneously as well as over the lifetime of the Entity.)
There is an apparent exception to this principle. Within a Domain, it may sometimes be discovered that what were hitherto wrongly considered to be two or more
Entities are actually the same (a false negative), or that what was wrongly considered a single Entity is actually more than one (a false positive). It will be
necessary in such cases to merge or split Identities. When doing so, it will be necessary to change the association between External Identifiers and Domain-
private Identifiers, which may seem like a violation of the above principle. However, in spirit, the Identifiers still refer to the same Entity. Only the previous model
of the Entity was incorrect. With a suitable audit trail to document the merge or split, historical attributes and events can still be related back to an Entity.
An important effect of having External Identifiers mapped to Domain-private Identifiers is that any splitting or merging of Entities that is necessitated by the
requirement to fix errors (false negatives and false positives) within a Domain need not be exposed immediately to external Domains. It is possible for the
mapping to hide these changes and have them communicated at a more convenient time, and only if necessary.
Principle 11 (Merging of Identity): Merging two or more Entity Identities should be done by dropping all but one Domain-private Identifier. All the External
Identifiers of the other Identities should now be associated with the sole remaining Domain-private Identifier. All the various attributes of those Identities should
now be associated with this single Domain-private Identifier, merging and reconciling them as required. E.g., if two Entities referred to by the External Identifiers
“J Smith” and “John Smith” are recognised to be one and the same, they must now have the same Domain-private Identifier, although the External Identifiers “J
Smith” and “John Smith” may continue to exist, with both now associated with the same Domain-private Identifier. If John Smith has two valid phone numbers,
and each of his previous Identities was associated with one, the merged Identity should have both. If the two earlier Identities had different addresses and only
one turned out to be valid, then the discrepancy should be reconciled by dropping the invalid one and associating the remaining with the Domain-private identifier.
Other Domains relying on these External Identifiers will not (and should not) be impacted by the clean-up within this Domain.
Principle 12 (Splitting of Identity): Splitting Entity identities should be done by creating new Domain-private Identifiers for the Entities that have to be created out
of the original one. Existing Attributes should be distributed among the new Entities by associating them with the appropriate Domain-private Identifiers. In some
cases, Attributes may apply to more than one of the Entities, and will need to be duplicated. New External Identifiers may be created for the newly created
Entities and exposed to other Domains if and when required. E.g., if it is discovered that an Entity with an External Identifier of “John Smith” actually refers to two
different people, then only one of them should be allowed to carry this Identity going forward. The other should be given a new Identity (a new Domain-private
Identifier) and can be gradually introduced to other Domains through a new External Identifier, (say) “John G Smith”. If the original Entity had a “Date of Birth”
attribute with the value “1 Jan 1970”, and this was found to be valid for both the Entities after the split, then the attribute should be duplicated and applied to both
through association with their respective Domain-private Identifiers.
8
Merging of Entity Identities
9
Entities X and Y are discovered to be the same (a “false negative”). The two Entity identities should be merged.
Domain A
Entity X
Domain-private
Identifier 'x'
Attributes
of X
Entity Y
Domain-private
Identifier 'y'
Attributes
of Y
External
Identifier 'p'
External
Identifier 'r'
Visible to Domain B Visible to Domain B
Domain A
Entity X
Domain-private
Identifier 'x'
Merged
attributes
of Entities
X and Y
Entity Y
Domain-private
Identifier 'y'
External
Identifier 'p'
External
Identifier 'r'
No longer exists
No longer referenced and
never recycled (i.e., never
used for another Entity)
Visible to Domain B
Visible to Domain B
(No change detected)
Domain B can be notified of the merge
at a convenient later time, or not at all.
Splitting of Entity Identities
10
“Entity X” is discovered to be representing two Entities (a “false positive”). The Entity identity should be split.
Domain A
Entity X
Domain-private
Identifier 'x'
Attributes
of X
External
Identifier 'p'
Visible to Domain B
Domain A
Entity X
Domain-private
Identifier 'x'
Attributes
rightfully
belonging
to X
Entity Y
Domain-private
Identifier 'y'
External
Identifier 'p'
New External
Identifier 'r'
Visible to Domain B Made visible to Domain B
when required
Domain B can be notified of the split at a convenient later time, or not
at all. In some cases, Domain B may need to be notified immediately.
Attributes
from X that rightfully
belong to Y
The Life-cycle of External Identifiers
Managing the life-cycle of Domain-private Identifiers is relatively easy, as we have shown, because there are few (if any) external dependencies on them.
However, the same cannot be said about External Identifiers, which by definition, are visible externally and therefore have external dependencies.
Example: Two independent, legacy applications with their own user stores need to be gradually decommissioned in favour of a new, integrated application. In
other words, two legacy Domains are to be merged into a third one. (The legacy Domains may continue operating in parallel for a while, provisioning new users
using independent legacy logic even as they are being migrated.) The treatment of Domain-private Identifiers is relatively straightforward as described in the
previous section. If UUIDs are used in the legacy Domains, it may even be possible to migrate them unchanged without conflict since UUIDs share a universal
namespace to start with. However, conflict is possible between External Identifiers because two namespaces are being collapsed into one. Hence specific
strategies are required to manage these conflicts.
Principle 13 (Maintain visibility of changes to External Identifiers): External parties that have built a dependency on External Identifiers in legacy Domains must
understand that a migration is taking place and that a change in their Identifiers may be required. Setting expectations is key, because a seamless migration (i.e.,
no change to any External Identifier) is not realistic.
Principle 14 (Determine a conflict resolution protocol): In the interest of least disruption, a protocol to resolve conflicts should be agreed before migration (e.g.,
“first come, first served” or “Domain 1 over Domain 2”). Only one claimant to an External Identifier that migrates to the new, merged namespace can be granted
the right to use the Identifier. Other claimants will be required to choose another Identifier. The converse is not true. When false negatives are detected and
merged into a single Entity, it can still retain all its External Identifiers.
Principle 15 (Handle false conflicts): Although it is possible that External Identifiers from two or more legacy Domains will conflict in the merged namespace of the
new Domain, this may simply be because they refer to the same logical Entity. This is a special case of a false negative, and will need to be detected as part of
the migration process along with other false negatives. Their Domain-private Identifiers and attributes will need to be merged, of course, but their common
External Identifier can be preserved without change because it relates to the same logical Entity.
11
Legacy Domain A
Entity X
Domain-private
Identifier 'x'
External
Identifier 'p'
Migration
New Domain Q Legacy Domain B
Entity Y
Domain-private
Identifier 'y'
External
Identifier 'p'
Entity X
Domain-private
Identifier 'x'
External
Identifier 'p'
Entity Y
Domain-private
Identifier 'y'
External
Identifier 'p'
Migration
Use
the 'split'
technique
in case of
conflict
This conflict is
harder to reconcile
Identity Establishment, Degree of Trust, Credentials and Authentication
Principle 20 (Identity Establishment): Identity Establishment is a more general concept than Authentication. Identity Establishment within a Domain is simply the
determination of an Entity's Domain-private Identifier through any means. Identity Establishment is the pre-requisite for most meaningful business functions
involving the Entity, since all Attributes are associated with the Domain-private Identifier.
Principle 21 (Trust model): The nature of the means through which an Entity's Identity is established determines the Degree of Trust associated with the Identity.
A mere reference to an Entity's Domain-private Identifier is sufficient to establish the Identity of the Entity that is being discussed, but the Degree of Trust in the
accuracy of that reference could vary based on how it came about.
Principle 22 (Authentication): If a “sufficiently high” Degree of Trust is achieved in the establishment of an Entity's identity, “Authentication” can be said to have
taken place. In other words, the assertion or claim that an Entity's identity is such-and-such is accepted. How high the Degree of Trust needs to be in order to be
considered “sufficient” varies with the Domain, hence Authentication is a more fuzzy concept than Identity Establishment. In practice, Authentication occurs either
(1) when the Entity itself presents one of its External Identifiers along with one or more matching (security) tokens that other Entities are unlikely to possess or
have knowledge of, or (2) when an External Identifier for the Entity is propagated from another (trusted) Domain in a tamper-proof way. In either case, the
Domain-private Identifier for the Entity can then be determined with a high Degree of Trust through its association with the External Identifier that is presented.
Authentication implies Identity Establishment but not the other way around.
Principle 23 (The Degree of Trust is not static): The Degree of Trust can depend on a variety of factors, such as the strength of the security tokens presented to
validate an Identifier, the channel through which the access takes place, the time elapsed since the Identity was established, etc. The strength of the security
tokens is important since some sensitive functions may require stronger tokens to be presented when they are accessed. The channel is important because the
Identities of users from a trusted network or using a trusted device are established with a higher Degree of Trust than those from untrusted networks or devices.
(Of course, a conservative model is to treat all networks and devices as untrusted.) The time elapsed is important since the Degree of Trust can “decay” with
time, requiring periodic renewal. This latter aspect clearly distinguishes Identity Establishment from Authentication, since the Identity continues to be valid, but a
degradation in the Degree of Trust may require re-Authentication.
Principle 24 (Credentials): The combination of an Identifier and a security token is referred to as a set of Credentials. A security token may be associated with a
specific External Identifier or with the Domain-private Identifier for the Entity. The latter association can provide greater flexibility in certain cases, such as when
allowing a customer to identify themselves in a variety of ways but requiring them to remember only one password.
Principle 25 (Identity Establishment and Authentication can occur in any sequence): Identity Establishment and Authentication can occur in different domains and
in any arbitrary sequence. The Degree of Trust in each domain can also vary accordingly. If Authentication is done in one Domain and the Identity is propagated
securely to another Domain, then Identity Establishment occurs after Authentication. The Degree of Trust could be high in both Domains. If one Domain merely
propagates an Identity to another, and the second Domain establishes the Identity and then performs Authentication, then the order is reversed. The Degree of
Trust may only be high in the second Domain.
12
Illustration
(1) The Domain receives a set of Credentials in the form of an Entity's External Identifier 'p' and a Security Token that is associated with that specific Identifier. If
the token matches the value stored, then the Entity is deemed authenticated and its Identity is established to be the Domain-private Identifier 'x', with a high
Degree of Trust.
(2) and (3) The Domain receives a set of Credentials in the form of an Entity's External Identifier ('r' or 's') and a Security Token that is associated with the Entity's
Domain-private Identifier 'x'. If the token matches the value stored, then the Entity is deemed authenticated and its Identity is established to the be Domain-
private Identifier 'x', with a high Degree of Trust. What distinguishes the latter two cases from (1) is that all External Identifiers share a single Security Token,
which makes security easier to manage, both for the Domain and for the Entity. E.g., a customer may present either a user name or a primary email address as
their External Identifier, but only have to remember a single password. Changes to passwords then also apply uniformly to all Identifiers.
(4) The Domain receives an Entity's External Identifier 'q' from a trusted external Domain in a way that is guaranteed against tampering. Although no associated
Security Token is received, the tamper-proof assertion of the External Identifier is itself considered a Security Token. There is a high Degree of Trust in the
association of the External Identifier 'q' to the Domain-private Identifier 'x', and the Entity is taken to be Authenticated.
(5) The Domain receives an Entity's External Identifier 't' through a less trusted mechanism. The Entity's Identity can be established to be Domain-private
Identifier 'x', but the Degree of Trust associated with this Identity is lower. It may be sufficient for certain purposes but not for others. Establishing a user's Identity
by validating a weak surrogate such as their mobile number falls under this category.
13
Trusted Domain
Entity
Domain-private
Identifier 'y'
“My” Domain
Entity
Domain-private
Identifier 'x'
External
Identifier 'p'
External
Identifier 'r'
Identifier-specific
Security Token
External
Identifier 's'
Domain-wide
Security Token
for Entity
Entity-Scoped
Credentials
Entity-Scoped
Credentials
Identifier-
Scoped
Credentials
External
Identifier 'q'
External
Identifier 'q'
External
Identifier 't'
1
2
3
4
5
The Life-cycle of Credentials
The life-cycle of Credentials is related to that of External Identifiers. Domains that merge often have to merge Credentials as well, and this presents further
problems.
Principle 16 (Credentials are for the Entity, not the Identifier): In legacy Domains with a relatively simplistic Identity model, Credentials are usually associated
directly with External Identifiers, and there is no separate internal Identifier. In the new Domain, Credentials should be associated with the Domain-private
Identifier rather than with any External Identifier (See following section on Authentication). This can also prove friendlier to users when Domains are merged,
because they can still use any of the External Identifiers they are used to, but only have to remember a single password, for example.
Principle 17 (Limit the number of Credentials per Domain): A Domain should standardise upon one set of Credentials of the appropriate strength and discard all
others. External parties with a dependency on these Credentials need to be notified of the consolidation and allowed to select the one they want to retain. In rare
cases, more than one set of Credentials may need to be stored, such as to enforce “step-up” Authentication when accessing more sensitive functions.
Ideally, Credentials must be stored in only one place, without duplication. Sometimes, due to legacy dependencies, it may not be possible to consolidate the
storage of Credentials. In that case, their values should be harmonised across physical stores using MDM principles.
Principle 18 (Employ Master Data Management to keep redundant Credentials consistent): Updates to credentials should follow MDM principles (Also discussed
under Provisioning). One store should be designated the “source of truth”, i.e., the only one updated by business logic. All others should be treated as read-only
replicas and robustly refreshed from the source of truth, either in real-time or using an eventual consistency model.
14
Principle 19 (Robustness): (Caution: This principle trades off security for user-friendliness.) The principle of robustness in communications is to “be conservative
in what you produce and liberal in what you consume”. In similar fashion, IAM should be conservative while provisioning (i.e., provisions to ALL stores using
MDM) and liberal while authenticating (accepts validation against ANY store).
How robustness is ensured: When a user changes their password on the source of truth, the expected replication to secondary stores may fail. Normally, this
would pose a problem if there are applications that authenticate against these secondary stores. However, Authentication will still succeed because all stores are
checked and a successful validation against any one of them is taken as successful authentication, hence replication failures will not impact users and the system
as a whole is robust.
However, note that this approach also successfully authenticates the previous password. If the password had had to be changed because it was compromised,
then this is clearly a security loophole. Hence this approach must be used with caution.
15
Credential Store 1 Credential Store 2
1. Initial Provisioning
2a. Change
of password
2b. Replication
(may fail)
3a. Authentication with new password
(Step 1 - fails)
3b. Authentication with new password
(Step 2 - succeeds)
Single Sign-On – A Poster Child of Access Management
Principle 26 (Single Sign-On): Single Sign-On (SSO) is defined in different ways, but the most general one is that a user attempting to access a related group of
systems (i.e., an SSO environment) is challenged for their credentials only once per “session”, whatever those credentials may be and however that session may
be defined (See Single Sign-Out below). There could be multiple sets of credentials that could be used, but only one set is required for a given session. There
could be multiple initial entry points into the SSO environment, and a different one could be used in each session, and each such entry point may require a
different set of credentials, but once the challenge has been successfully met, no further challenge is made for the rest of the session. Hence this is the definition
that covers all use cases including federation.
Principle 27 (SSO Token model): The data model to support SSO is largely independent of the core Identity model and consists of a set of tokens. There is a
single token for SSO itself, which ensures that a second challenge does not occur within the same session. There is a second set of tokens that are each specific
to one particular application or resource that is being accessed. Authentication is sufficient to grant the SSO token, but Authorisation rules are consulted for each
application or resource for which access is being attempted, and only successful authorisation will result in the grant of the application/resource access token.
Both tokens are required before a user can access an application or resource in an SSO environment.
Principle 28 (SSO and Identifiers): When SSO covers a single Domain, the Domain-private Identifier for an Entity can be freely exchanged inside tokens passed
between systems as part of the SSO protocol. When SSO covers multiple Domains (“federated SSO”), appropriate mapping to External Identifiers must be
performed and only External Identifiers may be communicated between Domains as part of the SSO protocol (e.g., within SAML tokens). Once Authentication
completes, Identity is established, i.e., the Domain-private Identifier is known to the SSO system. Either this or a suitable External Identifier associated with it
should be populated within the appropriate tokens and passed to participating (trusted) systems, depending on whether they are within the Domain or in external
Domains.
Principle 29 (SSO and Coarse-grained Authorisation): The SSO system should only perform coarse-grained authorisation checks (explained in detail later).
Coarse-grained Role Identifiers may be populated within application access tokens passed to applications in addition to the user's Identifier (Domain-private or
External). The application itself should perform fine-grained authorisation checks using its knowledge of the user's Identifier. This keeps the SSO system
manageable in terms of logistical complexity, especially as the number of protected applications increases, because each application will have its own specialised
roles and access rules.
SSO has a number of side-effects, some of which may be seen as undesirable. If an application that is sensitive from a security viewpoint shares an SSO
environment with other applications that are not sensitive, then there is a potential risk, because it is not possible to “log out” of the sensitive application if any of
the other applications is being used. The SSO session is deemed to be active, and it will be possible to acquire unchallenged access to the sensitive application
at any time, since a second challenge is never issued during an SSO session.
Principle 30 (Ending SSO Sessions): As far as possible, sensitive and less sensitive applications should not be combined within the same SSO environment.
Extra protection such as decay in the Degree of Trust requiring fresh authentication may be employed. This bends the definition of SSO a little by requiring a
fresh challenge during a session but provides greater security for sensitive apps. An alternative is “Single Sign-Out”, under which logging out of a sensitive
application ends the SSO session altogether and requires fresh authentication before access is granted again to any system. It may be argued that Single Sign-
Out defeats the purpose of Single Sign-On.
16
Access Management – Intra-Domain (Data Stores and Data Flows)
17
Domain
Application A Application B
Authentication
Data Store
Coarse-grained
Authorisation
Data Store
SSO Server
ID mapping
Data Store
Client Application
(Browser)
Fine-grained
Authorisation
Data Store A
Fine-grained
Authorisation
Data Store B
Token
Data Store
User Attribute
Data Store
Logical IAM
Data Stores
Temporary store for
SSO Token and
Application Access Tokens Credentials:
External ID + Security Token(s) OR
Domain-private ID + Security Token(s)
- Domain-private ID to
External ID(s)
- Domain-private ID to
Coarse-grained Roles
- Roles to Application
Access
- Domain-private ID to
other Entity Attributes
- Domain-private ID to Fine-grained Roles
- Roles to Function Access
- Domain-private ID to Data Access (Rules)
Credentials:
ID + Security Token(s)
SSO Token
+ Application
Access Token(s)
Application Access Token A
+ Domain-private ID
+ Coarse-grained Roles
+ User attributes
Application Access Token B
+ Domain-private ID
+ Coarse-grained Roles
+ User attributes
Authentication
Coarse-grained
Authorisation
User attribute
retrieval
Fine-grained
Authorisation
Fine-grained
Authorisation
Store / Retrieve
Access Management – Inter-Domain (Data Stores and Data Flows)
18
Domain YDomain X
Application A
Client Application
(Browser)
Application P
SSO Server X
IAM
Data Store X
Credentials
Tokens
Application Access Token A
(includes Domain-private
Identifier as attribute)
Application Access Token P
(includes External Identifier
as attribute)
(Because of the focus on
data, not all flows of the
federated SSO protocol are
shown)
Identity Management and Provisioning – Intra-Domain
Data pertaining to an Entity may be distributed across multiple physical data stores in a geographically dispersed way within a logical Domain. Each physical data
store may use a different identifier (unique within that data store alone) to refer to the Entity. Entity attributes may also be replicated (redundantly stored) across
multiple data stores. More than one system may be responsible for creation of new Entity instances, for updating Entity attributes or for marking the
deletion/deactivation of Entity instances.
Principle 31 (Harmonise entity data into a single logical record): The Domain-private Identifier is a “candidate key” in every data store (although it will not replace
the existing primary keys in any of them). It should be used to associate Entity data across multiple physical data stores within the Domain to effectively create a
single logical Entity record. Physical consolidation of Entity data into a single data store is neither necessary nor (in general) cost-effective.
Principle 32 (Advantages of the UUID format): Adopting the UUID format for the Domain-private Identifier allows multiple systems to independently create Entity
instances if required. There is negligible danger of Identity conflict, since the probability of two random UUIDs having the same value is extremely low (about 1 in
10^33). It is meaning-free, which is a major advantage in avoiding external dependencies. It allows different Domains to implement IAM at different speeds and
yet interoperate or even merge when required. It also enables the adoption of an “eventual consistency” model for Entity Identity through the gradual merging of
false positives, which is a more pragmatic approach than an aspiration for 100% consistency at any instant in time.
Principle 33 (Intra-Domain Provisioning Event model): Provisioning events are of 5 major types: (1) Entity creation, (2) Entity deletion/deactivation, (3) Entity
update (add new attribute), (4) Entity update (update attribute value) and (5) Entity update (delete attribute). In cases (4) and (5), if the attribute is multi-valued,
then the specific instance of the value to be updated or deleted needs to be identified with its own unique identifier (UUID). In case (3), if the attribute is multi-
valued, the provisioning request must receive a response with the unique identifier (say, a UUID) of the newly-created value. Case (4) could include arbitrary
nesting of operations on nested attributes. It is of course the implementation's responsibility to handle this arbitrarily complex logic, but the data construct to
support such nested operations is quite simple, i.e., a unique identifier for each value of a multi-valued attribute at any level in the hierarchy.
Principle 34 (Attribute Identifier model): Ideally, each value of a multi-valued attribute must have an Internal Identifier and one or more External Identifiers that are
loosely associated through mapping. This improves flexibility but unlike with Entities (where splitting and merging of Identities is a constant possibility), the use
cases may not always justify the added complexity of having more than one Identifier per attribute. This is completely optional and dependent upon the use cases
that are anticipated.
Principle 35 (Employ Master Data Management for provisioning): Adopting Master Data Management (MDM) principles allows Entity data to be kept consistent
within the Domain in spite of replication. Specifically, every attribute must have a designated source of truth, and all other instances of that data must be deemed
to be read-only replicas. Only the source of truth can be updated by business logic. Replicas must only be refreshed from the source of truth. All Entity life-cycle
events must be propagated from the appropriate source of truth, and all data stores holding replicas must listen on these events and update the replicas. This is a
federated model, and the unique Domain-private Identifier reference is the required logical link across all data stores.
Principle 36 (Reliability of Provisioning): A reliable event delivery mechanism is required to implement this model of MDM. Specifically, messages must be
persistent (they must not be lost even if there is a system failure somewhere) and subscriptions must be durable (messages must be ultimately delivered even if
a subscriber was temporarily off-line). Alternatively, an idempotence model of reliability may be used. Both models assume eventual consistency.
19
Illustration
20
Domain
Data Store A
Entity Instance
Attributes
(sources of truth)
Local
Primary Key
Domain-private Identifier
(Candidate Key)
Attributes
(replicas)
Data Store B
Entity Instance
Attributes
(sources of truth)
Local
Primary Key
Domain-private Identifier
(Candidate Key)
Attributes
(replicas)
Data Store C
Entity Instance
Attributes
(sources of truth)
Local
Primary Key
Domain-private Identifier
(Candidate Key)
Attributes
(replicas)
Entity Lifecycle Events (referenced by Domain-private Identifier)
Source of
truth changed
Replica
updated
Source of
truth changed
Replica
updated
Replica
updated
Source of
truth changed
Identity Management and Provisioning - Inter-Domain
Inter-Domain, or Cross-Domain provisioning is very topical because of the rapid adoption of cloud-based solutions to many problems. The SCIM protocol has
been proposed to standardise provisioning operations between Enterprise Customers and Cloud Providers.
Cross-Domain Identity Management and provisioning are similar to their counterparts within a Domain, with two important exceptions:
1. Domain-private Identifiers are never exposed outside the Domain, as mentioned earlier. Special External Identifiers are shared by two or more Domains to
refer to the same instance of an Entity, and they each map these External Identifiers to independent Domain-private Identifiers internally within their respective
Domains.
2. Within a Domain, there are multiple data stores that may hold Entity data, each with its own internal primary key for the Entity. The Domain-private Identifier
acts as a candidate key in all the data stores within a Domain and is the logical “primary key” for the Entity within the Domain. This analogy does not hold
between Domains. There is no “super-Domain” that performs a similar role that a Domain performs for the data stores within it. Hence there is no “super-Identifer”
that can act as a “candidate key” within all Domains and also act as a Universal primary key for the Entity.
The reason for the different treatment of data-stores-within-a-Domain and Domains themselves has to do with the very definition of Domain. Entity Identity only
makes sense within a Domain, and the Domain imposes a uniform meaning to that Identity by virtue of the cohesiveness of the Domain, i.e., the common
characteristics of the Domain that are shared by all systems and data stores within it. While it may be possible to build associations between specific Entity
instances across two Domains, this is by no means universally applicable. E.g., Some customers may be employees, and hence some Entities in the Customer
domain may be associated with some Entities in the Staff domain, but not every Entity in these two Domains has a similar association.
These characteristics lead to the following principle:
Principle 37 (Inter-Domain Provisioning Event model): Provisioning events between Domains are more loosely coupled than provisioning events between data
stores within a single Domain in that the Entity Identifiers used are always External Identifiers.
(The SCIM protocol's provision of an “id” and an “external id” seems superfluous and even misleading, because all identifiers in messages must be external.
Internal identifiers must never be exposed in messages.)
The same 5 types of provisioning events apply as in the intra-Domain case. Instances of multi-valued attributes, no matter how deeply nested, require their own
unique identifiers. (The SCIM protocol's treatment of multi-valued attributes is clumsy for the simple reason that it does not mandate this aspect of data design as
a requirement.)
As before, all events are advisory in nature and there is no notion of “control”. A Domain is free to act in whatever way it chooses to an provisioning event. The
provisioning message must either be reliably delivered to the Domains that require to receive it, or it must be communicated in an idempotent way so it can be
retried without adverse consequences. (SCIM assumes a synchronous request-response protocol that may prove too tightly-coupled and brittle. Time will tell.)
21
Illustration
22
The Domain-private Identifier is “global” within a Domain and
provides a uniform mechanism to identify an Entity across all data
stores within the Domain.
However, there is no analogous External Identifier that is “global” to
all Domains. Domains need to agree on shared External Identifiers
on a bilateral basis, because all Domains are co-equal and there is
no global Domain.
Forcing the use of a single global External Identifier across Domains
can simplify Identifier mapping within any given Domain but
introduces rigidity in the overall system due to tight coupling between
Domains. There is a trade-off between the two aspects, and we
recommend using multiple External Identifiers as illustrated here.
Domain Y
Data Store P
Entity Instance
Attributes
Local Primary
Key “6”
Domain-private Identifier “99”
Data Store Q
Entity Instance
Attributes
Local Primary
Key “8”
External Identifier “389” External Identifier “613”Domain X
Data Store A
Entity Instance
Attributes
Local Primary
Key “1”
Domain-private Identifier “55”
Data Store B
Entity Instance
Attributes
Local Primary
Key “4”
External Identifier “389”
Domain Z
Data Store S
Entity Instance
Attributes
Local Primary
Key “9”
Domain-private Identifier “27”
Data Store T
Entity Instance
Attributes
Local Primary
Key “5”
External Identifier “613”
Authorisation / Entitlements
Principle 38 (Isolate Coarse-grained and Fine-grained Authorisation): Authorisation rules should be split into coarse-grained and fine-grained. Fine-grained
authorisation rules should be applied close to where access takes place, such as a single application or data store. Coarse-grained rules can be applied at higher
levels, such as the Domain. Standards such as XACML are seductive but misleading. Too much detail at a more coarse-grained level of control is logistically hard
to manage and does not deliver sufficient benefit to justify the cost.
Principle 39 (Roles): Roles are a mechanism to standardise access control privileges and apply them across Entities. Coarse-grained roles should be used at the
Domain level and fine-grained roles at the individual application level.
Principle 40 (Rules): Role-Based Access Control (RBAC) is useful for access to functions. It is generally not useful to control access to data (e.g., specific
subsets of data within a data store). Rules, not roles, that are applied at an individual Entity level are more suitable to control access to data items. E.g., two
personal bankers offering financial advice and other personalised services to high net worth customers may both have the same role entitlements, but rules
specific to their individual identities will control which customer's data each can see.
Principle 41 (On-behalf-of Access model): In situations requiring on-behalf-of access, the Identity of the Entity on whose behalf an activity is being performed
should be treated as an attribute of the Entity that is physically performing the activity. E.g., if a customer service representative is performing a function on behalf
of a customer, then the CSR's Identity is the one to be authenticated, and the customer's Identity merely established and verified as an authorised attribute of the
CSR. This treatment aids the audit function as well, since it primarily records who performed an action, and secondarily on whose behalf the action was
performed.
Principle 42 (Role Propagation model): When one Domain propagates the Identity of an Entity to another, it is clear that the shared External Identifier will be
used, and that is sufficient for the Establishment of Identity. However, for the receiving Domain to be able to perform authorisation effectively, it needs to be able
to determine the Roles (coarse- or fine-grained) of the Entity and the allowed Functions for those Roles. This involves some trade-offs.
If the first Domain does not pass in any Role information but only the Entity's External Identifier, it means the receiving Domain will have to maintain a mapping
between the Entity's corresponding Domain-private Identifier and a set of Roles. In other words, the Entity will have to be provisioned within the receiving Domain
as well.
If the first Domain itself determines the Entity's Role(s) and passes them to the receiving Domain, then the two Domains must pre-agree the set of Roles,
otherwise the received Role(s) may not be interpreted correctly. A system of Domain-private and External Identifiers for Roles can solve this problem, if Roles are
treated as Entities in their own right.
A third approach is for the receiving Domain to be agnostic to Entity Identity and allow function access purely on the basis of Role information passed in. This
approach may not be universally applicable because of the common requirement to maintain audit logs with Entity identity.
23
Domain 1 Domain 2Domain 1's users need to be provisioned in
Domain 2 in terms of their mapping to roles
Domain 2Domain 1 Domain 1 and Domain 2 need to agree on
common role Identifiers
Propagation of Role Identity
24
User Role Function
User-Role
Mapping
Role-Function
Mapping
User Identifier
User Role Function
User-Role
Mapping
Role-Function
Mapping
Logical Model: An Authorisation check is performed by following the mappings of User-to-Role and Role-to-(allowed) Function to determine whether an
attempted access is allowed or not.
Implementation Model 1: Domain 1 only provides the External Identifier of a User Entity. Domain 2 needs to map the corresponding Internal Identifier to a
Role and then determine the Function authorisation. For this model to work, a user provisioned into Domain 1 and requiring access to functions in
Domain 2 must also be provisioned into Domain 2, either concurrently or in a Just-In-Time manner.
Implementation Model 2: Domain 1 maintains a mapping of User identifiers to Roles, and provides the Role Identifier to Domain 2 (along with the optional
External Identifier, which is required not for authorisation but for audit purposes). Domain 2 only needs to determine the Function authorisation using this
Role Identifier. For this model to work, the two Domains must pre-agree a set of Role Identifiers.
Federation use case: A user provisioned in Domain 1 requires to access a function in Domain 2. Domain 1 establishes the user's Identity. Domain 2
needs to determine whether the user is authorised to perform the function. The translation from user Identity to function access has to cross the Domain
boundary, and it may use more than one model, as shown below.
RoleUser Function
User-Role
Mapping
Role-Function
Mapping
Role Identifier
Party
Belongs to IndividualHousehold OrganisationBelongs to Is sub-unit of
d
UUID - Globally
unique, meaning-free,
externally-invisible
identifier
Individual
attributes
Organisational
attributes
Household
attributes
Is owned by
Is used by
Product/Service
Product/Service
ID – abstract ID
decoupled from
physical
identifiers
Is managed by
Sample Identity Model for an Industry
Domain Models and the Identity of Domain Entities
Principle 46 (Identify all core Entities): Identity management is often understood to pertain to individuals, specifically “users”. However, Individuals are not the only
Entities to be considered in a generic IAM system. A more generic Entity is “Party”. Individuals and Groups (such as Households and Organisations) are sub-
types of Party.
In general, all Parties have Domain-private Identifiers and External Identifiers, but only Individuals require Credentials, because Groups do not log into
applications. Groups may however have relationships that Individuals do not have, such as when Organisations are billed for services that Individuals
(employees) use. Groups also aggregate Individual Identities into more complex structures, such as organisations with multiple levels of business units and
employees associated with each level.
A full-fledged Data Model for a business will mesh the Identity Model with other important Entities in the business Domain, and it needs to be rich enough
internally to be able to model associations such as the examples above.
Other Entities that may be of interest in a given industry Domain are Products, Services, Locations, etc. Industry Domain Models exist at various levels of
abstraction for the Banking, Insurance, Telecom and other industries. Similar data principles as enunciated in this document may hold for all these Entities, with
appropriate variations.
25
Domain 1 Domain 2
Miscellaneous Aspects of Security
Principle 47 (Appropriate use of Cryptography): Encryption of data for confidentiality is an orthogonal concern to Access Management/SSO (where it is mainly
required) and is part of those protocols. Provisioning messages are also sensitive, but here it is more important to prevent spoofing of provisioning requests than
to protect data from prying eyes. So cryptographic techniques are still required on the provisioning side, but more for authentication of event sources and
message integrity than for encryption of traffic.
Principle 48 (Non-trackability): Privacy concerns may dictate that when a domain shares an entity's external identifier with another domain, the unvarying nature
of the identifier may itself create a vulnerability that third parties can exploit to track the behaviour and other profile information that may be associated with the
entity. In such cases, it is not enough for an entity's external identifier to be meaningless. It must also keep changing at frequent intervals to prevent third parties
from tracking the entity. The following illustration illustrates one possible data scheme to implement this privacy requirement.
Principle 49 (Audit): Audit of functions is greatly facilitated once Identifiers accompany every activity. On-behalf-of transactions must be logged with the Identifier
of the logged-on user and the Identifier of the user on whose behalf the activity is being carried out. The latter is generally available as an attribute of the logged-
on user. Audit logs need to be write-once and tamper-proof. When logs across physical systems need to be reconciled, External Identifiers in the log records (in
addition to timestamps and transaction IDs) can help to establish a thread of activity.
Principle 50 (Segregation of Duties): The Segregation of Duties principle means that provision needs to be made for two roles to perform each activity, one to
request and the other to authorise. An Entity cannot authorise an activity requested by themselves. The data model presented in this paper can support this
requirement through a combination of a Rule, two Roles and individual Identities for Entities.
26
Untrackable
Identifier:
“b8d234018c4b”,
“41b472a0bef6”,
“9d30bd205534”,
etc.
Entity
Map to Ext
Identifier
Domain-private
Identifier “ABC”
External Identifier
“03736ef741d2”
Add random
“salt”
Salted Identifier:
“03736ef741d24f”,
“03736ef741d2c3”,
“03736ef741d255”, etc.
Encrypt Decrypt
Discard
“salt”
Map to Int
Identifier
Entity
External Identifier
“03736ef741d2”
Domain-private
Identifier “XYZ”
Salted Identifier:
“03736ef741d24f”,
“03736ef741d2c3”,
“03736ef741d255”, etc.
Summary and Conclusions
We said in the introduction that the most common mistake with IAM is in assuming that it is a technology problem. Given the subtlety of many of the data
principles we have just seen, and the hugely negative implications of getting these wrong, it should be clear why IAM is not so much a technology problem as a
data problem. If the emerging, modern IAM protocols did not exist, it would still be possible to “roll your own”, but if the underlying data model has serious flaws,
no amount of technology thrown at the problem will fix matters.
The data principles listed and described in this document have been arrived at through hard experience at more than one user organisation. Many of these
appear obvious in hindsight, but it is astonishing that they are mainly observed in the breach.
Let's summarise the most common industry mistakes relating to data modelling:
1. Lack of clarity on the appropriate Entities in the Domain, and the subsequent use of inappropriate surrogates
2. The use of identifiers with business meaning, creating external dependencies
3. The use of sequence numbers instead of UUIDs for identifiers, creating real-time dependencies upon a single source
4. The exposure of internal identifiers to parties outside the domain, creating external dependencies and preventing splitting/merging of Identities
5. Recycling of identifiers, which breaks more things than we can describe here
6. An assumption of “control” that spans domains, instead of a truly federated architecture, leading to needless political battles
7. Lack of understanding of MDM principles, leading to poor provisioning practices and consequent inconsistencies in replicated data
8. Lack of clarity on the Trust model, leading to conflict between the security function and the business/IT functions
9. An excessively ambitious authorisation model, with the logistical complexity of fine-grained access control overwhelming the IAM function
10. Lack of understanding of cross-Domain authorisation, leading to one-off, brittle solutions that break the overall model
It is our belief that a meticulous application of the data principles in this document can lead to more flexible and robust data models, and these in turn will enable
simple and powerful protocols for authentication, authorisation and provisioning. Together with audit, these functions form the core of what is called Identity and
Access Management (IAM).
We hope these principles will be useful not only to practitioners at end-user organisations but also to IAM protocol designers and product developers.
About the Author
Ganesh Prasad is an architect who has worked in the area of Identity and Access Management for over 5 years, covering the banking, insurance and telecom
industries. His experiences in this field, combined with general lessons learnt over a decade of architecture practice and consulting, have prompted him to
document his learnings for the benefit of other professionals. His previous writings in the area of IAM are “Identity Management on a Shoestring” (a how-to
manual on designing a loosely-coupled corporate IAM solution, published through InfoQ - http://bit.ly/ZLv3i9) and “Don't SCIM over Your Data Model” (an InfoQ
article detailing some suggestions to improve the SCIM protocol - http://bit.ly/10G8biT).
27

More Related Content

What's hot

AWS Single Sign-On (SSO) 서비스 집중 탐구 - 윤석찬 :: AWS Unboxing 온라인 세미나
AWS Single Sign-On (SSO) 서비스 집중 탐구 - 윤석찬 :: AWS Unboxing 온라인 세미나AWS Single Sign-On (SSO) 서비스 집중 탐구 - 윤석찬 :: AWS Unboxing 온라인 세미나
AWS Single Sign-On (SSO) 서비스 집중 탐구 - 윤석찬 :: AWS Unboxing 온라인 세미나Amazon Web Services Korea
 
AWS Storage - S3 Fundamentals
AWS Storage - S3 FundamentalsAWS Storage - S3 Fundamentals
AWS Storage - S3 FundamentalsPiyush Agrawal
 
Use Elastic Beanstalk Blue/Green Deployment to Reduce Downtime & Risk (DEV330...
Use Elastic Beanstalk Blue/Green Deployment to Reduce Downtime & Risk (DEV330...Use Elastic Beanstalk Blue/Green Deployment to Reduce Downtime & Risk (DEV330...
Use Elastic Beanstalk Blue/Green Deployment to Reduce Downtime & Risk (DEV330...Amazon Web Services
 
Spring Framework Petclinic sample application
Spring Framework Petclinic sample applicationSpring Framework Petclinic sample application
Spring Framework Petclinic sample applicationAntoine Rey
 
Getting Started with Serverless Architectures
Getting Started with Serverless ArchitecturesGetting Started with Serverless Architectures
Getting Started with Serverless ArchitecturesAmazon Web Services
 
AWS Global Infrastructure Foundations
AWS Global Infrastructure Foundations AWS Global Infrastructure Foundations
AWS Global Infrastructure Foundations Amazon Web Services
 
Identity and Access Management: The First Step in AWS Security
Identity and Access Management: The First Step in AWS SecurityIdentity and Access Management: The First Step in AWS Security
Identity and Access Management: The First Step in AWS SecurityAmazon Web Services
 
Intro to AWS: EC2 & Compute Services
Intro to AWS: EC2 & Compute ServicesIntro to AWS: EC2 & Compute Services
Intro to AWS: EC2 & Compute ServicesAmazon Web Services
 
Module 3: Security, Identity and Access Management - AWSome Day Online Confer...
Module 3: Security, Identity and Access Management - AWSome Day Online Confer...Module 3: Security, Identity and Access Management - AWSome Day Online Confer...
Module 3: Security, Identity and Access Management - AWSome Day Online Confer...Amazon Web Services
 
Deep Dive on Amazon Aurora MySQL Performance Tuning (DAT429-R1) - AWS re:Inve...
Deep Dive on Amazon Aurora MySQL Performance Tuning (DAT429-R1) - AWS re:Inve...Deep Dive on Amazon Aurora MySQL Performance Tuning (DAT429-R1) - AWS re:Inve...
Deep Dive on Amazon Aurora MySQL Performance Tuning (DAT429-R1) - AWS re:Inve...Amazon Web Services
 
Bastion Host : Amazon Web Services
Bastion Host : Amazon Web ServicesBastion Host : Amazon Web Services
Bastion Host : Amazon Web ServicesAkhilesh Joshi
 
How Do I Know I Need a Ledger Database? An Intro to Amazon QLDB: re:Invent 20...
How Do I Know I Need a Ledger Database? An Intro to Amazon QLDB: re:Invent 20...How Do I Know I Need a Ledger Database? An Intro to Amazon QLDB: re:Invent 20...
How Do I Know I Need a Ledger Database? An Intro to Amazon QLDB: re:Invent 20...Amazon Web Services
 
AWS Black Belt Techシリーズ Amazon Workspaces
AWS Black Belt Techシリーズ  Amazon WorkspacesAWS Black Belt Techシリーズ  Amazon Workspaces
AWS Black Belt Techシリーズ Amazon WorkspacesAmazon Web Services Japan
 
EKS를 통한 차량 공유 서비스 '타다' 서비스 구축기 - 김태호, VCNC :: AWS Summit Seoul 2019
EKS를 통한 차량 공유 서비스 '타다' 서비스 구축기 - 김태호, VCNC :: AWS Summit Seoul 2019EKS를 통한 차량 공유 서비스 '타다' 서비스 구축기 - 김태호, VCNC :: AWS Summit Seoul 2019
EKS를 통한 차량 공유 서비스 '타다' 서비스 구축기 - 김태호, VCNC :: AWS Summit Seoul 2019Amazon Web Services Korea
 
Amazon EC2 고급 활용 기법 및 모범 사례::이진욱::AWS Summit Seoul 2018
Amazon EC2 고급 활용 기법 및 모범 사례::이진욱::AWS Summit Seoul 2018Amazon EC2 고급 활용 기법 및 모범 사례::이진욱::AWS Summit Seoul 2018
Amazon EC2 고급 활용 기법 및 모범 사례::이진욱::AWS Summit Seoul 2018Amazon Web Services Korea
 
IAM 정책을 잘 알아야 AWS 보안도 쉬워진다. 이것은 꼭 알고 가자! - 신은수 솔루션즈 아키텍트, AWS :: AWS Summit S...
IAM 정책을 잘 알아야 AWS 보안도 쉬워진다. 이것은 꼭 알고 가자! - 신은수 솔루션즈 아키텍트, AWS :: AWS Summit S...IAM 정책을 잘 알아야 AWS 보안도 쉬워진다. 이것은 꼭 알고 가자! - 신은수 솔루션즈 아키텍트, AWS :: AWS Summit S...
IAM 정책을 잘 알아야 AWS 보안도 쉬워진다. 이것은 꼭 알고 가자! - 신은수 솔루션즈 아키텍트, AWS :: AWS Summit S...Amazon Web Services Korea
 
Elastic Load Balancing Deep Dive and Best Practices - NET402 - re:Invent 2017
Elastic Load Balancing Deep Dive and Best Practices - NET402 - re:Invent 2017Elastic Load Balancing Deep Dive and Best Practices - NET402 - re:Invent 2017
Elastic Load Balancing Deep Dive and Best Practices - NET402 - re:Invent 2017Amazon Web Services
 

What's hot (20)

AWS Single Sign-On (SSO) 서비스 집중 탐구 - 윤석찬 :: AWS Unboxing 온라인 세미나
AWS Single Sign-On (SSO) 서비스 집중 탐구 - 윤석찬 :: AWS Unboxing 온라인 세미나AWS Single Sign-On (SSO) 서비스 집중 탐구 - 윤석찬 :: AWS Unboxing 온라인 세미나
AWS Single Sign-On (SSO) 서비스 집중 탐구 - 윤석찬 :: AWS Unboxing 온라인 세미나
 
AWS Storage - S3 Fundamentals
AWS Storage - S3 FundamentalsAWS Storage - S3 Fundamentals
AWS Storage - S3 Fundamentals
 
Use Elastic Beanstalk Blue/Green Deployment to Reduce Downtime & Risk (DEV330...
Use Elastic Beanstalk Blue/Green Deployment to Reduce Downtime & Risk (DEV330...Use Elastic Beanstalk Blue/Green Deployment to Reduce Downtime & Risk (DEV330...
Use Elastic Beanstalk Blue/Green Deployment to Reduce Downtime & Risk (DEV330...
 
Spring Framework Petclinic sample application
Spring Framework Petclinic sample applicationSpring Framework Petclinic sample application
Spring Framework Petclinic sample application
 
Cloud Security Fundamentals Webinar
Cloud Security Fundamentals WebinarCloud Security Fundamentals Webinar
Cloud Security Fundamentals Webinar
 
Getting Started with Serverless Architectures
Getting Started with Serverless ArchitecturesGetting Started with Serverless Architectures
Getting Started with Serverless Architectures
 
AWS Global Infrastructure Foundations
AWS Global Infrastructure Foundations AWS Global Infrastructure Foundations
AWS Global Infrastructure Foundations
 
Identity and Access Management: The First Step in AWS Security
Identity and Access Management: The First Step in AWS SecurityIdentity and Access Management: The First Step in AWS Security
Identity and Access Management: The First Step in AWS Security
 
Intro to AWS: EC2 & Compute Services
Intro to AWS: EC2 & Compute ServicesIntro to AWS: EC2 & Compute Services
Intro to AWS: EC2 & Compute Services
 
Module 3: Security, Identity and Access Management - AWSome Day Online Confer...
Module 3: Security, Identity and Access Management - AWSome Day Online Confer...Module 3: Security, Identity and Access Management - AWSome Day Online Confer...
Module 3: Security, Identity and Access Management - AWSome Day Online Confer...
 
Deep Dive on Amazon Aurora MySQL Performance Tuning (DAT429-R1) - AWS re:Inve...
Deep Dive on Amazon Aurora MySQL Performance Tuning (DAT429-R1) - AWS re:Inve...Deep Dive on Amazon Aurora MySQL Performance Tuning (DAT429-R1) - AWS re:Inve...
Deep Dive on Amazon Aurora MySQL Performance Tuning (DAT429-R1) - AWS re:Inve...
 
Bastion Host : Amazon Web Services
Bastion Host : Amazon Web ServicesBastion Host : Amazon Web Services
Bastion Host : Amazon Web Services
 
AWS 101
AWS 101AWS 101
AWS 101
 
How Do I Know I Need a Ledger Database? An Intro to Amazon QLDB: re:Invent 20...
How Do I Know I Need a Ledger Database? An Intro to Amazon QLDB: re:Invent 20...How Do I Know I Need a Ledger Database? An Intro to Amazon QLDB: re:Invent 20...
How Do I Know I Need a Ledger Database? An Intro to Amazon QLDB: re:Invent 20...
 
AWS Black Belt Techシリーズ Amazon Workspaces
AWS Black Belt Techシリーズ  Amazon WorkspacesAWS Black Belt Techシリーズ  Amazon Workspaces
AWS Black Belt Techシリーズ Amazon Workspaces
 
EKS를 통한 차량 공유 서비스 '타다' 서비스 구축기 - 김태호, VCNC :: AWS Summit Seoul 2019
EKS를 통한 차량 공유 서비스 '타다' 서비스 구축기 - 김태호, VCNC :: AWS Summit Seoul 2019EKS를 통한 차량 공유 서비스 '타다' 서비스 구축기 - 김태호, VCNC :: AWS Summit Seoul 2019
EKS를 통한 차량 공유 서비스 '타다' 서비스 구축기 - 김태호, VCNC :: AWS Summit Seoul 2019
 
Amazon EC2 고급 활용 기법 및 모범 사례::이진욱::AWS Summit Seoul 2018
Amazon EC2 고급 활용 기법 및 모범 사례::이진욱::AWS Summit Seoul 2018Amazon EC2 고급 활용 기법 및 모범 사례::이진욱::AWS Summit Seoul 2018
Amazon EC2 고급 활용 기법 및 모범 사례::이진욱::AWS Summit Seoul 2018
 
IAM 정책을 잘 알아야 AWS 보안도 쉬워진다. 이것은 꼭 알고 가자! - 신은수 솔루션즈 아키텍트, AWS :: AWS Summit S...
IAM 정책을 잘 알아야 AWS 보안도 쉬워진다. 이것은 꼭 알고 가자! - 신은수 솔루션즈 아키텍트, AWS :: AWS Summit S...IAM 정책을 잘 알아야 AWS 보안도 쉬워진다. 이것은 꼭 알고 가자! - 신은수 솔루션즈 아키텍트, AWS :: AWS Summit S...
IAM 정책을 잘 알아야 AWS 보안도 쉬워진다. 이것은 꼭 알고 가자! - 신은수 솔루션즈 아키텍트, AWS :: AWS Summit S...
 
Elastic Load Balancing Deep Dive and Best Practices - NET402 - re:Invent 2017
Elastic Load Balancing Deep Dive and Best Practices - NET402 - re:Invent 2017Elastic Load Balancing Deep Dive and Best Practices - NET402 - re:Invent 2017
Elastic Load Balancing Deep Dive and Best Practices - NET402 - re:Invent 2017
 
Amazon Aurora
Amazon AuroraAmazon Aurora
Amazon Aurora
 

Similar to 50 data principles for loosely coupled identity management v1 0

Identity & Access Management - Securing Your Data in the 21st Century Enterprise
Identity & Access Management - Securing Your Data in the 21st Century EnterpriseIdentity & Access Management - Securing Your Data in the 21st Century Enterprise
Identity & Access Management - Securing Your Data in the 21st Century EnterpriseLance Peterman
 
Five Ways to Make Identity Management Work Best Across Hybrid Computing Envir...
Five Ways to Make Identity Management Work Best Across Hybrid Computing Envir...Five Ways to Make Identity Management Work Best Across Hybrid Computing Envir...
Five Ways to Make Identity Management Work Best Across Hybrid Computing Envir...Dana Gardner
 
Identity Management: A New Key Strategic Infrastructure
Identity Management: A New Key Strategic InfrastructureIdentity Management: A New Key Strategic Infrastructure
Identity Management: A New Key Strategic InfrastructureJISC Netskills
 
Jazoon'12 Enterprise-wide Cloud Governance
Jazoon'12 Enterprise-wide Cloud GovernanceJazoon'12 Enterprise-wide Cloud Governance
Jazoon'12 Enterprise-wide Cloud GovernanceNetcetera
 
ANALYSIS ON IDENTITY MANAGEMENT SYSTEMS WITH EXTENDED STATE-OF-THE-ART IDM TA...
ANALYSIS ON IDENTITY MANAGEMENT SYSTEMS WITH EXTENDED STATE-OF-THE-ART IDM TA...ANALYSIS ON IDENTITY MANAGEMENT SYSTEMS WITH EXTENDED STATE-OF-THE-ART IDM TA...
ANALYSIS ON IDENTITY MANAGEMENT SYSTEMS WITH EXTENDED STATE-OF-THE-ART IDM TA...ijasuc
 
Sap Business Objects Tableau Ibm Cognos
Sap Business Objects Tableau Ibm CognosSap Business Objects Tableau Ibm Cognos
Sap Business Objects Tableau Ibm CognosGerri Dominguez
 
InfoFusion Overview And Roadmap
InfoFusion Overview And RoadmapInfoFusion Overview And Roadmap
InfoFusion Overview And RoadmapMarten den Haring
 
Identity_Management_Vendor_Evaluation
Identity_Management_Vendor_EvaluationIdentity_Management_Vendor_Evaluation
Identity_Management_Vendor_EvaluationJerry Ruggieri
 
Storytelling Drives Usefulness in Business Intelligence
Storytelling Drives Usefulness in Business IntelligenceStorytelling Drives Usefulness in Business Intelligence
Storytelling Drives Usefulness in Business IntelligenceNeil Raden
 
CA Technologies and Deloitte: Unleash and Protect your Business with Identity...
CA Technologies and Deloitte: Unleash and Protect your Business with Identity...CA Technologies and Deloitte: Unleash and Protect your Business with Identity...
CA Technologies and Deloitte: Unleash and Protect your Business with Identity...CA Technologies
 
Intelligence Driven Identity and Access Management
Intelligence Driven Identity and Access ManagementIntelligence Driven Identity and Access Management
Intelligence Driven Identity and Access ManagementEMC
 
Why IAM is the Need of the Hour
Why IAM is the Need of the HourWhy IAM is the Need of the Hour
Why IAM is the Need of the HourTechdemocracy
 
Digital Asset Management What to know before you go.pdf
Digital Asset Management What to know before you go.pdfDigital Asset Management What to know before you go.pdf
Digital Asset Management What to know before you go.pdfHeyEmbedMe
 
An apporach to AIM - A strategy proposal and recommendation - ver 0.1
An apporach to AIM - A strategy proposal and recommendation - ver 0.1An apporach to AIM - A strategy proposal and recommendation - ver 0.1
An apporach to AIM - A strategy proposal and recommendation - ver 0.1Michael Clarkson
 
KMWorld Martin Briefing
KMWorld Martin BriefingKMWorld Martin Briefing
KMWorld Martin Briefingmartingarland
 
Emerging Trends in Knowledge Management
Emerging Trends in Knowledge ManagementEmerging Trends in Knowledge Management
Emerging Trends in Knowledge ManagementNikesh Narayanan
 
Windows Server 2008 R2 Active Directory ADFS Claims Base Identity for Windows...
Windows Server 2008 R2 Active Directory ADFS Claims Base Identity for Windows...Windows Server 2008 R2 Active Directory ADFS Claims Base Identity for Windows...
Windows Server 2008 R2 Active Directory ADFS Claims Base Identity for Windows...Tũi Wichets
 

Similar to 50 data principles for loosely coupled identity management v1 0 (20)

Identity & Access Management - Securing Your Data in the 21st Century Enterprise
Identity & Access Management - Securing Your Data in the 21st Century EnterpriseIdentity & Access Management - Securing Your Data in the 21st Century Enterprise
Identity & Access Management - Securing Your Data in the 21st Century Enterprise
 
Five Ways to Make Identity Management Work Best Across Hybrid Computing Envir...
Five Ways to Make Identity Management Work Best Across Hybrid Computing Envir...Five Ways to Make Identity Management Work Best Across Hybrid Computing Envir...
Five Ways to Make Identity Management Work Best Across Hybrid Computing Envir...
 
Identity Management: A New Key Strategic Infrastructure
Identity Management: A New Key Strategic InfrastructureIdentity Management: A New Key Strategic Infrastructure
Identity Management: A New Key Strategic Infrastructure
 
Jazoon'12 Enterprise-wide Cloud Governance
Jazoon'12 Enterprise-wide Cloud GovernanceJazoon'12 Enterprise-wide Cloud Governance
Jazoon'12 Enterprise-wide Cloud Governance
 
ANALYSIS ON IDENTITY MANAGEMENT SYSTEMS WITH EXTENDED STATE-OF-THE-ART IDM TA...
ANALYSIS ON IDENTITY MANAGEMENT SYSTEMS WITH EXTENDED STATE-OF-THE-ART IDM TA...ANALYSIS ON IDENTITY MANAGEMENT SYSTEMS WITH EXTENDED STATE-OF-THE-ART IDM TA...
ANALYSIS ON IDENTITY MANAGEMENT SYSTEMS WITH EXTENDED STATE-OF-THE-ART IDM TA...
 
Identity Management In Cloud Computing
Identity Management In Cloud ComputingIdentity Management In Cloud Computing
Identity Management In Cloud Computing
 
Esecurity e202
Esecurity e202Esecurity e202
Esecurity e202
 
Sap Business Objects Tableau Ibm Cognos
Sap Business Objects Tableau Ibm CognosSap Business Objects Tableau Ibm Cognos
Sap Business Objects Tableau Ibm Cognos
 
InfoFusion Overview And Roadmap
InfoFusion Overview And RoadmapInfoFusion Overview And Roadmap
InfoFusion Overview And Roadmap
 
Identity_Management_Vendor_Evaluation
Identity_Management_Vendor_EvaluationIdentity_Management_Vendor_Evaluation
Identity_Management_Vendor_Evaluation
 
Storytelling Drives Usefulness in Business Intelligence
Storytelling Drives Usefulness in Business IntelligenceStorytelling Drives Usefulness in Business Intelligence
Storytelling Drives Usefulness in Business Intelligence
 
IdM vs. IDaaS
IdM vs. IDaaSIdM vs. IDaaS
IdM vs. IDaaS
 
CA Technologies and Deloitte: Unleash and Protect your Business with Identity...
CA Technologies and Deloitte: Unleash and Protect your Business with Identity...CA Technologies and Deloitte: Unleash and Protect your Business with Identity...
CA Technologies and Deloitte: Unleash and Protect your Business with Identity...
 
Intelligence Driven Identity and Access Management
Intelligence Driven Identity and Access ManagementIntelligence Driven Identity and Access Management
Intelligence Driven Identity and Access Management
 
Why IAM is the Need of the Hour
Why IAM is the Need of the HourWhy IAM is the Need of the Hour
Why IAM is the Need of the Hour
 
Digital Asset Management What to know before you go.pdf
Digital Asset Management What to know before you go.pdfDigital Asset Management What to know before you go.pdf
Digital Asset Management What to know before you go.pdf
 
An apporach to AIM - A strategy proposal and recommendation - ver 0.1
An apporach to AIM - A strategy proposal and recommendation - ver 0.1An apporach to AIM - A strategy proposal and recommendation - ver 0.1
An apporach to AIM - A strategy proposal and recommendation - ver 0.1
 
KMWorld Martin Briefing
KMWorld Martin BriefingKMWorld Martin Briefing
KMWorld Martin Briefing
 
Emerging Trends in Knowledge Management
Emerging Trends in Knowledge ManagementEmerging Trends in Knowledge Management
Emerging Trends in Knowledge Management
 
Windows Server 2008 R2 Active Directory ADFS Claims Base Identity for Windows...
Windows Server 2008 R2 Active Directory ADFS Claims Base Identity for Windows...Windows Server 2008 R2 Active Directory ADFS Claims Base Identity for Windows...
Windows Server 2008 R2 Active Directory ADFS Claims Base Identity for Windows...
 

More from Ganesh Prasad

Workshop Slides - Introduction to Dependency-Oriented Thinking" Feb 15, 2014,...
Workshop Slides - Introduction to Dependency-Oriented Thinking" Feb 15, 2014,...Workshop Slides - Introduction to Dependency-Oriented Thinking" Feb 15, 2014,...
Workshop Slides - Introduction to Dependency-Oriented Thinking" Feb 15, 2014,...Ganesh Prasad
 
Dependency-Oriented Thinking Sydney Workshop Brochure and Schedule (Feb 15 2014)
Dependency-Oriented Thinking Sydney Workshop Brochure and Schedule (Feb 15 2014)Dependency-Oriented Thinking Sydney Workshop Brochure and Schedule (Feb 15 2014)
Dependency-Oriented Thinking Sydney Workshop Brochure and Schedule (Feb 15 2014)Ganesh Prasad
 
(Deprecated) Slicing the Gordian Knot of SOA Governance
(Deprecated) Slicing the Gordian Knot of SOA Governance(Deprecated) Slicing the Gordian Knot of SOA Governance
(Deprecated) Slicing the Gordian Knot of SOA GovernanceGanesh Prasad
 
Sofea in a soa ecosystem v0 4
Sofea in a soa ecosystem v0 4Sofea in a soa ecosystem v0 4
Sofea in a soa ecosystem v0 4Ganesh Prasad
 
Life above the service tier preso v1 0
Life above the service tier preso v1 0Life above the service tier preso v1 0
Life above the service tier preso v1 0Ganesh Prasad
 
Life above the_service_tier_v1.1
Life above the_service_tier_v1.1Life above the_service_tier_v1.1
Life above the_service_tier_v1.1Ganesh Prasad
 

More from Ganesh Prasad (7)

Enterprise REST
Enterprise RESTEnterprise REST
Enterprise REST
 
Workshop Slides - Introduction to Dependency-Oriented Thinking" Feb 15, 2014,...
Workshop Slides - Introduction to Dependency-Oriented Thinking" Feb 15, 2014,...Workshop Slides - Introduction to Dependency-Oriented Thinking" Feb 15, 2014,...
Workshop Slides - Introduction to Dependency-Oriented Thinking" Feb 15, 2014,...
 
Dependency-Oriented Thinking Sydney Workshop Brochure and Schedule (Feb 15 2014)
Dependency-Oriented Thinking Sydney Workshop Brochure and Schedule (Feb 15 2014)Dependency-Oriented Thinking Sydney Workshop Brochure and Schedule (Feb 15 2014)
Dependency-Oriented Thinking Sydney Workshop Brochure and Schedule (Feb 15 2014)
 
(Deprecated) Slicing the Gordian Knot of SOA Governance
(Deprecated) Slicing the Gordian Knot of SOA Governance(Deprecated) Slicing the Gordian Knot of SOA Governance
(Deprecated) Slicing the Gordian Knot of SOA Governance
 
Sofea in a soa ecosystem v0 4
Sofea in a soa ecosystem v0 4Sofea in a soa ecosystem v0 4
Sofea in a soa ecosystem v0 4
 
Life above the service tier preso v1 0
Life above the service tier preso v1 0Life above the service tier preso v1 0
Life above the service tier preso v1 0
 
Life above the_service_tier_v1.1
Life above the_service_tier_v1.1Life above the_service_tier_v1.1
Life above the_service_tier_v1.1
 

Recently uploaded

Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.francesco barbera
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureEric D. Schabell
 
RAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AIRAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AIUdaiappa Ramachandran
 
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdfJamie (Taka) Wang
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfDianaGray10
 
GenAI and AI GCC State of AI_Object Automation Inc
GenAI and AI GCC State of AI_Object Automation IncGenAI and AI GCC State of AI_Object Automation Inc
GenAI and AI GCC State of AI_Object Automation IncObject Automation
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaborationbruanjhuli
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
Babel Compiler - Transforming JavaScript for All Browsers.pptx
Babel Compiler - Transforming JavaScript for All Browsers.pptxBabel Compiler - Transforming JavaScript for All Browsers.pptx
Babel Compiler - Transforming JavaScript for All Browsers.pptxYounusS2
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1DianaGray10
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024SkyPlanner
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Websitedgelyza
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Will Schroeder
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1DianaGray10
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
Introduction to Quantum Computing
Introduction to Quantum ComputingIntroduction to Quantum Computing
Introduction to Quantum ComputingGDSC PJATK
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Adtran
 

Recently uploaded (20)

Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability Adventure
 
RAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AIRAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AI
 
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
 
GenAI and AI GCC State of AI_Object Automation Inc
GenAI and AI GCC State of AI_Object Automation IncGenAI and AI GCC State of AI_Object Automation Inc
GenAI and AI GCC State of AI_Object Automation Inc
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
Babel Compiler - Transforming JavaScript for All Browsers.pptx
Babel Compiler - Transforming JavaScript for All Browsers.pptxBabel Compiler - Transforming JavaScript for All Browsers.pptx
Babel Compiler - Transforming JavaScript for All Browsers.pptx
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Website
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
Introduction to Quantum Computing
Introduction to Quantum ComputingIntroduction to Quantum Computing
Introduction to Quantum Computing
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™
 

50 data principles for loosely coupled identity management v1 0

  • 2. “50 Data Principles for Loosely-Coupled Identity Management” Version 1.0, May 2013 © Ganesh Prasad This work is licensed under Creative Commons Attribution-No Derivs 3.0 Australia http://creativecommons.org/licenses/by-nd/3.0/au/
  • 3. Table of Contents The Importance of the Data Model for Identity Management..............................................................................................................................................................4 Domain, Entity, Identifier and Attribute................................................................................................................................................................................................ 5 Illustration...................................................................................................................................................................................................................................... 6 Identity Federation............................................................................................................................................................................................................................. 7 Identity Life-cycle............................................................................................................................................................................................................................... 8 Merging of Entity Identities............................................................................................................................................................................................................ 9 Splitting of Entity Identities........................................................................................................................................................................................................... 10 The Life-cycle of External Identifiers............................................................................................................................................................................................ 11 Identity Establishment, Degree of Trust, Credentials and Authentication..........................................................................................................................................12 Illustration.................................................................................................................................................................................................................................... 13 The Life-cycle of Credentials....................................................................................................................................................................................................... 14 Single Sign-On – A Poster Child of Access Management.................................................................................................................................................................16 Access Management – Intra-Domain (Data Stores and Data Flows)...........................................................................................................................................17 Access Management – Inter-Domain (Data Stores and Data Flows)...........................................................................................................................................18 Identity Management and Provisioning – Intra-Domain....................................................................................................................................................................19 Illustration.................................................................................................................................................................................................................................... 20 Identity Management and Provisioning - Inter-Domain.....................................................................................................................................................................21 Illustration.................................................................................................................................................................................................................................... 22 Authorisation / Entitlements.............................................................................................................................................................................................................. 23 Propagation of Role Identity........................................................................................................................................................................................................ 24 Domain Models and the Identity of Domain Entities.........................................................................................................................................................................25 Miscellaneous Aspects of Security................................................................................................................................................................................................... 26 Summary and Conclusions.............................................................................................................................................................................................................. 27 About the Author.............................................................................................................................................................................................................................. 27
  • 4. The Importance of the Data Model for Identity Management Our previous publication (“Identity Management on a Shoestring”) introduced the concept of loose coupling in the domain of Identity and Access Management (IAM) and described in detail the architecture of a lightweight, low-cost, loosely-coupled corporate IAM system. With the advent of Cloud Computing, “Identity Management in the Cloud” has become a hot topic, and many standards have emerged to deal with the challenges of IAM at Web scale. The older XML-based trio of protocols – SAML for authentication, XACML for authorisation and SPML for provisioning – have achieved only mixed success, with only SAML having gained some traction in enterprise systems. But in the new world of the cloud, more lightweight alternatives are in demand. The “OAuth2 family” of protocol standards promises to deliver what the industry is asking for. The OAuth2 protocol itself, as a means of enabling constrained delegated authorisation of access, is an excellent base technology to protect other IAM APIs (protocols), – specifically, such APIs as OpenID Connect for Authentication and SCIM for User Provisioning1 . However, the OAuth2 family of protocols is by itself only a necessary and not a sufficient enabler. A well-designed protocol requires a flexible data model underpinning it, and both need to be based on sound principles. The most common mistake made by practitioners is the assumption that Identity Management is a technology problem. Regrettably, the transition from corporate IAM to cloud-based IAM has not changed that mindset. Solutions are almost always sought in the realm of technology products and protocols, and data models are relatively neglected. IAM projects therefore generally incur significant cost, but their record of success is not very encouraging. The irony is that identity- related problems can be effectively sorted out, and at far lower cost to boot, if the focus is placed where it belongs, i.e., on data. Identity management is primarily a data problem, not a technology problem. In this document, we will talk about important data principles and end by summarising the most common industry mistakes relating to data modelling. In a separate article (“Don't SCIM over Your Data Model”), we pointed out specific examples in the SCIM (System for Cross-domain Identity Management) provisioning standard where a data model based on certain principles could greatly improve the protocol. Here, we attempt to enunciate as many data-related principles as possible to support all the major aspects of Identity and Access Management. Some of these principles may appear trivial and obvious, while others may appear counter-intuitive or unnecessary. Nevertheless, we have found these principles useful in our own practice. They are unfortunately not commonly applied, which is why Identity and Access Management is often such a bugbear. We believe IAM (and not just Cross-domain Identity Management) will become much simpler if this model is followed. 1SCIM used to stand for “Simple Cloud Identity Management” but now stands for “System for Cross-domain Identity Management”, which is more generic. 4
  • 5. Domain, Entity, Identifier and Attribute Principle 1 (All Identity is contextual): An Entity's Identity is not an absolute concept but is only meaningful within a Domain or a Universe of Discourse, i.e., within some well-defined area of interest. (“John” in a social Domain is a different Identity from “Mr. Smith” in a corporate Domain, and is different again from “dad” in a family Domain. All of them could be the same person, but trying to distil some fundamental Identity that exists outside all these Domains is generally neither feasible nor worthwhile. Domain-specific Identities are more natural to model, and it is much more practical to simply associate these Domain-specific Identities with one another when required. In other words, an Identity (for any Entity) that is independent of a Domain or that exists outside of all Domains is a chimera. Principle 2 (Uniqueness is the essence of Identity): Domains may contain many types of Entities, and within each type, there could be many individual Entities, or instances. These instances need to be distinguished from others of the same type, i.e., Entities (or more correctly, Entity instances) have unique Identity. If something does not have a unique Identity, then it is by definition not an Entity (e.g., “Value Objects” in Domain-Driven Design). Principle 3 (Identity is independent of Attributes): Entities have properties or Attributes with business meaning, and these Attributes are what make Entities “interesting” to the Domain in the first place. So it will seem counter-intuitive to assert as we do here that an Entity really has no inherent Attributes with business meaning! However, this principle aids flexibility by not imposing constraints. An analogy is the Standard Model of Particle Physics (recently validated through the confirmation of the Higgs boson's existence). A core aspect of the Standard Model is that particles do not inherently have mass. Some of them acquire mass through interaction with the Higgs field, which explains why other particles like photons have no mass. A loosely coupled model for Identity similarly decouples an Entity from all its meaningful Attributes. This is extremely useful in cases where anonymous Identity is to be tracked analogous to persistent cookies in browsers. Principle 4 (Identifiers must have no business meaning): The only inherent Attribute of an Entity is a unique and meaning-free Identifier that serves only to distinguish it from other Entities in the Domain. It is critically important that the identifier be free of all business meaning, because it will otherwise have to change when the business context changes. E.g., using a person's email address as their identifier would require changing the identifier when the user changes ISPs. A meaningless string of characters is a much better identifier, because there would be no reason to change one for another. Identities are more “stable” when Identifiers are meaningless. Principle 5 (An Entity needs at least one “private” Identifier): An Entity's inherent Identifier attribute is private to the Domain in which the Entity is known and is never visible outside the Domain. There can be additional identifiers that are made public and explicitly designated as External Identifiers (described under Federated Identity). However, revealing a private identifier to third parties creates dependencies that can prevent necessary housekeeping operations such as splitting and merging identities (as will be discussed in a later section). The existence of external (public) Identifiers does not obviate the need for a private one. Principle 6 (Attribute model): All Attributes of an Entity (including all its External Identifiers) are associated with the Entity through its Domain-private Identifier. Attributes may be simple (a name-value pair), multi-valued/repeating (a name with multiple values of the same type) or composite (a collection of dissimilar Attributes). Combinations of these are also possible, to any arbitrary level of complexity. Principle 7 (Every attribute value must have its own unique Identifier): For non-repeating Attributes, the attribute's name is itself its unique Identifier within the namespace of the Entity. This is true for simple attributes (e.g., “date-of-birth”) as well as composite attributes (e.g., “address.post-code”). Similarly, each element of a multi-valued (repeating) Attribute must also be assigned a unique, meaning-free Identifier of its own (i.e., not a mere positional index). The reason for this Identifier will become clearer when we see how it can be used to support provisioning operations. 5
  • 6. Illustration 6 Example Domain: “Asia-Pacific Region”, “Small & Medium Businesses”, “Employees”, etc. Entity: “Customer”, “Product”, “Employee”, etc. Domain-private, meaning-free Identifier: “0d72c8ca-8b97-416c-9e2e-6f1695011e9e” (a UUID) External Identifier: “0800200c9a66” (some unique string) “ad28ce96-aea2-41f0-bdfd-c926682ad37f” (another UUID) Simple Attribute: Date of Birth Repeating Attribute: Email addresses – {UUID, address string}* (Note the per-value identifier, the UUID) Composite Attribute: Full name (Title, First name, Last name) Repeating, composite attribute: Addresses – {UUID, Address type (home/business), Street number, Street name, Street type, Suburb, Post code, State, Country}* (Note the per-value identifier, the UUID) Domain X Entity Composite Attribute Domain-private Identifier Simple Attribute Attribute 2 Attribute 4 Attribute 1 Attribute 3 Attribute 5 Name Value N N N N N V V V V V V Identifier V Identifier N Repeating Attribute Identifier V N V External Identifier 1 External Identifier 2 Visible to Domain Z Visible to Domain Y
  • 7. Identity Federation Entities must often be referenced outside their Domain. Some of these references may be to associate Entity instances in two or more Domains because they refer to the same logical Entity. Principle 8 (Federated Domain model): No Domain is the “centre of the universe”. All Domains are co-equal, and no Domain can dictate any aspect of an Entity's identity within another Domain, although they may notify one another of Entity life-cycle events (i.e., creation, deletion/deactivation or a change in attributes). Domains cannot make assumptions about how other Domains will act on an Entity's life-cycle events. Principle 9 (Federated Identifier model): External Identifiers are special Attributes that also uniquely identify an Entity within a Domain (like “candidate keys” in relational database tables). When Entity instances are associated across two Domains, the Domains should share a common External Identifier for the Entity and map/associate this External Identifier to their respective Internal Identifiers. Neither Domain must see the other's Internal Identifier for the Entity. 7 Staff Member as Customer Domain: Customer Domain-private Identifier: a224dadc-bb7b-4011-97ec-c8ba1336e65f Attributes: Customer category (Platinum, Gold, Silver), etc. External Identifier: f6302ada-aece-4869-aeba-43a735f081a3 Domain: Staff Domain-private Identifier: c0e790e4-6466-43f3-8d52-253c3f75349b Attributes: Employee number, etc. External Identifier: f6302ada-aece-4869-aeba-43a735f081a3 Same person Domain A Entity X Domain-private Identifier 'x' Attribute(s) External Identifier 'q' Domain B Entity Y Domain-private Identifier 'y' Attribute(s) External Identifier 'q' External Identifier 'p' External Identifier 'r' Shared reference
  • 8. Identity Life-cycle Apart from the standard life-cycle events of creation, modification and deletion that apply to an Entity, there are events that are peculiar to its Identity. These require special rules and special processes. Principle 10 (Identifiers are forever): The life-cycle of an Entity's Identifiers (both Domain-private and External) is independent of the life-cycle of the Entity itself. Once created, an Identifier exists in perpetuity. An Entity may cease to exist, but the Identifier must not be recycled, i.e., used to refer to another Entity thereafter. Identifiers are created to be used for one Entity only, and form a useful reference to historical data even after the deletion of the Entity. (Of course, an Entity can be referred to by more than one Identifier, simultaneously as well as over the lifetime of the Entity.) There is an apparent exception to this principle. Within a Domain, it may sometimes be discovered that what were hitherto wrongly considered to be two or more Entities are actually the same (a false negative), or that what was wrongly considered a single Entity is actually more than one (a false positive). It will be necessary in such cases to merge or split Identities. When doing so, it will be necessary to change the association between External Identifiers and Domain- private Identifiers, which may seem like a violation of the above principle. However, in spirit, the Identifiers still refer to the same Entity. Only the previous model of the Entity was incorrect. With a suitable audit trail to document the merge or split, historical attributes and events can still be related back to an Entity. An important effect of having External Identifiers mapped to Domain-private Identifiers is that any splitting or merging of Entities that is necessitated by the requirement to fix errors (false negatives and false positives) within a Domain need not be exposed immediately to external Domains. It is possible for the mapping to hide these changes and have them communicated at a more convenient time, and only if necessary. Principle 11 (Merging of Identity): Merging two or more Entity Identities should be done by dropping all but one Domain-private Identifier. All the External Identifiers of the other Identities should now be associated with the sole remaining Domain-private Identifier. All the various attributes of those Identities should now be associated with this single Domain-private Identifier, merging and reconciling them as required. E.g., if two Entities referred to by the External Identifiers “J Smith” and “John Smith” are recognised to be one and the same, they must now have the same Domain-private Identifier, although the External Identifiers “J Smith” and “John Smith” may continue to exist, with both now associated with the same Domain-private Identifier. If John Smith has two valid phone numbers, and each of his previous Identities was associated with one, the merged Identity should have both. If the two earlier Identities had different addresses and only one turned out to be valid, then the discrepancy should be reconciled by dropping the invalid one and associating the remaining with the Domain-private identifier. Other Domains relying on these External Identifiers will not (and should not) be impacted by the clean-up within this Domain. Principle 12 (Splitting of Identity): Splitting Entity identities should be done by creating new Domain-private Identifiers for the Entities that have to be created out of the original one. Existing Attributes should be distributed among the new Entities by associating them with the appropriate Domain-private Identifiers. In some cases, Attributes may apply to more than one of the Entities, and will need to be duplicated. New External Identifiers may be created for the newly created Entities and exposed to other Domains if and when required. E.g., if it is discovered that an Entity with an External Identifier of “John Smith” actually refers to two different people, then only one of them should be allowed to carry this Identity going forward. The other should be given a new Identity (a new Domain-private Identifier) and can be gradually introduced to other Domains through a new External Identifier, (say) “John G Smith”. If the original Entity had a “Date of Birth” attribute with the value “1 Jan 1970”, and this was found to be valid for both the Entities after the split, then the attribute should be duplicated and applied to both through association with their respective Domain-private Identifiers. 8
  • 9. Merging of Entity Identities 9 Entities X and Y are discovered to be the same (a “false negative”). The two Entity identities should be merged. Domain A Entity X Domain-private Identifier 'x' Attributes of X Entity Y Domain-private Identifier 'y' Attributes of Y External Identifier 'p' External Identifier 'r' Visible to Domain B Visible to Domain B Domain A Entity X Domain-private Identifier 'x' Merged attributes of Entities X and Y Entity Y Domain-private Identifier 'y' External Identifier 'p' External Identifier 'r' No longer exists No longer referenced and never recycled (i.e., never used for another Entity) Visible to Domain B Visible to Domain B (No change detected) Domain B can be notified of the merge at a convenient later time, or not at all.
  • 10. Splitting of Entity Identities 10 “Entity X” is discovered to be representing two Entities (a “false positive”). The Entity identity should be split. Domain A Entity X Domain-private Identifier 'x' Attributes of X External Identifier 'p' Visible to Domain B Domain A Entity X Domain-private Identifier 'x' Attributes rightfully belonging to X Entity Y Domain-private Identifier 'y' External Identifier 'p' New External Identifier 'r' Visible to Domain B Made visible to Domain B when required Domain B can be notified of the split at a convenient later time, or not at all. In some cases, Domain B may need to be notified immediately. Attributes from X that rightfully belong to Y
  • 11. The Life-cycle of External Identifiers Managing the life-cycle of Domain-private Identifiers is relatively easy, as we have shown, because there are few (if any) external dependencies on them. However, the same cannot be said about External Identifiers, which by definition, are visible externally and therefore have external dependencies. Example: Two independent, legacy applications with their own user stores need to be gradually decommissioned in favour of a new, integrated application. In other words, two legacy Domains are to be merged into a third one. (The legacy Domains may continue operating in parallel for a while, provisioning new users using independent legacy logic even as they are being migrated.) The treatment of Domain-private Identifiers is relatively straightforward as described in the previous section. If UUIDs are used in the legacy Domains, it may even be possible to migrate them unchanged without conflict since UUIDs share a universal namespace to start with. However, conflict is possible between External Identifiers because two namespaces are being collapsed into one. Hence specific strategies are required to manage these conflicts. Principle 13 (Maintain visibility of changes to External Identifiers): External parties that have built a dependency on External Identifiers in legacy Domains must understand that a migration is taking place and that a change in their Identifiers may be required. Setting expectations is key, because a seamless migration (i.e., no change to any External Identifier) is not realistic. Principle 14 (Determine a conflict resolution protocol): In the interest of least disruption, a protocol to resolve conflicts should be agreed before migration (e.g., “first come, first served” or “Domain 1 over Domain 2”). Only one claimant to an External Identifier that migrates to the new, merged namespace can be granted the right to use the Identifier. Other claimants will be required to choose another Identifier. The converse is not true. When false negatives are detected and merged into a single Entity, it can still retain all its External Identifiers. Principle 15 (Handle false conflicts): Although it is possible that External Identifiers from two or more legacy Domains will conflict in the merged namespace of the new Domain, this may simply be because they refer to the same logical Entity. This is a special case of a false negative, and will need to be detected as part of the migration process along with other false negatives. Their Domain-private Identifiers and attributes will need to be merged, of course, but their common External Identifier can be preserved without change because it relates to the same logical Entity. 11 Legacy Domain A Entity X Domain-private Identifier 'x' External Identifier 'p' Migration New Domain Q Legacy Domain B Entity Y Domain-private Identifier 'y' External Identifier 'p' Entity X Domain-private Identifier 'x' External Identifier 'p' Entity Y Domain-private Identifier 'y' External Identifier 'p' Migration Use the 'split' technique in case of conflict This conflict is harder to reconcile
  • 12. Identity Establishment, Degree of Trust, Credentials and Authentication Principle 20 (Identity Establishment): Identity Establishment is a more general concept than Authentication. Identity Establishment within a Domain is simply the determination of an Entity's Domain-private Identifier through any means. Identity Establishment is the pre-requisite for most meaningful business functions involving the Entity, since all Attributes are associated with the Domain-private Identifier. Principle 21 (Trust model): The nature of the means through which an Entity's Identity is established determines the Degree of Trust associated with the Identity. A mere reference to an Entity's Domain-private Identifier is sufficient to establish the Identity of the Entity that is being discussed, but the Degree of Trust in the accuracy of that reference could vary based on how it came about. Principle 22 (Authentication): If a “sufficiently high” Degree of Trust is achieved in the establishment of an Entity's identity, “Authentication” can be said to have taken place. In other words, the assertion or claim that an Entity's identity is such-and-such is accepted. How high the Degree of Trust needs to be in order to be considered “sufficient” varies with the Domain, hence Authentication is a more fuzzy concept than Identity Establishment. In practice, Authentication occurs either (1) when the Entity itself presents one of its External Identifiers along with one or more matching (security) tokens that other Entities are unlikely to possess or have knowledge of, or (2) when an External Identifier for the Entity is propagated from another (trusted) Domain in a tamper-proof way. In either case, the Domain-private Identifier for the Entity can then be determined with a high Degree of Trust through its association with the External Identifier that is presented. Authentication implies Identity Establishment but not the other way around. Principle 23 (The Degree of Trust is not static): The Degree of Trust can depend on a variety of factors, such as the strength of the security tokens presented to validate an Identifier, the channel through which the access takes place, the time elapsed since the Identity was established, etc. The strength of the security tokens is important since some sensitive functions may require stronger tokens to be presented when they are accessed. The channel is important because the Identities of users from a trusted network or using a trusted device are established with a higher Degree of Trust than those from untrusted networks or devices. (Of course, a conservative model is to treat all networks and devices as untrusted.) The time elapsed is important since the Degree of Trust can “decay” with time, requiring periodic renewal. This latter aspect clearly distinguishes Identity Establishment from Authentication, since the Identity continues to be valid, but a degradation in the Degree of Trust may require re-Authentication. Principle 24 (Credentials): The combination of an Identifier and a security token is referred to as a set of Credentials. A security token may be associated with a specific External Identifier or with the Domain-private Identifier for the Entity. The latter association can provide greater flexibility in certain cases, such as when allowing a customer to identify themselves in a variety of ways but requiring them to remember only one password. Principle 25 (Identity Establishment and Authentication can occur in any sequence): Identity Establishment and Authentication can occur in different domains and in any arbitrary sequence. The Degree of Trust in each domain can also vary accordingly. If Authentication is done in one Domain and the Identity is propagated securely to another Domain, then Identity Establishment occurs after Authentication. The Degree of Trust could be high in both Domains. If one Domain merely propagates an Identity to another, and the second Domain establishes the Identity and then performs Authentication, then the order is reversed. The Degree of Trust may only be high in the second Domain. 12
  • 13. Illustration (1) The Domain receives a set of Credentials in the form of an Entity's External Identifier 'p' and a Security Token that is associated with that specific Identifier. If the token matches the value stored, then the Entity is deemed authenticated and its Identity is established to be the Domain-private Identifier 'x', with a high Degree of Trust. (2) and (3) The Domain receives a set of Credentials in the form of an Entity's External Identifier ('r' or 's') and a Security Token that is associated with the Entity's Domain-private Identifier 'x'. If the token matches the value stored, then the Entity is deemed authenticated and its Identity is established to the be Domain- private Identifier 'x', with a high Degree of Trust. What distinguishes the latter two cases from (1) is that all External Identifiers share a single Security Token, which makes security easier to manage, both for the Domain and for the Entity. E.g., a customer may present either a user name or a primary email address as their External Identifier, but only have to remember a single password. Changes to passwords then also apply uniformly to all Identifiers. (4) The Domain receives an Entity's External Identifier 'q' from a trusted external Domain in a way that is guaranteed against tampering. Although no associated Security Token is received, the tamper-proof assertion of the External Identifier is itself considered a Security Token. There is a high Degree of Trust in the association of the External Identifier 'q' to the Domain-private Identifier 'x', and the Entity is taken to be Authenticated. (5) The Domain receives an Entity's External Identifier 't' through a less trusted mechanism. The Entity's Identity can be established to be Domain-private Identifier 'x', but the Degree of Trust associated with this Identity is lower. It may be sufficient for certain purposes but not for others. Establishing a user's Identity by validating a weak surrogate such as their mobile number falls under this category. 13 Trusted Domain Entity Domain-private Identifier 'y' “My” Domain Entity Domain-private Identifier 'x' External Identifier 'p' External Identifier 'r' Identifier-specific Security Token External Identifier 's' Domain-wide Security Token for Entity Entity-Scoped Credentials Entity-Scoped Credentials Identifier- Scoped Credentials External Identifier 'q' External Identifier 'q' External Identifier 't' 1 2 3 4 5
  • 14. The Life-cycle of Credentials The life-cycle of Credentials is related to that of External Identifiers. Domains that merge often have to merge Credentials as well, and this presents further problems. Principle 16 (Credentials are for the Entity, not the Identifier): In legacy Domains with a relatively simplistic Identity model, Credentials are usually associated directly with External Identifiers, and there is no separate internal Identifier. In the new Domain, Credentials should be associated with the Domain-private Identifier rather than with any External Identifier (See following section on Authentication). This can also prove friendlier to users when Domains are merged, because they can still use any of the External Identifiers they are used to, but only have to remember a single password, for example. Principle 17 (Limit the number of Credentials per Domain): A Domain should standardise upon one set of Credentials of the appropriate strength and discard all others. External parties with a dependency on these Credentials need to be notified of the consolidation and allowed to select the one they want to retain. In rare cases, more than one set of Credentials may need to be stored, such as to enforce “step-up” Authentication when accessing more sensitive functions. Ideally, Credentials must be stored in only one place, without duplication. Sometimes, due to legacy dependencies, it may not be possible to consolidate the storage of Credentials. In that case, their values should be harmonised across physical stores using MDM principles. Principle 18 (Employ Master Data Management to keep redundant Credentials consistent): Updates to credentials should follow MDM principles (Also discussed under Provisioning). One store should be designated the “source of truth”, i.e., the only one updated by business logic. All others should be treated as read-only replicas and robustly refreshed from the source of truth, either in real-time or using an eventual consistency model. 14
  • 15. Principle 19 (Robustness): (Caution: This principle trades off security for user-friendliness.) The principle of robustness in communications is to “be conservative in what you produce and liberal in what you consume”. In similar fashion, IAM should be conservative while provisioning (i.e., provisions to ALL stores using MDM) and liberal while authenticating (accepts validation against ANY store). How robustness is ensured: When a user changes their password on the source of truth, the expected replication to secondary stores may fail. Normally, this would pose a problem if there are applications that authenticate against these secondary stores. However, Authentication will still succeed because all stores are checked and a successful validation against any one of them is taken as successful authentication, hence replication failures will not impact users and the system as a whole is robust. However, note that this approach also successfully authenticates the previous password. If the password had had to be changed because it was compromised, then this is clearly a security loophole. Hence this approach must be used with caution. 15 Credential Store 1 Credential Store 2 1. Initial Provisioning 2a. Change of password 2b. Replication (may fail) 3a. Authentication with new password (Step 1 - fails) 3b. Authentication with new password (Step 2 - succeeds)
  • 16. Single Sign-On – A Poster Child of Access Management Principle 26 (Single Sign-On): Single Sign-On (SSO) is defined in different ways, but the most general one is that a user attempting to access a related group of systems (i.e., an SSO environment) is challenged for their credentials only once per “session”, whatever those credentials may be and however that session may be defined (See Single Sign-Out below). There could be multiple sets of credentials that could be used, but only one set is required for a given session. There could be multiple initial entry points into the SSO environment, and a different one could be used in each session, and each such entry point may require a different set of credentials, but once the challenge has been successfully met, no further challenge is made for the rest of the session. Hence this is the definition that covers all use cases including federation. Principle 27 (SSO Token model): The data model to support SSO is largely independent of the core Identity model and consists of a set of tokens. There is a single token for SSO itself, which ensures that a second challenge does not occur within the same session. There is a second set of tokens that are each specific to one particular application or resource that is being accessed. Authentication is sufficient to grant the SSO token, but Authorisation rules are consulted for each application or resource for which access is being attempted, and only successful authorisation will result in the grant of the application/resource access token. Both tokens are required before a user can access an application or resource in an SSO environment. Principle 28 (SSO and Identifiers): When SSO covers a single Domain, the Domain-private Identifier for an Entity can be freely exchanged inside tokens passed between systems as part of the SSO protocol. When SSO covers multiple Domains (“federated SSO”), appropriate mapping to External Identifiers must be performed and only External Identifiers may be communicated between Domains as part of the SSO protocol (e.g., within SAML tokens). Once Authentication completes, Identity is established, i.e., the Domain-private Identifier is known to the SSO system. Either this or a suitable External Identifier associated with it should be populated within the appropriate tokens and passed to participating (trusted) systems, depending on whether they are within the Domain or in external Domains. Principle 29 (SSO and Coarse-grained Authorisation): The SSO system should only perform coarse-grained authorisation checks (explained in detail later). Coarse-grained Role Identifiers may be populated within application access tokens passed to applications in addition to the user's Identifier (Domain-private or External). The application itself should perform fine-grained authorisation checks using its knowledge of the user's Identifier. This keeps the SSO system manageable in terms of logistical complexity, especially as the number of protected applications increases, because each application will have its own specialised roles and access rules. SSO has a number of side-effects, some of which may be seen as undesirable. If an application that is sensitive from a security viewpoint shares an SSO environment with other applications that are not sensitive, then there is a potential risk, because it is not possible to “log out” of the sensitive application if any of the other applications is being used. The SSO session is deemed to be active, and it will be possible to acquire unchallenged access to the sensitive application at any time, since a second challenge is never issued during an SSO session. Principle 30 (Ending SSO Sessions): As far as possible, sensitive and less sensitive applications should not be combined within the same SSO environment. Extra protection such as decay in the Degree of Trust requiring fresh authentication may be employed. This bends the definition of SSO a little by requiring a fresh challenge during a session but provides greater security for sensitive apps. An alternative is “Single Sign-Out”, under which logging out of a sensitive application ends the SSO session altogether and requires fresh authentication before access is granted again to any system. It may be argued that Single Sign- Out defeats the purpose of Single Sign-On. 16
  • 17. Access Management – Intra-Domain (Data Stores and Data Flows) 17 Domain Application A Application B Authentication Data Store Coarse-grained Authorisation Data Store SSO Server ID mapping Data Store Client Application (Browser) Fine-grained Authorisation Data Store A Fine-grained Authorisation Data Store B Token Data Store User Attribute Data Store Logical IAM Data Stores Temporary store for SSO Token and Application Access Tokens Credentials: External ID + Security Token(s) OR Domain-private ID + Security Token(s) - Domain-private ID to External ID(s) - Domain-private ID to Coarse-grained Roles - Roles to Application Access - Domain-private ID to other Entity Attributes - Domain-private ID to Fine-grained Roles - Roles to Function Access - Domain-private ID to Data Access (Rules) Credentials: ID + Security Token(s) SSO Token + Application Access Token(s) Application Access Token A + Domain-private ID + Coarse-grained Roles + User attributes Application Access Token B + Domain-private ID + Coarse-grained Roles + User attributes Authentication Coarse-grained Authorisation User attribute retrieval Fine-grained Authorisation Fine-grained Authorisation Store / Retrieve
  • 18. Access Management – Inter-Domain (Data Stores and Data Flows) 18 Domain YDomain X Application A Client Application (Browser) Application P SSO Server X IAM Data Store X Credentials Tokens Application Access Token A (includes Domain-private Identifier as attribute) Application Access Token P (includes External Identifier as attribute) (Because of the focus on data, not all flows of the federated SSO protocol are shown)
  • 19. Identity Management and Provisioning – Intra-Domain Data pertaining to an Entity may be distributed across multiple physical data stores in a geographically dispersed way within a logical Domain. Each physical data store may use a different identifier (unique within that data store alone) to refer to the Entity. Entity attributes may also be replicated (redundantly stored) across multiple data stores. More than one system may be responsible for creation of new Entity instances, for updating Entity attributes or for marking the deletion/deactivation of Entity instances. Principle 31 (Harmonise entity data into a single logical record): The Domain-private Identifier is a “candidate key” in every data store (although it will not replace the existing primary keys in any of them). It should be used to associate Entity data across multiple physical data stores within the Domain to effectively create a single logical Entity record. Physical consolidation of Entity data into a single data store is neither necessary nor (in general) cost-effective. Principle 32 (Advantages of the UUID format): Adopting the UUID format for the Domain-private Identifier allows multiple systems to independently create Entity instances if required. There is negligible danger of Identity conflict, since the probability of two random UUIDs having the same value is extremely low (about 1 in 10^33). It is meaning-free, which is a major advantage in avoiding external dependencies. It allows different Domains to implement IAM at different speeds and yet interoperate or even merge when required. It also enables the adoption of an “eventual consistency” model for Entity Identity through the gradual merging of false positives, which is a more pragmatic approach than an aspiration for 100% consistency at any instant in time. Principle 33 (Intra-Domain Provisioning Event model): Provisioning events are of 5 major types: (1) Entity creation, (2) Entity deletion/deactivation, (3) Entity update (add new attribute), (4) Entity update (update attribute value) and (5) Entity update (delete attribute). In cases (4) and (5), if the attribute is multi-valued, then the specific instance of the value to be updated or deleted needs to be identified with its own unique identifier (UUID). In case (3), if the attribute is multi- valued, the provisioning request must receive a response with the unique identifier (say, a UUID) of the newly-created value. Case (4) could include arbitrary nesting of operations on nested attributes. It is of course the implementation's responsibility to handle this arbitrarily complex logic, but the data construct to support such nested operations is quite simple, i.e., a unique identifier for each value of a multi-valued attribute at any level in the hierarchy. Principle 34 (Attribute Identifier model): Ideally, each value of a multi-valued attribute must have an Internal Identifier and one or more External Identifiers that are loosely associated through mapping. This improves flexibility but unlike with Entities (where splitting and merging of Identities is a constant possibility), the use cases may not always justify the added complexity of having more than one Identifier per attribute. This is completely optional and dependent upon the use cases that are anticipated. Principle 35 (Employ Master Data Management for provisioning): Adopting Master Data Management (MDM) principles allows Entity data to be kept consistent within the Domain in spite of replication. Specifically, every attribute must have a designated source of truth, and all other instances of that data must be deemed to be read-only replicas. Only the source of truth can be updated by business logic. Replicas must only be refreshed from the source of truth. All Entity life-cycle events must be propagated from the appropriate source of truth, and all data stores holding replicas must listen on these events and update the replicas. This is a federated model, and the unique Domain-private Identifier reference is the required logical link across all data stores. Principle 36 (Reliability of Provisioning): A reliable event delivery mechanism is required to implement this model of MDM. Specifically, messages must be persistent (they must not be lost even if there is a system failure somewhere) and subscriptions must be durable (messages must be ultimately delivered even if a subscriber was temporarily off-line). Alternatively, an idempotence model of reliability may be used. Both models assume eventual consistency. 19
  • 20. Illustration 20 Domain Data Store A Entity Instance Attributes (sources of truth) Local Primary Key Domain-private Identifier (Candidate Key) Attributes (replicas) Data Store B Entity Instance Attributes (sources of truth) Local Primary Key Domain-private Identifier (Candidate Key) Attributes (replicas) Data Store C Entity Instance Attributes (sources of truth) Local Primary Key Domain-private Identifier (Candidate Key) Attributes (replicas) Entity Lifecycle Events (referenced by Domain-private Identifier) Source of truth changed Replica updated Source of truth changed Replica updated Replica updated Source of truth changed
  • 21. Identity Management and Provisioning - Inter-Domain Inter-Domain, or Cross-Domain provisioning is very topical because of the rapid adoption of cloud-based solutions to many problems. The SCIM protocol has been proposed to standardise provisioning operations between Enterprise Customers and Cloud Providers. Cross-Domain Identity Management and provisioning are similar to their counterparts within a Domain, with two important exceptions: 1. Domain-private Identifiers are never exposed outside the Domain, as mentioned earlier. Special External Identifiers are shared by two or more Domains to refer to the same instance of an Entity, and they each map these External Identifiers to independent Domain-private Identifiers internally within their respective Domains. 2. Within a Domain, there are multiple data stores that may hold Entity data, each with its own internal primary key for the Entity. The Domain-private Identifier acts as a candidate key in all the data stores within a Domain and is the logical “primary key” for the Entity within the Domain. This analogy does not hold between Domains. There is no “super-Domain” that performs a similar role that a Domain performs for the data stores within it. Hence there is no “super-Identifer” that can act as a “candidate key” within all Domains and also act as a Universal primary key for the Entity. The reason for the different treatment of data-stores-within-a-Domain and Domains themselves has to do with the very definition of Domain. Entity Identity only makes sense within a Domain, and the Domain imposes a uniform meaning to that Identity by virtue of the cohesiveness of the Domain, i.e., the common characteristics of the Domain that are shared by all systems and data stores within it. While it may be possible to build associations between specific Entity instances across two Domains, this is by no means universally applicable. E.g., Some customers may be employees, and hence some Entities in the Customer domain may be associated with some Entities in the Staff domain, but not every Entity in these two Domains has a similar association. These characteristics lead to the following principle: Principle 37 (Inter-Domain Provisioning Event model): Provisioning events between Domains are more loosely coupled than provisioning events between data stores within a single Domain in that the Entity Identifiers used are always External Identifiers. (The SCIM protocol's provision of an “id” and an “external id” seems superfluous and even misleading, because all identifiers in messages must be external. Internal identifiers must never be exposed in messages.) The same 5 types of provisioning events apply as in the intra-Domain case. Instances of multi-valued attributes, no matter how deeply nested, require their own unique identifiers. (The SCIM protocol's treatment of multi-valued attributes is clumsy for the simple reason that it does not mandate this aspect of data design as a requirement.) As before, all events are advisory in nature and there is no notion of “control”. A Domain is free to act in whatever way it chooses to an provisioning event. The provisioning message must either be reliably delivered to the Domains that require to receive it, or it must be communicated in an idempotent way so it can be retried without adverse consequences. (SCIM assumes a synchronous request-response protocol that may prove too tightly-coupled and brittle. Time will tell.) 21
  • 22. Illustration 22 The Domain-private Identifier is “global” within a Domain and provides a uniform mechanism to identify an Entity across all data stores within the Domain. However, there is no analogous External Identifier that is “global” to all Domains. Domains need to agree on shared External Identifiers on a bilateral basis, because all Domains are co-equal and there is no global Domain. Forcing the use of a single global External Identifier across Domains can simplify Identifier mapping within any given Domain but introduces rigidity in the overall system due to tight coupling between Domains. There is a trade-off between the two aspects, and we recommend using multiple External Identifiers as illustrated here. Domain Y Data Store P Entity Instance Attributes Local Primary Key “6” Domain-private Identifier “99” Data Store Q Entity Instance Attributes Local Primary Key “8” External Identifier “389” External Identifier “613”Domain X Data Store A Entity Instance Attributes Local Primary Key “1” Domain-private Identifier “55” Data Store B Entity Instance Attributes Local Primary Key “4” External Identifier “389” Domain Z Data Store S Entity Instance Attributes Local Primary Key “9” Domain-private Identifier “27” Data Store T Entity Instance Attributes Local Primary Key “5” External Identifier “613”
  • 23. Authorisation / Entitlements Principle 38 (Isolate Coarse-grained and Fine-grained Authorisation): Authorisation rules should be split into coarse-grained and fine-grained. Fine-grained authorisation rules should be applied close to where access takes place, such as a single application or data store. Coarse-grained rules can be applied at higher levels, such as the Domain. Standards such as XACML are seductive but misleading. Too much detail at a more coarse-grained level of control is logistically hard to manage and does not deliver sufficient benefit to justify the cost. Principle 39 (Roles): Roles are a mechanism to standardise access control privileges and apply them across Entities. Coarse-grained roles should be used at the Domain level and fine-grained roles at the individual application level. Principle 40 (Rules): Role-Based Access Control (RBAC) is useful for access to functions. It is generally not useful to control access to data (e.g., specific subsets of data within a data store). Rules, not roles, that are applied at an individual Entity level are more suitable to control access to data items. E.g., two personal bankers offering financial advice and other personalised services to high net worth customers may both have the same role entitlements, but rules specific to their individual identities will control which customer's data each can see. Principle 41 (On-behalf-of Access model): In situations requiring on-behalf-of access, the Identity of the Entity on whose behalf an activity is being performed should be treated as an attribute of the Entity that is physically performing the activity. E.g., if a customer service representative is performing a function on behalf of a customer, then the CSR's Identity is the one to be authenticated, and the customer's Identity merely established and verified as an authorised attribute of the CSR. This treatment aids the audit function as well, since it primarily records who performed an action, and secondarily on whose behalf the action was performed. Principle 42 (Role Propagation model): When one Domain propagates the Identity of an Entity to another, it is clear that the shared External Identifier will be used, and that is sufficient for the Establishment of Identity. However, for the receiving Domain to be able to perform authorisation effectively, it needs to be able to determine the Roles (coarse- or fine-grained) of the Entity and the allowed Functions for those Roles. This involves some trade-offs. If the first Domain does not pass in any Role information but only the Entity's External Identifier, it means the receiving Domain will have to maintain a mapping between the Entity's corresponding Domain-private Identifier and a set of Roles. In other words, the Entity will have to be provisioned within the receiving Domain as well. If the first Domain itself determines the Entity's Role(s) and passes them to the receiving Domain, then the two Domains must pre-agree the set of Roles, otherwise the received Role(s) may not be interpreted correctly. A system of Domain-private and External Identifiers for Roles can solve this problem, if Roles are treated as Entities in their own right. A third approach is for the receiving Domain to be agnostic to Entity Identity and allow function access purely on the basis of Role information passed in. This approach may not be universally applicable because of the common requirement to maintain audit logs with Entity identity. 23
  • 24. Domain 1 Domain 2Domain 1's users need to be provisioned in Domain 2 in terms of their mapping to roles Domain 2Domain 1 Domain 1 and Domain 2 need to agree on common role Identifiers Propagation of Role Identity 24 User Role Function User-Role Mapping Role-Function Mapping User Identifier User Role Function User-Role Mapping Role-Function Mapping Logical Model: An Authorisation check is performed by following the mappings of User-to-Role and Role-to-(allowed) Function to determine whether an attempted access is allowed or not. Implementation Model 1: Domain 1 only provides the External Identifier of a User Entity. Domain 2 needs to map the corresponding Internal Identifier to a Role and then determine the Function authorisation. For this model to work, a user provisioned into Domain 1 and requiring access to functions in Domain 2 must also be provisioned into Domain 2, either concurrently or in a Just-In-Time manner. Implementation Model 2: Domain 1 maintains a mapping of User identifiers to Roles, and provides the Role Identifier to Domain 2 (along with the optional External Identifier, which is required not for authorisation but for audit purposes). Domain 2 only needs to determine the Function authorisation using this Role Identifier. For this model to work, the two Domains must pre-agree a set of Role Identifiers. Federation use case: A user provisioned in Domain 1 requires to access a function in Domain 2. Domain 1 establishes the user's Identity. Domain 2 needs to determine whether the user is authorised to perform the function. The translation from user Identity to function access has to cross the Domain boundary, and it may use more than one model, as shown below. RoleUser Function User-Role Mapping Role-Function Mapping Role Identifier
  • 25. Party Belongs to IndividualHousehold OrganisationBelongs to Is sub-unit of d UUID - Globally unique, meaning-free, externally-invisible identifier Individual attributes Organisational attributes Household attributes Is owned by Is used by Product/Service Product/Service ID – abstract ID decoupled from physical identifiers Is managed by Sample Identity Model for an Industry Domain Models and the Identity of Domain Entities Principle 46 (Identify all core Entities): Identity management is often understood to pertain to individuals, specifically “users”. However, Individuals are not the only Entities to be considered in a generic IAM system. A more generic Entity is “Party”. Individuals and Groups (such as Households and Organisations) are sub- types of Party. In general, all Parties have Domain-private Identifiers and External Identifiers, but only Individuals require Credentials, because Groups do not log into applications. Groups may however have relationships that Individuals do not have, such as when Organisations are billed for services that Individuals (employees) use. Groups also aggregate Individual Identities into more complex structures, such as organisations with multiple levels of business units and employees associated with each level. A full-fledged Data Model for a business will mesh the Identity Model with other important Entities in the business Domain, and it needs to be rich enough internally to be able to model associations such as the examples above. Other Entities that may be of interest in a given industry Domain are Products, Services, Locations, etc. Industry Domain Models exist at various levels of abstraction for the Banking, Insurance, Telecom and other industries. Similar data principles as enunciated in this document may hold for all these Entities, with appropriate variations. 25
  • 26. Domain 1 Domain 2 Miscellaneous Aspects of Security Principle 47 (Appropriate use of Cryptography): Encryption of data for confidentiality is an orthogonal concern to Access Management/SSO (where it is mainly required) and is part of those protocols. Provisioning messages are also sensitive, but here it is more important to prevent spoofing of provisioning requests than to protect data from prying eyes. So cryptographic techniques are still required on the provisioning side, but more for authentication of event sources and message integrity than for encryption of traffic. Principle 48 (Non-trackability): Privacy concerns may dictate that when a domain shares an entity's external identifier with another domain, the unvarying nature of the identifier may itself create a vulnerability that third parties can exploit to track the behaviour and other profile information that may be associated with the entity. In such cases, it is not enough for an entity's external identifier to be meaningless. It must also keep changing at frequent intervals to prevent third parties from tracking the entity. The following illustration illustrates one possible data scheme to implement this privacy requirement. Principle 49 (Audit): Audit of functions is greatly facilitated once Identifiers accompany every activity. On-behalf-of transactions must be logged with the Identifier of the logged-on user and the Identifier of the user on whose behalf the activity is being carried out. The latter is generally available as an attribute of the logged- on user. Audit logs need to be write-once and tamper-proof. When logs across physical systems need to be reconciled, External Identifiers in the log records (in addition to timestamps and transaction IDs) can help to establish a thread of activity. Principle 50 (Segregation of Duties): The Segregation of Duties principle means that provision needs to be made for two roles to perform each activity, one to request and the other to authorise. An Entity cannot authorise an activity requested by themselves. The data model presented in this paper can support this requirement through a combination of a Rule, two Roles and individual Identities for Entities. 26 Untrackable Identifier: “b8d234018c4b”, “41b472a0bef6”, “9d30bd205534”, etc. Entity Map to Ext Identifier Domain-private Identifier “ABC” External Identifier “03736ef741d2” Add random “salt” Salted Identifier: “03736ef741d24f”, “03736ef741d2c3”, “03736ef741d255”, etc. Encrypt Decrypt Discard “salt” Map to Int Identifier Entity External Identifier “03736ef741d2” Domain-private Identifier “XYZ” Salted Identifier: “03736ef741d24f”, “03736ef741d2c3”, “03736ef741d255”, etc.
  • 27. Summary and Conclusions We said in the introduction that the most common mistake with IAM is in assuming that it is a technology problem. Given the subtlety of many of the data principles we have just seen, and the hugely negative implications of getting these wrong, it should be clear why IAM is not so much a technology problem as a data problem. If the emerging, modern IAM protocols did not exist, it would still be possible to “roll your own”, but if the underlying data model has serious flaws, no amount of technology thrown at the problem will fix matters. The data principles listed and described in this document have been arrived at through hard experience at more than one user organisation. Many of these appear obvious in hindsight, but it is astonishing that they are mainly observed in the breach. Let's summarise the most common industry mistakes relating to data modelling: 1. Lack of clarity on the appropriate Entities in the Domain, and the subsequent use of inappropriate surrogates 2. The use of identifiers with business meaning, creating external dependencies 3. The use of sequence numbers instead of UUIDs for identifiers, creating real-time dependencies upon a single source 4. The exposure of internal identifiers to parties outside the domain, creating external dependencies and preventing splitting/merging of Identities 5. Recycling of identifiers, which breaks more things than we can describe here 6. An assumption of “control” that spans domains, instead of a truly federated architecture, leading to needless political battles 7. Lack of understanding of MDM principles, leading to poor provisioning practices and consequent inconsistencies in replicated data 8. Lack of clarity on the Trust model, leading to conflict between the security function and the business/IT functions 9. An excessively ambitious authorisation model, with the logistical complexity of fine-grained access control overwhelming the IAM function 10. Lack of understanding of cross-Domain authorisation, leading to one-off, brittle solutions that break the overall model It is our belief that a meticulous application of the data principles in this document can lead to more flexible and robust data models, and these in turn will enable simple and powerful protocols for authentication, authorisation and provisioning. Together with audit, these functions form the core of what is called Identity and Access Management (IAM). We hope these principles will be useful not only to practitioners at end-user organisations but also to IAM protocol designers and product developers. About the Author Ganesh Prasad is an architect who has worked in the area of Identity and Access Management for over 5 years, covering the banking, insurance and telecom industries. His experiences in this field, combined with general lessons learnt over a decade of architecture practice and consulting, have prompted him to document his learnings for the benefit of other professionals. His previous writings in the area of IAM are “Identity Management on a Shoestring” (a how-to manual on designing a loosely-coupled corporate IAM solution, published through InfoQ - http://bit.ly/ZLv3i9) and “Don't SCIM over Your Data Model” (an InfoQ article detailing some suggestions to improve the SCIM protocol - http://bit.ly/10G8biT). 27