IDENTITY SOUFFLE CREATING A WELL-BAKED IDENTITY LIFECYCLE

Pamela Dingle @pamelarosiedee Office of the CTO, Ping Identity

•  Heckler Policy •  Platitudes •  Meal Plan •  Pantry Management (data at

rest) •  Shopping – (data movement) •  Kitchen Techniques (handling

data)

Agenda

This track is about breadth not depth

What does it mean to Manage Identities

•  Before you can chop •  Before you can bake •  Before you can serve

•  You need to know what you’re trying to make

•  You have to have the right ingredients in your pantry

Preparation is the key – Identity is State

“I” comes before “A” in IAM 1.  Create and maintain an

accurate picture of the people, policies, and resources in your Enterprise

2.  Leverage that state to protect and enable

Identity like Cooking is GIGO (garbage in, garbage out)

•  You can have the best security in the world – But it won’t help you if

decisions are based on outdated identity information

Review the Meal Plan Attribution: Daniel Headrick, GE

Pantry Management : Identity Lifecycle •  Accurate, timely knowledge of who and what constitutes your

Enterprise –  Every system needs the right set of data in its reach

•  Accounts •  Resources •  Policies

–  Data must change everywhere when it is changed at the authoritative source

•  You know you’re doing it wrong when –  Your SOX audit finds dead people in application databases –  It takes 5 days for a new hire to get access to applications –  A fired employee can walk to Starbucks and download critical

business info from cloud applications –  An employee has to chase a 100 application admins to change

their name

The Units of User Identity Lifecycle

•  Account –  A relationship between a user and a

system •  Identifier

–  Unique keys or “handles” for accounts •  Username •  GUID

•  Attribute –  Distinct piece of information

•  Often a name/value pair •  Values can be complex •  Aka: Claim •  Eg:

–  Name: Pamela

• Where does data originate? • Where should it change? • What systems should also

change when authoritative systems change?

•  Note this only shows data replication, not the tools that do the detecting or moving

•  Principle: SSOT or DRY

Track Data Relationship

Start by looking at Data at Rest SOR HR System

Authoritative for: Account Status name

department employee#

Repo: Active DirectoryAuthoritative for: Identifier

email groups

password

SOR: Social NetworksAuthoritative for: Login Credential

nickname

Repo: MySQLAuthoritative for: Identifier

roles enrollment date

Internal Apps

Internal APIs

Attribute Provider: Billing System

Authoritative for: current plan $$ spent

plan expiry CC number

Sales Rep

Cloud Apps

Identifiers

•  Identifiers have a scope –  Not every identifier is globally unique –  Not every identifier has to be human readable –  Identifiers can co-exist

•  Advice: standardize one “login id” –  Best usability for users –  Federation systems help here

•  Can map user-known id to system-known id –  Maps may need to be maintained

Accounts

•  Presence/Status of Account is a preliminary access gate •  When access is needed, pressure to create account is high

–  When access is discarded, no such pressure exists •  Many [cloud] apps refuse to delete accounts

–  Only disable them –  Discrepancies can cause havoc –  Advice: create an identifier recycling plan

•  Hire John Smith (jsmith) & propagate accounts •  Fire John Smith and hire Jane smith (jsmith)

Attributes

•  User attributes –  Have an authoritative source

•  Can be self-asserted –  Source is the identity owner

•  Can be “verified” –  Source is authoritative and accountable

–  Some attributes are perishable •  Name infrequently changes •  Roles frequently change •  Birthdate never changes •  Credit rating should be fetched every time

•  Advice: standardize attribute name and format where possible across systems (eg: date)

Pantry Staple: Directories

•  Directories are specialized account and attribute repositories –  Meant to be used by multiple

applications –  Highly fault tolerant and

distributed –  Designed to be hierarchically

accessible via a standard protocol: LDAP

So you think you know how to Stock the Pantry.

•  What’s next?

Provisioning!

•  Process of getting the right information to the right systems at the right time – CRUD: create, replace, update,

delete based on events

•  Advice: automation reduces risk

Provisioning

•  Pushing accounts and attributes shouldn’t be hard –  But it is. Many application vendors figure an admin console is

good enough. •  Common options:

–  Batch (CSV/LDIF) –  Backend database manipulation (not possible for cloud) –  Provisioning API –  SCIM –  JIT Provisioning

Base elements of a provisioning architecture

•  Process –  HR adds a new user via admin console –  Manager requests a promotion for an

employee –  Customer updates their self-service profile

•  Trigger •  Attribute or account change detected in AD •  Help Desk ticket triggers API call to a service •  Business logic executes on data save •  Admin gets an email

