FAQs

Q1. Does the Auth Service decide if user X can perform action Y?

Not for end-user requests. It stores and serves policies/roles and resolves them (Policy Action API). The actual allow/deny evaluation for incoming requests is done by the JWT-auth layer / consuming services. Within this service, preauth + isAdmin gate who may administer the data.

Q2. What database and collections does it use?

MongoDB, database authdb_, collections policy, policyRoleMapping, and read-only masterseeddata.

Q3. Is businessId always required?

Yes for all Policy and Role endpoints (integer, must be > 0). The only exception is GET /v1/service-privileges, which does not take businessId.

Q4. How do I delete a policy — is it permanent?

DELETE /v1/policies/:id is a soft delete: it sets status=DELETED and returns 204. Roles, by contrast, are permanently removed.

Q5. Can I rename a role?

No. roleName is immutable — the update validator rejects any PATCH body containing roleName with EQ-PRL-4000002.

Q6. What action format do policies expect?

Colon-separated service:action (e.g. user:create, order:view:*). Slash formats are rejected with EQ-POL-4000008.

Q7. Are events emitted when a policy/role changes?

No. The event publisher is a no-op stub and is never called from the request path (see Events section).

Q8. How does the Policy Action endpoint decide which policies to return?

It loads the business’s roles (optionally filtered by roleIds), then for each role returns its referenced allow-effect policies, keyed by role name.

Q9. How do I run it locally without MongoDB?

Set AUTH_USE_INMEMORY=true to use the in-memory adapter for local development and testing.

Q10. Where are error messages translated?

Messages are available in English, French, and Arabic, selected via the Locale header (fallback English).

Revision History
2026-08-05 | AN – Created the page and added the content.