Admin Identity & SSO: WIP Demo

Transcript

1. ADMIN IDENTITY & SSO WIP Update @Timur Ramazanov @Sergey Ponomarev #f-admin-identity
2. OVERVIEW
3. Admin Identity & SSO GOALS: RECAP Stronger security requirements for internal actors (HR, IT, OPS, etc) Federated authorisation through SSO 3
4. Admin Identity & SSO PRINCIPLES Operations interruption is not acceptable Any change requires a rollback plan Changes in small incremental chunks 4
5. Admin Identity & SSO HIGH-LEVEL PLAN Phase 1. Decouple internal actors from User model aka “Admin Identity MVP” Phase 2. Implement SSO for Admins with Okta 5
6. ADMIN IDENTITY MVP Phase 1
7. Admin Identity & SSO WHY? Different nature Different data structure Different security requirements 7
8. Admin Identity & SSO PLAN Auth: Introduce Admin entity + CRUD Auth: Enforce stronger security (during the interim period) preserving email/password authentication Auth: Admin becomes an actor in the Auth Admin Area Monolith: Decouple Admin Portal actors from User data 8
9. CHALLENGES
10. Admin Identity & SSO Cover all OAuth flows with tests. 100% code path coverage required. 10 AUTH SERVICE: CHALLENGES
11. Admin Identity & SSO Stronger security requirements 11 AUTH SERVICE: CHALLENGES Required @chowbus.com account // AR validation Password complexity // devise-security gem Mandatory password rotation // devise-security gem Session expiration // devise’s Timeoutable JWT expiration // Doorkeeper magic
12. Admin Identity & SSO Support flexible JWT expiration 12 AUTH SERVICE: CHALLENGES now incorporated as Application#token_expires_in setting Make sure all OAuth clients send client_id for refresh_token flow Web iOS Android
13. Admin Identity & SSO 13
14. Admin Identity & SSO Decouple Admin Portal for persisted User 14 MONOLITH: CHALLENGES current_admin becomes ephemeral. Everything is coming from JWT data. Current Administered Region is stored in Rails session Migrate a bunch of references (approx. 8) to the Admin Portal actor, previously User. Store actor email instead of the DB reference.
15. NOTICEABLE CHANGES
16. Admin Identity & SSO Internal actors become Admins. Old Users are still legit Chowbus customers. Not @chowbus.com actors will be skipped Old password preserved, but on the first login it will require to set a new stronger one Auth Service Admin Area signs out after 6 hours of inactivity * Monolith Admin Portal: refresh_token flow will proceed more often 16
17. PROGRESS
18. Admin Identity & SSO PROGRESS ✅ Auth: Introduce Admin entity + CRUD ✅ Auth: Enforce stronger security (during the migration period) preserving email/password authentication ⏸ Auth: Admin becomes an actor in the Auth Admin Area Monolith: Decouple Admin Portal actors from User data 18
19. Admin Identity & SSO HIGH-LEVEL PLAN Phase 1. Decouple internal actors from User model aka “Admin Identity MVP” Phase 2. Implement SSO for Admins with Okta 19
20. SINGLE SIGN-ON Phase 2
21. Admin Identity & SSO SSO Single credentials, Multiple services 21
22. Admin Identity & SSO RESPONSIBILITIES Single source of truth for internal actors Provisioning & Deprovisioning in internal services Keeping security requirements 2FA Password policies for complexity and rotation Firewall whitelistening (e.g requiring VPN) 22
23. Admin Identity & SSO SSO INTEGRATION OIDC (OpenID Connect) – OAuth 2.0 protocol + JWT 23
24. DATA EXCHANGE FLOWS
25. Admin Identity & SSO AUTHENTICATION 25
26. Admin Identity & SSO DATA PROPAGATION 26 { "uuid": "c2a66d94-f471-11ea-97ad-2f8850418bae", "published": "2020-09-11T21:00:02.239Z", "eventType": "user.account.update_profile", "version": "0", "displayMessage": "Update user profile for Okta", "severity": "INFO", "outcome": { "result": "SUCCESS" }, "target": [ { "id": "00uvqmujhlxYt39444x6", "type": "User", "alternateId": "sergey.ponomarev@chowbus.com", "displayName": "Sergey Ponomarev" } ] }
27. Admin Identity & SSO REFRESH TOKEN 27
28. CHALLENGES
29. Admin Identity & SSO 29 ROLES MANAGEMENT What are roles in Okta? How to expose them in OIDC and API? Roles has scopes
30. Admin Identity & SSO 30 REGIONAL OPS ADMIN
31. Admin Identity & SSO 31 REGIONAL OPS ADMIN
32. Admin Identity & SSO 32 REGIONAL OPS ADMIN Scopes synchronisation: •Production is a single source of truth •Once a region is created, corresponding custom attribute values are propagated to Okta
33. Admin Identity & SSO 33 MULTIPLE ENVIRONMENTS Distinguish users between environments Development happiness
34. Admin Identity & SSO 34 MULTIPLE ENVIRONMENTS
35. Admin Identity & SSO 35 MULTIPLE ENVIRONMENTS
36. NOTICEABLE CHANGES
37. Admin Identity & SSO Internal actors starts login through Okta Okta is a single source of truth for Admin data 37
38. PROGRESS
39. Admin Identity & SSO PROGRESS ✅ All done! 39
40. NEXT
41. Admin Identity & SSO 41
42. THANKS! @Timur Ramazanov @Sergey Ponomarev #f-admin-identity