CIS14: Identity Souffle: Creating a Well-baked Identity Lifecycle
•
2 gostaram•788 visualizações
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.
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (14)
Semelhante a CIS14: Identity Souffle: Creating a Well-baked Identity Lifecycle
Semelhante a CIS14: Identity Souffle: Creating a Well-baked Identity Lifecycle (20)
Mais de CloudIDSummit
Mais de CloudIDSummit (20)
Último
Último (20)
CIS14: Identity Souffle: Creating a Well-baked Identity Lifecycle
- 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"} ] }
- 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