WSO2 Identity Server - Hardened Identity and Access Server

What is WSO2 Identity Server

WSO2 Identity Server is an open-source identity and access management platform. It issues and validates tokens for your applications and APIs, and centralises how users sign in across them. It implements the standards your stack already speaks: OAuth 2.0 and OpenID Connect (authorization code, client credentials, refresh, token exchange, CIBA, device grant), SAML 2.0, SCIM 2.0 for user provisioning, and OIDC front-channel logout. It supports multi-factor authentication, adaptive and conditional authentication, passwordless and social login, B2B organisation management, self-service registration and password recovery, and fine-grained role and API-resource authorisation. Administration is through a browser Console; end users manage their own profile, sessions and MFA enrolments through a separate My Account portal.

Why self-host WSO2 Identity Server

Identity is the one system that sees every login, every token and every user attribute you hold. Self-hosting keeps that data in your own subscription and region, which matters for GDPR and for data-residency obligations. Cost is per virtual machine rather than per monthly active user, so it does not scale with your user base. The protocols are open standards, so integrated applications stay portable and you control the upgrade schedule.

What this VM image adds

Security hardening:

• No baked administrator password - a random super-admin credential is generated on first boot and written to a root-only file; no image ever ships a known password
• Keystore regenerated at first boot - the distribution's default key is publicly known, so a fresh 2048-bit RSA key with correct subject alternative names replaces it before the server ever starts
• Truststore password rotated - moved off the published default value
• Internal endpoint credential rotated - the shipped default application password and its hash are both replaced on first boot
• HTTPS only - the plain HTTP transport is disabled, so only the TLS port serves traffic and only it is opened in the firewall
• TLS 1.2 and 1.3 only - older protocol versions are switched off
• PostgreSQL backing store on loopback - identity, shared and agent databases are local-only and never exposed off the VM
• CVE scan - every image is scanned for vulnerabilities with Trivy before release
• UFW firewall - only the console/API port and SSH on 22 are reachable
• fail2ban - SSH brute-force protection
• AppArmor - mandatory access control

OS hardening (CIS Level 1):

• CIS Level 1 hardened - CIS Ubuntu 24.04 LTS Level 1 Benchmark via ansible-lockdown
• auditd - system call auditing for critical paths
• SSH hardening - PasswordAuthentication disabled, key-only access
• Kernel hardening - SYN cookies, ASLR, rp_filter, TCP BBR
• /tmp as tmpfs - nosuid, nodev, noexec
• Azure IMDS endpoints - egress rules pre-configured (169.254.169.254, 168.63.129.16)

Compliance artifacts (inside the VM):

• SBOM - CycloneDX 1.6 at /etc/lynxroute/sbom.json
• CIS Conformance Report - OpenSCAP HTML at /etc/lynxroute/cis-report.html
• Tailored CIS profile - /usr/share/doc/lynxroute/CIS_TAILORED_PROFILE.md
• Generated credentials file - /root/wso2is-credentials.txt, readable by root only

Quick Start

1. Deploy the VM from Azure Marketplace (Standard_D4s_v3 or larger recommended; the platform needs 4 vCPU and 4 GB RAM as a minimum)
2. SSH: ssh -i key.pem <username>@<PUBLIC_IP> (username set during VM creation, default: azureuser)
3. Check status: MOTD shows the version, service state and the console URL on login
4. Read the generated administrator password: sudo cat /root/wso2is-credentials.txt
5. Open https://<PUBLIC_IP>:9443/console, accept the self-signed certificate and sign in as admin; end users get https://<PUBLIC_IP>:9443/myaccount
6. Create your own administrator, then disable the generated account

Restrict the network security group so that only your own network reaches port 9443, and replace the self-signed certificate with your own before going to production.