keycloak

Keycloak is a separate server that you manage on your network. Applications are configured to point to and be secured by this server.

This redirection is important because users are completely isolated from applications and applications never see a user’s credentials. Applications instead are given an identity token or assertion that is cryptographically signed.

To setup keycloak for the production release (https://www.keycloak.org/server/configuration-production), we need to configure it at two levels:

1. hostname: https://www.keycloak.org/server/hostname
2. database: https://www.keycloak.org/server/db

First-time setup

sudo kc.sh start-dev

Here's what I recommend for a production Keycloak setup:

My Recommendation: Single Subdomain + Reverse Proxy Rules

Use one subdomain (e.g., auth.yourdomain.com) and properly configure your reverse proxy to block admin endpoints from public access.

Why this approach:

1. Simpler to manage: One subdomain, one certificate, fewer DNS records
2. Actually secure: The two-subdomain approach doesn't provide real security without reverse proxy rules anyway (as the documentation warns)
3. Standard practice: Most production Keycloak deployments I've seen use this pattern
4. Cost-effective: No need for additional infrastructure or certificates

Configuration

At your reverse proxy (Nginx, Apache, or load balancer), block these paths from public internet: - /admin/* - Admin Console - /realms/master/* - Master realm (if not needed publicly) - Any other administrative endpoints

Allow public access to: - /realms/{your-realm}/protocol/openid-connect/* - Authentication flows - /realms/{your-realm}/account/* - User account management (if needed) - /js/*, /resources/* - Static assets

When Two Subdomains Might Make Sense

• You have a very strict network architecture requiring physical separation
• Admin access comes from a completely different network segment
• You want different WAF/security policies for admin vs. public traffic

But even then, you still need the reverse proxy rules, so it's additional complexity without significant security benefit for most use cases.

Bottom line: Start with one subdomain and good reverse proxy configuration. It's simpler, equally secure when done right, and easier to maintain.

keycloak hostname

Yes, exactly! You're absolutely right. Let me clarify:

SSL Certificate Management

SSL certificates (issued by Certbot/Let's Encrypt) are typically managed by Nginx (or Apache), not Keycloak directly.

Typical Architecture:

Internet (HTTPS) → Nginx (port 443, handles SSL) → Keycloak (port 8080, HTTP)

What This Means:

1. Nginx handles:
2. SSL/TLS termination (uses your Certbot certificates)
3. Listens on port 443 (HTTPS)

4. Forwards requests to Keycloak via HTTP internally

5. Keycloak handles:

6. Business logic (authentication, authorization)
7. Listens on port 8080 (HTTP internally)
8. Doesn't need to know about SSL certificates

Your Keycloak Configuration Should Be:

bin/kc.sh start \
  --hostname https://auth.yourdomain.com \
  --http-enabled true \
  --proxy-headers xforwarded

• --hostname https://auth.yourdomain.com - tells Keycloak what URL users see
• --http-enabled true - allows Keycloak to accept HTTP (from Nginx)
• --proxy-headers xforwarded - trusts Nginx's forwarded headers

Your Nginx Configuration Should Include:

server {
    listen 443 ssl;
    server_name auth.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/auth.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/auth.yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Port $server_port;
    }
}

This is the standard and recommended approach - let Nginx handle SSL! 🎯

Comments