Getting Cloud Identity Right

© Global Identity Foundation, 2014

Getting Cloud Identity Right(or why Domain 12 says what is does)

Paul Simmonds

www.linkedin.com/in/psimmonds

twitter: @simmonds_paul

www.globalidentityfoundation.org

[email protected]


Credentials

• Co-founder of the Jericho Forum

• Co-editor of CSA ‘Guidance’ Version 3

• Responsable for:

– Domain 1: Cloud Computing Architectural Framework

– Domain 6: Interoperability & Portability

– Domain 10: Application Security

– Domain 11: Encryption and Key Management

– Domain 12: Identity, Entitlement, and Access Management

• Led the team that re-wrote Domain 12


Agenda – Cloud Identity

• The problems with identity

• The “Locus of Control “ problem

• What we do today

• Current problems with

identity

• Designing for the future

• Examples


Trust / Control Conundrum

I trust it because I control it

I can’t control you, therefore

I don’t trust your

information

I trust it because I

manage it’s lifecycle

I don’t know how you

manage your lifecycle

I trust it because I

verify to my standards

I don’t trust your proofing

standards

So everything

needs to be in my

identity system


Jericho Forum® Commandment #8

Authentication, authorisation

and accountability must

interoperate / exchange outside

of your locus / area of control

– People/systems must be able

to manage permissions of

resources and rights of users

they don't control

– Multiple loci (areas) of control

must be supported

Identity, Management and Federation

April 2006


Why is Locus-of-Control such an

issue for identity?


Jericho Forum® Cloud Cube Model

Proprietary Open

Ext

ern

al

Inte

rna

l

Perimeterised

De-perimeterised

Loca

tio

n

Architecture

De-perimeterised

Open

External

Outsourced

Ownership - technology/services/code

Dimension Four:

Insourced /

Outsourced


Cloud is the opposite

• It’s deperimeterised

• It’s outside your identity system

• It needs its own access management system

• You have little or no control over it


Solving the conundrum

• SAML, OAUTH & SCIM

• Just provision all identities

• Federate identities

• Buy into someone else's

IDM system - Google /

Facebook / Microsoft

• Currently what we do is adapt

(kluge) our LoC into the cloud


Problems (Identity)

trust (trst) n.

Firm reliance on the

integrity, ability, or character

of a person or thing.


Problems (Identity & Trust)

• Binary assertion: of user authenticationCan I trust how this was arrived at?

• Identity validation:Do I trust 14 char passwords more than 8 char passwords more than 2-factor authentication?

• Federation: A trusts B and B trusts C Does A trust C?

• Context & Risk:I may trust you to place a £10 bet, but not to invest my entire pension?


Identity – More than just people

People

OrganizationsAgents

Devices

Identity needs to encompass all entities that

need to identify themselves

Code


What is wrong with Identity 1.0?

• Identity defined once by IT, divorced from business requirements

• Only identifies a person (entity that knows the pass code)

• No context information about all the entities in the transaction

• No relationship information about the entities in the transaction

• No understanding of risk, especially in a business context

• Most “user” information (if used) is not authoritative

Active

Directory

AAA Server

or

SecurID Server

Application or

File Server

being Accessed

Maybe

Person

Is

Person


What is wrong with Identity 2.0?

• Identity defined once, divorced from business requirements

• Needs a federated relationship

• Horribly complex (thus few do it)

• Assertions are not risk based

• Little understanding of risk, especially in a business context

• Most “user” information (if used) is not authoritative

Active

Directory

AAA Server

or

SecurID Server

Application or

File Server

being Accessed

Maybe

Person

Is

Person

SAML

OAuth

SCIM


So what must we do differently in Cloud?

Domain 12

introduces the

concept of

"entitlement"


The Holy Grail - Entitlement

Making a risk-based decision

�

About access to data and/or systems

�

Based on the trusted identity and attributes

�

Of all the entities and components in the transaction chain


Identity Source #1Identity Source #1

Identity Source #2Identity Source #2

Attribute Source #1Attribute Source #1

Attribute Source #3Attribute Source #3

Access ManagementAccess Management

Netw

ork

Access

Netw

ork

Access

Syste

m A

ccess

Syste

m A

ccess

Applic

atio

n A

ccess

Applic

atio

n A

ccess

Pro

cess A

ccess

Pro

cess A

ccess

Data

Access

Data

Access

AuthorizationAuthorization

Entitlement RulesEntitlement Rules

Entitlement ProcessEntitlement Process

Identity Source #1

Identity Source #2

Attribute Source #1

Attribute Source #3

Access Management

Netw

ork

Access

Syste

m A

ccess

Applic

atio

n A

ccess

Pro

cess A

ccess

Data

Access

Authorization

Entitlement Rules

Entitlement Process

Source: Cloud Security Alliance: Guidance v3.0

Entitlement


HR Example - The old state


HR Example - The cloud state


Source: Cloud Security Alliance: Guidance v3.0


Three key risk principles

Risk

1. Decisions around identity are taken by the entitya that is assuming the riskb; with full visibility of the identity and attributes of all the entities in the transaction chain.

