Configuration

MAPS uses JAAS-based realms for authentication. You define JAAS entries in jaasAuth.config, map those entries to internal auth names in SecurityManager.yaml, and reference those names per interface in NetworkManager.yaml.

TL;DR

1. Define JAAS entries → jaasAuth.config
2. Map them to internal names → SecurityManager.yaml
3. Use the mapped name on each listener → NetworkManager.yaml

---

1) Define JAAS entries (jaasAuth.config)

Each entry declares a login module (or chain) and becomes a realm you can reference later.

UsernamePasswordLoginModule {
  io.mapsmessaging.security.jaas.IdentityLoginModule Required
    debug=false
    siteWide="system";
};

PublicAuthConfig {
  io.mapsmessaging.security.jaas.AnonymousLoginModule Required
    debug=true;
};

SSLAuthConfig {
  io.mapsmessaging.security.jaas.SSLCertificateLoginModule Required
    debug=true;
};

JWTAuthConfig {
  io.mapsmessaging.security.jaas.AwsJwtLoginModule Required
    region="#################"
    poolId="######################"
    clientId="###########################"
    debug=true;
};

PrivateAuthConfig {
  com.sun.security.auth.module.LdapLoginModule Required
    userProvider="ldap://ldapserver:389"
    authIdentity="uid={USERNAME},OU=people,DC=mapsmessaging,DC=io"
    useSSL=false
    debug=false;
};

Examples

• UsernamePasswordLoginModule → internal username/password (site-wide “system”).
• PublicAuthConfig → anonymous access.
• PrivateAuthConfig → LDAP (bind pattern via authIdentity).
• JWTAuthConfig → Cognito/OIDC JWT validation.
• SSLAuthConfig → mTLS client certs.

---

2) Map JAAS entries to internal names (SecurityManager.yaml)

This creates stable aliases you’ll use across listeners.

SecurityManager:
  -
    default: PublicAuthConfig
    public: UsernamePasswordLoginModule
    private: PrivateAuthConfig
    admin: MessagingAuthConfig
    anon: PublicAuthConfig
    ssl: SSLAuthConfig
    test: TestAuthConfig

• default is the system-wide fallback (here, anonymous).
• Other keys (public, private, ssl, etc.) point to JAAS entries you defined above.

---

3) Use per-interface auth in NetworkManager.yaml

Each listener picks an auth alias from SecurityManager.yaml.

Anonymous NATS:

data:
  - name: "NATS TCP Test anon Interface for raw buffer writes"
    url: "tcp://0.0.0.0:4222/"
    protocol: nats
    enableStreams: true
    auth: anon

MQTT over TLS with username/password (public):

data:
  - name: "MQTT SSL Test Auth Interface"
    url: "ssl://0.0.0.0:1893/"
    protocol: mqtt, ws
    auth: public
    sasl:
      mechanism: "CRAM-MD5"
      identityProvider: system

Because auth is per-interface, different protocols (or even different bindings of the same protocol) can use different realms: anonymous for test NATS, LDAP for internal MQTT, OIDC for REST, mTLS for external ingress, etc.

---

Choosing the right realm (quick guide)

Requirement	Realm example
Public demo / test access	anon → PublicAuthConfig
Username/password (site users)	public → UsernamePasswordLoginModule
Enterprise directory	private → PrivateAuthConfig (LDAP)
JWT/OIDC (Auth0/Cognito)	jwt → JWTAuthConfig
Mutual TLS (device identity)	ssl → SSLAuthConfig

---

Notes & tips

• Keep secrets out of the JAAS file when possible (env vars or externalized secrets).
• Use separate listeners to cleanly isolate auth policies (e.g., internal vs external).
• SASL settings (e.g., CRAM-MD5) are configured on the listener and work with the chosen realm.
• Set a safe default in SecurityManager.yaml to avoid accidental open listeners.