SlideShare a Scribd company logo

Identity Server on Azure: A Reference Architecture

•
•
WSO2
WSO2

As the popularity of cloud-based deployment is on the rise, more and more organizations are moving their mission-critical workloads into cloud services. Microsoft Azure is one of the fastest-growing cloud service providers. They have gained the trust and loyalty of lots of users over the year. WSO2 identity server is an extensible identity access management solution for implementing cost-effective identity management infrastructure. WSO2 Identity Server supports deployments on-premises, many cloud service providers and hybrid models. Watch the on-demand recording here - https://wso2.com/library/webinars/identity-server-on-azure-a-reference-architecture/

Related slideshows

Introduction to docker
Introduction to dockerIntroduction to docker
Introduction to docker
 
(DVO306) AWS CodeDeploy: Automating Your Software Deployments
(DVO306) AWS CodeDeploy: Automating Your Software Deployments(DVO306) AWS CodeDeploy: Automating Your Software Deployments
(DVO306) AWS CodeDeploy: Automating Your Software Deployments
 
Intro to kubernetes
Intro to kubernetesIntro to kubernetes
Intro to kubernetes
 
1 of 33
Download to read offline
Identity Server on Azure: A Reference Architecture May 27th, 2020
Hello! Supun Perera Ajanthan Balachandran Senior Software Engineer ajanthan@wso2.com supunpe@wso2.com Senior Lead Solution Engineer
Identity Server on Azure: 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
WSO2 Identity Server
5 WSO2 Identity and Access 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 Product Capabilities Identity Federation and SSO Identity Bridging Strong and Adaptive Authentication Fine Grained Access Control API and Microservices Privacy Regulations and Compliances Identity Provisioning and Administration
Deployment Options
● 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
Deployment Architecture
Deployment Ecosystem
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
Required Softwares ● Operating system ⦿ 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
Network Architecture ● WSO2 Identity 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
Clustering ● Minimum HA requires 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
Determining the Number of 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
Deployment Patterns
Deployment Pattern 1 ● Highly available deployment of WSO2 Identity Server ● Deployment for scalability
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
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
Azure
Azure Datacenters
Azure Security and Compliance
WSO2 Reference Architecture
Capacity Planning ● Virtual Machine ⦿ CPU ⦿ Memory ⦿ Disk ● Database ⦿ CPU ⦿ Memory ⦿ IOPS
Capacity Planning - Azure DTU Metrix
Capacity Planning - Azure vCore Metrix
Capacity Planning - Azure vCore General Purpose
Monitoring and Alerts Monitoring and alerts can be easily configure with Azure Monitor. ● VM Resource Monitoring ● Network Level Monitoring ● Log4j Monitoring ● JMX monitoring ● Customized Alerts
Reliability and Availability Automated backup and DR solution ● Backup service ⦿ Virtual Machines ⦿ Database Servers ● Site Recovery service ⦿ Complete DR solution
Best Practices ● Shared Mount 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.
Demo
Question Time! 32
wso2.com Thanks!

More Related Content

Identity Server on Azure: A Reference Architecture

  • 1. Identity Server on Azure: A Reference Architecture May 27th, 2020
  • 2. Hello! Supun Perera Ajanthan Balachandran Senior Software Engineer ajanthan@wso2.com supunpe@wso2.com Senior Lead Solution Engineer
  • 3. Identity Server on Azure: 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
  • 5. 5 WSO2 Identity and Access 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 Federation and SSO Identity Bridging Strong and Adaptive Authentication Fine Grained Access Control API and Microservices Privacy Regulations and Compliances Identity Provisioning and Administration
  • 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
  • 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 ● Operating system ⦿ 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 ● WSO2 Identity 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 HA requires 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 Number of 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
  • 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. Azure
  • 22. Azure Security and Compliance
  • 24. Capacity Planning ● Virtual Machine ⦿ 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 Monitoring and alerts can be easily configure with Azure Monitor. ● VM Resource Monitoring ● Network Level Monitoring ● Log4j Monitoring ● JMX monitoring ● Customized Alerts
  • 29. Reliability and Availability Automated backup and DR solution ● Backup service ⦿ Virtual Machines ⦿ Database Servers ● Site Recovery service ⦿ Complete DR solution
  • 30. Best Practices ● Shared Mount 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. Demo