•  Fulfillment –  Database row inserted –  SCIM call made

Provisioning Map

•  Process, Trigger, and Fulfillment may all be managed by different people

•  A single process often causes multiple triggers and fulfillments

SOR HR SystemAuthoritative for: Account Status

name department employee#

Repo: Active DirectoryAuthoritative for: Identifier

email groups

password

SOR: Social NetworksAuthoritative for: Login Credential

nickname

Repo: MySQLAuthoritative for: Identifier

roles enrollment date

Internal Apps

Internal APIs

Attribute Provider: Billing System

Authoritative for: current plan $$ spent

plan expiry CC number

Sales Rep

Cloud Apps

P: Admin App InterfaceT: New DB EntryF: LDAP insert T: New AD Entry

F: DB insertT: New AD EntryF: DB insert

T: New AD EntryF: SCIM create

P: Self ServiceT: API CAllF: DB Delete

T: DB deleteF: SCIM delete

T: DB deleteF: DB delete

T: DB updateF: API call

T: DB deleteF: DB delete

Repo: OracleAuthoritative for: Scopes

Access Tokens T: DB delete

F: API Call token wipe

T: DB deleteF: API Call token wipe

T: DB deleteF: DB delete

Provisioning Solutions

•  Provisioning world is a mess –  Old school provisioning about bypassing

the app –  No pressure was ever put on vendors

•  Provisioning to the cloud cannot happen without cooperation by cloud application vendors –  Many have no provisioning API –  Others have proprietary provisioning

APIs •  Which means provisioning efforts are

unique snowflakes –  Best hope for the future is SCIM

SCIM

•  System for Cross-Domain Identity •  It’s just a User Management REST API

–  That works the same way everywhere •  Ingredients:

– Users REST endpoint (minimum) –  Basic Auth creds

•  or better yet, an OAuth access token –  Create, delete, modify users on somebody else’s platform

HTTP Create to User Endpoint

{ "schemas": [ "urn:scim:schemas:core:1.0” ], "externalId":"bjensen”, "userName":"bjensen", "name”: { "familyName":"Jensen", "givenName":"Barbara” }, "emails": [ {"value":bjensen@babs.com,"type":"work"} ]

}

JSON Returned

{ "userName":"bjensen", "name”: { "familyName":"Jensen", "givenName":"Barbara” }, "userType":"basicUser", "emails": [ {"value":"bjensen@babs.com","type":"work"} ], "meta": { "lastModified":"2014-06-23T22:56:07.263Z", "created":"2014-06-23T22:56:07.263Z", "location":https://gold.pinglabs.net:9031/pf-scim/v1/Users/29166 }, "id":"29166", "schemas":["urn:scim:schemas:core:1.0"]

}

Just in Time Provisioning

•  Just in Time Provisioning is extremely useful for customer systems – System of Record is the Federation Server – User created in application database the second a

SAML assertion arrives from an authoritative source – Note: JIT provisioning often doesn’t handle de-prov

Provisioning Architecture SOR HR System

Authoritative for: Account Status name

department employee#

Repo: Active DirectoryAuthoritative for: Identifier

email groups

password

SOR: Social NetworksAuthoritative for: Login Credential

nickname

Repo: MySQLAuthoritative for: Identifier

roles enrollment date

Internal Apps

Internal APIs

Attribute Provider: Billing System

Authoritative for: current plan $$ spent

plan expiry CC number

Sales Rep

Cloud Apps

F: DB insertF: DB insert

T: New AD Entry

P: Self ServiceT: API CAllF: DB Delete

T: DB deleteF: SCIM delete

F: DB delete

T: DB deleteF: DB delete

Repo: OracleAuthoritative for: Scopes

Access Tokens T: DB delete

F: API Call token wipe

F: API Call token wipe

F: DB delete

ProvisioningSystem

F: SCIM create

F: API call

T: DB delete

P: Admin App InterfaceT: New DB Entry

F: LDAP insert

Data Ownership & Provenance

•  Other issues you need to think of – Who owns the data?

•  Is consent needed to use or move the data?

–  Jurisdiction •  Where was the data inputted and where can it legally go?

– Governance •  Can you prove that the system worked the way you mapped it •  SOX Attestation

Identities in the Cloud

•  How do you redraw your map when your users live in the cloud? – Architecture becomes fully API & federation driven –  IDaaS creates a “cloud platform” for user identities

•  Processes are either part of the IDaaS Service or integrated via API

–  The business must start to see itself as a service provider

Thanks!

@pamelarosiedee http://pingidentity.com

http://eternallyoptimistic.com