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/

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

4. WSO2 Identity Server

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

7. Deployment Options

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. Deployment Architecture

10. Deployment Ecosystem

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

16. Deployment Patterns

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

21. Azure Datacenters

22. Azure Security and Compliance

23. WSO2 Reference Architecture

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

32. Question Time!
32

33. wso2.com
Thanks!