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":[email protected],"type":"work"} ]
}
JSON Returned
{ "userName":"bjensen", "name”: { "familyName":"Jensen", "givenName":"Barbara” }, "userType":"basicUser", "emails": [ {"value":"[email protected]","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