Download as PDF, PPTX
Uploaded byWSO2
Identity Server on Azure: A Reference Architecture
The document outlines a reference architecture for deploying WSO2 Identity Server on Azure, detailing its features and capabilities in identity and access management. It covers deployment options, architectural considerations, capacity planning, monitoring, and best practices for ensuring reliability and scalability. The document serves as a guide for organizations looking to implement WSO2 Identity Server in cloud environments while maintaining performance and security.
More Related Content
![[오픈소스컨설팅] 아파치톰캣 운영가이드 v1.3](https://cdn.slidesharecdn.com/ss_thumbnails/opensourceconsultingtomcatoperationguidev1-181113020525-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
Similar to Identity Server on Azure: A Reference Architecture
![[Roundtable] Choreo - The AI-Native Internal Developer Platform as a Service](https://cdn.slidesharecdn.com/ss_thumbnails/choreo-deck-250328074645-511dded7-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
Identity Server on Azure: A Reference Architecture
- 1. Identity Server onAzure: A Reference Architecture May 27th, 2020
- 2. Hello! Supun Perera Ajanthan Balachandran SeniorSoftware Engineer ajanthan@wso2.com supunpe@wso2.com Senior Lead Solution Engineer
- 3. Identity Server onAzure: A Reference Architecture ● WSO2 Identity Server ⦿ Introduction ⦿ Deployment options ⦿ Deployment architecture ● Azure ⦿ Reference Architecture ⦿ Capacity Planning ⦿ Monitoring and alerting ⦿ Reliability and availability ⦿ Best practises ⦿ Demo Agenda 3
- 4.
- 5. 5 WSO2 Identity andAccess Management Server WSO2 Identity Server is a uniquely extensible, API driven, cloud native open source IAM product, designed for developers that build Customer IAM solutions. It helps federate, authenticate, and manage identities, bridge identity protocols across environments, and secure access to web, mobile apps, and API-based endpoints.
- 6. 6 Product Capabilities Identity Federationand SSO Identity Bridging Strong and Adaptive Authentication Fine Grained Access Control API and Microservices Privacy Regulations and Compliances Identity Provisioning and Administration
- 7.
- 8. ● Multi-tenanted, shared everything ●On-premise userstore or Cloud userstore with IdP in the Cloud ● WSO2 Hosted and managed ● Pay as you go ● Guaranteed uptime ● Limited options in customizing ● Privately hosted ● WSO2 managed ● Upgrades, patches installation ● Guaranteed uptime ● Full flexibility in customization ● Better control ● Self hosted ● Self managed ● Full flexibility ● Dev-ops learning curve ● Self managed upgrades 8 Cloud First or Start with Self-hosted and Self-managed Software as Service WSO2 Managed Service Self-hosted and self -managed
- 9.
- 10.
- 11. Required Subsystems ●Bare Metal/VM/Container ⦿ 4 or 2 core CPU/VPU ⦾ 2 cores are only for low end use cases ⦿ 4 GB Memory ⦿ 10 GB HD ● Database ⦿ Configuration and meta data store ⦿ Runtime data store ⦿ Users store ● Directory server ⦿ Needed only if the user profiles are in directory server ● Optional ⦿ WSO2 Identity Analytics ⦿ Other DevOps/CICD tools
- 12. Required Softwares ● Operatingsystem ⦿ Supporting all major OSs ⦿ Tested against WIN,Linux and Unix flavours ● JAVA ⦿ Supporting all the JDK distributions ⦿ Thoroughly tested on Openjdk ● JDBC Drivers ⦿ Relevant JDBC drivers are needed according to RDBMS used
- 13. Network Architecture ● WSO2Identity Server should be deployed inside the private network ● Deploying on public network or DMZ is not recommended ● Expose public facing endpoints through a Load Balancer or Reverse Proxy ● Only expose functional web endpoint to public ● Block management endpoint(Management console and APIs) unless needed
- 14. Clustering ● Minimum HArequires 2 nodes ● Clustering enables grouping nodes and horizontal scaling ● Uses Hazelcast for passing messages between nodes ● Nodes have local Caches ● Cache invalidated through message passing ● LB/RP route traffic among nodes ● Shared file system is for sharing secondary userstore configurations
- 15. Determining the Numberof Nodes ● Single node(4 cores) can handle ⦿ 150 concurrent users ⦿ 175 Login per second ● Latency in both cases is less than 1s ● Horizontal scaling yields ⦿ Near linear performance increase ⦿ Supporting systems should also be scaled to avoid bottlenecks ⦾ Database ⦾ Directory Server
- 16.
- 17. Deployment Pattern 1 ●Highly available deployment of WSO2 Identity Server ● Deployment for scalability
- 18. Deployment Pattern 1 ●TPS based scaling ● Horizontal auto-scaling via AWS/Azure/Google App Engine or container platforms such as K8S or OpenShift Number of nodes(Cores) Traffic Pattern High* Medium** Low*** Number of users < 1 Million 2(2) 2(2) 2(2) <2 Million 2(2) 2(2) 2(2) <3 Million 3(2) 2(2) 2(2) <4 Million 2(4) 2(2) 2(2) <5 Million 5(2) 2(2) 2(2) 7-10 Million 10(2) 5(2) 3(2) ● Low traffic ⦿ 50% users are login in 10 times a day ⦿ 25% users are login in 6 times a day ⦿ 25% users are login in 3 time a day ● Medium traffic ⦿ 50% users are login in 5 times a day ⦿ 25% users are login in 3 times a day ⦿ 25% users are login in 2 times a day ● High traffic ⦿ 50% users are login in 3 times a day ⦿ 25% users are login in 2 times a day ⦿ 25% users are login in 1 time a day
- 19. Deployment Pattern 2 ●Highly available deployment of WSO2 IS and WSO2 IS Analytics ● Minimum recommendation is 2 active/active IS nodes and 2 active/passive IS Analytics nodes ● Deployment for scalability ● IS Analytics doesn’t support horizontal dynamic scaling
- 20.
- 21.
- 22. Azure Security andCompliance
- 23.
- 24. Capacity Planning ● VirtualMachine ⦿ CPU ⦿ Memory ⦿ Disk ● Database ⦿ CPU ⦿ Memory ⦿ IOPS
- 25. Capacity Planning -Azure DTU Metrix
- 26. Capacity Planning -Azure vCore Metrix
- 27. Capacity Planning -Azure vCore General Purpose
- 28. Monitoring and Alerts Monitoringand alerts can be easily configure with Azure Monitor. ● VM Resource Monitoring ● Network Level Monitoring ● Log4j Monitoring ● JMX monitoring ● Customized Alerts
- 29. Reliability and Availability Automatedbackup and DR solution ● Backup service ⦿ Virtual Machines ⦿ Database Servers ● Site Recovery service ⦿ Complete DR solution
- 30. Best Practices ● SharedMount only for <IS_HOME>/../userstores directory. ● Choose the correct VM and Database type. ● Create backup and recovery sites in prior and verify them. ● Do not explored VMs to public. ● Have separate resource groups for different environments. ● Keep strict firewall and Network security groups (NSG) rules. ● Schedule the cleanup Tasks.
- 31.
- 32.
- 33.