getting cloud identity right
TRANSCRIPT
© 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
© Global Identity Foundation, 2014
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
© Global Identity Foundation, 2014
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
© Global Identity Foundation, 2014
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
© Global Identity Foundation, 2014
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
© Global Identity Foundation, 2014
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
© Global Identity Foundation, 2014
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
© Global Identity Foundation, 2014
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
© Global Identity Foundation, 2014
Problems (Identity)
trust (trst) n.
Firm reliance on the
integrity, ability, or character
of a person or thing.
© Global Identity Foundation, 2014
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?
© Global Identity Foundation, 2014
Identity – More than just people
People
OrganizationsAgents
Devices
Identity needs to encompass all entities that
need to identify themselves
Code
© Global Identity Foundation, 2014
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
© Global Identity Foundation, 2014
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
© Global Identity Foundation, 2014
So what must we do differently in Cloud?
Domain 12
introduces the
concept of
"entitlement"
© Global Identity Foundation, 2014
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
© Global Identity Foundation, 2014
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
© Global Identity Foundation, 2014
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.
© Global Identity Foundation, 2014
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
© Global Identity Foundation, 2014
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
© Global Identity Foundation, 2014
NASA – Entitlement (ABAC)
Credit: Identity, Credential, and Access Management at NASA, from Zachman to Attributes ; Irwin & Taylor (NASA)
© Global Identity Foundation, 2014
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)
© Global Identity Foundation, 2014
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!
© Global Identity Foundation, 2014
Related Reading
Freely available or linked at: www.globalidentityfoundation.org
Jericho ForumIdentity Commandments
CSA Guidelines 3.0(Domain 12)
Global Identity – “Challenges
Pitfalls & Solution”
© Global Identity Foundation, 2014
www.globalidentityfoundation.org
►Privacy & Primacy
►Global Solution
►Open Standard
►Open Implementation
►Universally Implemented
Join us on“Global Identity Foundation”
© Global Identity Foundation, 2014
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?
© Global Identity Foundation, 2014
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
© Global Identity Foundation, 2014
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.
© Global Identity Foundation, 2014
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!
© Global Identity Foundation, 2014
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