Download as ODP, PPTX
Case study: IDP
- 1. Case Study: ScalableIDP George Georgovassilis Consulting Digitalisation @blog.georgovassilis.com
- 2. blog.georgovassilis.com2 Hi! I’m George Internationalbusiness consulting (APAC, BeNeLux, DACH, EMEA) Helping organisations on their digitalisation journey Accenture, Allianz and Max Planck alumn TOGAF, Scrum, Design thinking practitioner
- 3. blog.georgovassilis.com3 Requirements - OIDC-capable IDP -Arbitrary availability & scalability - Extensible architecture - Security
- 4. blog.georgovassilis.com4 Considerations - Availability definition -system vs function - user vs resource - Availability constrained by infrastructure - Security by design and operations - OIDC notions
- 5.
- 6.
- 7.
- 8.
- 9.
- 10. blog.georgovassilis.com10 Ingredients - Multiple locations -Container runtime - Redhat SSO - ELK - Haproxy - Terraform - Dedicated user repository for mgmt
Editor's Notes
- #5 Scalablity and availability are achieved either by highly available instances and vertical scaling (expensive, has limits) or by horizontal scaling. System limits apply to horizontal scaling. Eg. Amazon EC2 SLAs are below case study requirements. Availability definition: downtime per day, hour? Downtime as measured by user or federated application? Broken transaction: replay or fail? Sub-system availability Scalability is limited by state and infrastructure. oath2’s implicit flow can store all state in the client, the explicit flow not. Availability is a chain: limited by weakest link
- #6 Scalability starts with the client’s ability to converse with interchangeable endpoints. Redundancy: locations, network paths
- #7 Operational view: network zones, monitoring, management, clients and resources
- #8 Drill-down to domain management view.