50 data principles for loosely coupled identity management v1 0

27

Post on 22-Oct-2014

3.151 views

Category:

Technology


2 download

DESCRIPTION

In the field of Identity and Access Management (IAM), Data is more important than Technology. A poorly designed data model can cause an IAM initiative to fail even with massive investments in technology products. Yet Data usually receives only superficial treatment, and many practitioners seem unaware of the basic principles to follow when designing Identity-based systems. This presentation is a succinct summarisation of 50 data-related principles that an organisation overlooks at its peril.

TRANSCRIPT

Page 1: 50 data principles for loosely coupled identity management v1 0
Page 2: 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/

Page 3: 50 data principles for loosely coupled identity management v1 0

Table of ContentsThe Importance of the Data Model for Identity Management.............................................................................................................................................................. 4Domain, Entity, Identifier and Attribute................................................................................................................................................................................................ 5

Illustration...................................................................................................................................................................................................................................... 6Identity Federation............................................................................................................................................................................................................................. 7Identity Life-cycle............................................................................................................................................................................................................................... 8

Merging of Entity Identities............................................................................................................................................................................................................ 9Splitting of Entity Identities........................................................................................................................................................................................................... 10The Life-cycle of External Identifiers............................................................................................................................................................................................ 11

Identity Establishment, Degree of Trust, Credentials and Authentication.......................................................................................................................................... 12Illustration.................................................................................................................................................................................................................................... 13The Life-cycle of Credentials....................................................................................................................................................................................................... 14

Single Sign-On – A Poster Child of Access Management................................................................................................................................................................. 16Access Management – Intra-Domain (Data Stores and Data Flows)........................................................................................................................................... 17Access Management – Inter-Domain (Data Stores and Data Flows)........................................................................................................................................... 18

Identity Management and Provisioning – Intra-Domain.................................................................................................................................................................... 19Illustration.................................................................................................................................................................................................................................... 20

Identity Management and Provisioning - Inter-Domain..................................................................................................................................................................... 21Illustration.................................................................................................................................................................................................................................... 22

Authorisation / Entitlements.............................................................................................................................................................................................................. 23Propagation of Role Identity........................................................................................................................................................................................................ 24

Domain Models and the Identity of Domain Entities......................................................................................................................................................................... 25Miscellaneous Aspects of Security................................................................................................................................................................................................... 26Summary and Conclusions.............................................................................................................................................................................................................. 27About the Author.............................................................................................................................................................................................................................. 27

Page 4: 50 data principles for loosely coupled identity management v1 0

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

Page 5: 50 data principles for loosely coupled identity management v1 0

Domain, Entity, Identifier and AttributePrinciple 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

Page 6: 50 data principles for loosely coupled identity management v1 0

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-privateIdentifier

SimpleAttribute

Attribute 2 Attribute 4

Attribute 1Attribute 3 Attribute 5

Name Value

N

N

N

N

N

V

V

V

V

V

V

Identifier

V

Identifier

N

RepeatingAttribute

Identifier

V

N

V

ExternalIdentifier 1

ExternalIdentifier 2

Visible to Domain Z

Visible to Domain Y

Page 7: 50 data principles for loosely coupled identity management v1 0

Identity FederationEntities 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-privateIdentifier 'x'

Attribute(s)

ExternalIdentifier 'q'

Domain B

Entity Y

Domain-privateIdentifier 'y'

Attribute(s)

ExternalIdentifier 'q'

ExternalIdentifier 'p'

ExternalIdentifier 'r'

Sharedreference

Page 8: 50 data principles for loosely coupled identity management v1 0

Identity Life-cycleApart 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

Page 9: 50 data principles for loosely coupled identity management v1 0

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-privateIdentifier 'x'

Attributesof X

Entity Y

Domain-privateIdentifier 'y'

Attributesof Y

ExternalIdentifier 'p'

ExternalIdentifier 'r'

Visible to Domain B Visible to Domain B

Domain A

Entity X

Domain-privateIdentifier 'x'

Mergedattributesof Entities

X and Y

Entity Y

Domain-privateIdentifier 'y'

ExternalIdentifier 'p'

ExternalIdentifier 'r'

No longer exists

No longer referenced andnever recycled (i.e., neverused for another Entity)

Visible to Domain BVisible to Domain B

(No change detected)Domain B can be notified of the merge at a convenient later time, or not at all.

Page 10: 50 data principles for loosely coupled identity management v1 0

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-privateIdentifier 'x'

Attributesof X

ExternalIdentifier 'p'

Visible to Domain B

Domain A

Entity X

Domain-privateIdentifier 'x'

Attributesrightfullybelonging

to X

Entity Y

Domain-privateIdentifier 'y'

ExternalIdentifier 'p'

New ExternalIdentifier '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.

Attributesfrom X that rightfully

belong to Y