2. Attributes of an Identity will be signed by the authoritative source for those attributes.

3. Identity will work off-line as well as on-line; with a lack of on-line verification simply another factor in the risk equation.

a. The five entity types are: People, Devices, Organizations, Code and Agents. (definition source: the Jericho Forum)

b. Remembering that risk will probably be bi-directional and both entities in a transaction will share the risk, though usually disproportionally.


Current Legacy “IAM” Vicious Cycle

My Access Control System only links to my Identity system

Thus all people requiring access must be in my

Identity system

Thus all my systems must

talk to my Access

Management system

I have a single “IAM” System


Legacy Identity to Cloud Identity

Identity

Management

Access

Management

RBAC

Identity

Management

Access

Management

Entitlement

Identity

Management

Identity

Management

Organisation #1

Organisation #2

Organisation #3

Cloud ServiceLegacy Perimeterised Organisation


NASA – Entitlement (ABAC)

Credit: Identity, Credential, and Access Management at NASA, from Zachman to Attributes ; Irwin & Taylor (NASA)


Browser Information

Have we seen it before?

Cookies?

Browser?

(Public) IP Address?

Geo-location

System Fonts? (fingerprint)

App. Information

Registered app.

Cookies?

(Public) IP Address?

Geo-location

Authentication

Chip & PIN?

Password?

SMS to phone?

Account Analytics

Transaction frequency?

Transaction amount?

Regular transaction?

Time of day?

From location(s)?

Transaction Risk

Internal or External Transfer?

Transfer to risky countries?

Allow with extra verification?

Threat Feed?

Current Fraud Feed (Interbank)

Entitlement

Matrix

On-Line Banking – Entitlement (Generic)


The Challenges (Near Future)

• Internet of Things

• (Need for) Authoritative sources of attributes

• Better trust required in the global ecosystem

• Cars, Phones, Houses, Work; all utilising identity & personas

• Agents, (Human and AI) with access to our lives

• BYOiD (improved usability & security)

• Access to government e-Services (inc. Voting)

• Urgent need to extendidentity to all entities

• Need to make betterbusiness-led, risk-baseddecisions!


Related Reading

Freely available or linked at: www.globalidentityfoundation.org

Jericho ForumIdentity Commandments

CSA Guidelines 3.0(Domain 12)

Global Identity – “Challenges

Pitfalls & Solution”


www.globalidentityfoundation.org

►Privacy & Primacy

►Global Solution

►Open Standard

►Open Implementation

►Universally Implemented

Join us on“Global Identity Foundation”


BACKUP SLIDES


Six Conundrums of Global Identity

Bring

Your

Own

IdentityAssertion of attributes

from authoritative sources

Are the attributes of the

entity asserted from their

authoritative source, thus

minimising / eliminating

the liability problem?

Persona Based

Identity

Is identity based on

personas, housed in

multiple locations of my

choice, ensuring my

attributes cannot easily

be aggregated?

Extensible to anywhere

that needs identity

Are devices, form-factors

and communications

extensible to work

with anything and

anywhere?

Global BYOiD

Will the US accept

Chinese iD and

vice versa?

Immutable linking

to the device

Does the third-party

know, with a defined

level of certainty /trust,

who (or which entity) is

making the assertion(s)?

1 2

4

3

5 6

Privacy

enhancing

Can I control where

my personas are held?


We have all the key blocks

We need the right people to;

• Sanity check this assertions

• Refine the business models

• Define the model to build

think we


Identity 3.0 Principles

Privacy

4. Every entity shall need only one identity which is unique and private unto the entity; there will be no body issuing or recording identities.

5. The Identity eco-system will be privacy enhancing; attributes will be minimised, asserting only such information that is relevant to the transaction.

6. Entities will only maintain attributes for which they are the authoritative source.

7. The identity of one entity to another will be cryptographically unique; negating the need for usernames or passwords and minimising attribute aggregation.

8. The biometrics (or other authentication method) of an entity will remain within the sole control of the entity; biometric information will not be used, exchanged or stored outside of the entities sole control.


Identity 3.0 Principles

Functionality

9. The digital representation and function of an entity type will be indistinguishable from another entity type, and will be interchangeable in operation.

10. The Identity ecosystem will operate without the need for identity brokers, CA of last resort or other centralised infrastructure.

11. Identity will be simply expandable to encompass the security of data; E-mail (for example) can be encrypted simply by having an entities e-mail attributes shared with them.

12. Identity shall be (as much as possible) invisible to the end user; identity and attribute verification and exchange should be a background operation until such time that increased levels of user verification is required.

13.Everyone plays their part – no more!


Identity 3.0 Operating Model (Personas)


The power of “Identity Joins”

•The join of two (or more) Identities gives context!

•Context enables understanding

•Understanding enables risk evaluation

●

•Persona’s are cryptographically unique, which;

•Allows protection of data linked to a persona

•Allows protection of data linked to a context

•Allows protection of data with an understood risk

Documents

Getting Cloud Identity Right