Pam Dingle, Ping Identity An “in-the-kitchen” walk through the process of painstakingly concocting the services and workflows that ensure that every identity is put into the oven and pulled out of the oven at exactly the right time, never too early or too late, every time.

2. IDENTITY SOUFFLE
CREATING A WELL-BAKED IDENTITY LIFECYCLE
Pamela Dingle
@pamelarosiedee
Office of the CTO, Ping Identity

3. • Heckler Policy
• Platitudes
• Meal Plan
• Pantry Management (data at
rest)
• Shopping – (data movement)
• Kitchen Techniques (handling
data)
Agenda

4. This track is about breadth not depth

5. 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

6. 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

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

8. Review the Meal Plan Attribution: Daniel Headrick, G

9. 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

10. 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

11. • 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 Directory
Authoritative for: Identifier
email
groups
password
SOR: Social Networks
Authoritative for: Login Credential
nickname
Repo: MySQL
Authoritative 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

12. 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

13. 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)

14. 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)

15. 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

16. So you think you know how to Stock the Pantry.
• What’s next?

18. 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

19. 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

20. 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

21. Provisioning Map
• Process,Trigger,
and Fulfillment
may all be
managed by
different people
• A single process
often causes
multiple triggers
and fulfillments
SOR HR System
Authoritative for: Account Status
name
department
employee#
Repo: Active Directory
Authoritative for: Identifier
email
groups
password
SOR: Social Networks
Authoritative for: Login Credential
nickname
Repo: MySQL
Authoritative 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 Interface
T: New DB Entry
F: LDAP insert T: New AD Entry
F: DB insert
T: New AD Entry
F: DB insert
T: New AD Entry
F: SCIM create
P: Self Service
T:API CAll
F: DB Delete
T: DB delete
F: SCIM delete
T: DB delete
F: DB delete
T: DB update
F:API call
T: DB delete
F: DB delete
Repo: Oracle
Authoritative for: Scopes
Access Tokens
T: DB delete
F:API Call token wipe
T: DB delete
F:API Call token wipe
T: DB delete
F: DB delete

22. 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

23. 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

24. 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"}
]
}

25. 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"]
}

26. 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

27. Provisioning Architecture
SOR HR System
Authoritative for: Account Status
name
department
employee#
Repo: Active Directory
Authoritative for: Identifier
email
groups
password
SOR: Social Networks
Authoritative for: Login Credential
nickname
Repo: MySQL
Authoritative 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 insert
F: DB insert
T: New AD Entry
P: Self Service
T:API CAll
F: DB Delete
T: DB delete
F: SCIM delete
F: DB delete
T: DB delete
F: DB delete
Repo: Oracle
Authoritative for: Scopes
Access Tokens
T: DB delete
F:API Call token wipe
F:API Call token wipe
F: DB delete
Provisioning
System
F: SCIM create
F:API call
T: DB delete
P:Admin App Interface
T: New DB Entry
F: LDAP insert

28. 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

29. 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

30. Thanks!
@pamelarosiedee
http://pingidentity.com
http://eternallyoptimistic.com