Page 11: 50 data principles for loosely coupled identity management v1 0

The Life-cycle of External IdentifiersManaging 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-privateIdentifier 'x'

ExternalIdentifier 'p'

Migration

New Domain Q Legacy Domain B

Entity Y

Domain-privateIdentifier 'y'

ExternalIdentifier 'p'

Entity X

Domain-privateIdentifier 'x'

ExternalIdentifier 'p'

Entity Y

Domain-privateIdentifier 'y'

ExternalIdentifier 'p'

Migration

Usethe 'split' technique in case of

conflict

This conflict isharder to reconcile

Page 12: 50 data principles for loosely coupled identity management v1 0

Identity Establishment, Degree of Trust, Credentials and AuthenticationPrinciple 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

Page 13: 50 data principles for loosely coupled identity management v1 0

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-privateIdentifier 'y'

“My” Domain

Entity

Domain-privateIdentifier 'x'

ExternalIdentifier 'p'

ExternalIdentifier 'r'

Identifier-specificSecurity Token

ExternalIdentifier 's'

Domain-wideSecurity Token

for Entity

Entity-ScopedCredentials

Entity-Scoped Credentials

Identifier-Scoped

Credentials

ExternalIdentifier 'q'

ExternalIdentifier 'q'

ExternalIdentifier 't'

1

2

3

4

5

Page 14: 50 data principles for loosely coupled identity management v1 0

The Life-cycle of CredentialsThe 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

Page 15: 50 data principles for loosely coupled identity management v1 0

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)

Page 16: 50 data principles for loosely coupled identity management v1 0

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

Page 17: 50 data principles for loosely coupled identity management v1 0

Access Management – Intra-Domain (Data Stores and Data Flows)

17

Domain

Application A Application B

AuthenticationData Store

Coarse-grainedAuthorisation

Data Store

SSO Server

ID mappingData Store

Client Application(Browser)

Fine-grainedAuthorisationData Store A

Fine-grainedAuthorisationData Store B

TokenData Store

User AttributeData Store

Logical IAM Data Stores

Temporary store forSSO Token and

Application Access Tokens Credentials:External ID + Security Token(s) ORDomain-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

Page 18: 50 data principles for loosely coupled identity management v1 0

Access Management – Inter-Domain (Data Stores and Data Flows)

18

Domain YDomain X

Application A

Client Application(Browser)

Application P

SSO Server X

IAMData 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)

Page 19: 50 data principles for loosely coupled identity management v1 0

Identity Management and Provisioning – Intra-DomainData 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

Page 20: 50 data principles for loosely coupled identity management v1 0

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

Page 21: 50 data principles for loosely coupled identity management v1 0

Identity Management and Provisioning - Inter-DomainInter-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

Page 22: 50 data principles for loosely coupled identity management v1 0

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”

Page 23: 50 data principles for loosely coupled identity management v1 0

Authorisation / EntitlementsPrinciple 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

Page 24: 50 data principles for loosely coupled identity management v1 0

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 FunctionUser-RoleMapping

Role-FunctionMapping

User Identifier

User Role FunctionUser-RoleMapping

Role-FunctionMapping

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 FunctionUser-RoleMapping

Role-FunctionMapping

Role Identifier

Page 25: 50 data principles for loosely coupled identity management v1 0

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 byProduct/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

Page 26: 50 data principles for loosely coupled identity management v1 0

Domain 1 Domain 2

Miscellaneous Aspects of Security

Principle 4 7 ( Appropriate use of Cryptograph y ) : 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.

EntityMap to ExtIdentifier

Domain-private Identifier “ABC”

External Identifier “03736ef741d2”

Add random“salt”

Salted Identifier: “03736ef741d24f”,“03736ef741d2c3”,“03736ef741d255”, etc.

Encrypt DecryptDiscard“salt”

Map to IntIdentifier

Entity

External Identifier “03736ef741d2”

Domain-private Identifier “XYZ”

Salted Identifier: “03736ef741d24f”,“03736ef741d2c3”,“03736ef741d255”, etc.

Page 27: 50 data principles for loosely coupled identity management v1 0

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 surrogates2. The use of identifiers with business meaning, creating external dependencies3. The use of sequence numbers instead of UUIDs for identifiers, creating real-time dependencies upon a single source4. The exposure of internal identifiers to parties outside the domain, creating external dependencies and preventing splitting/merging of Identities5. Recycling of identifiers, which breaks more things than we can describe here6. An assumption of “control” that spans domains, instead of a truly federated architecture, leading to needless political battles7. Lack of understanding of MDM principles, leading to poor provisioning practices and consequent inconsistencies in replicated data8. Lack of clarity on the Trust model, leading to conflict between the security function and the business/IT functions9. An excessively ambitious authorisation model, with the logistical complexity of fine-grained access control overwhelming the IAM function10. 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