Authentication and Security¶
Applies to: All subscriptions
Purpose¶
Give a customer's security team everything needed to review, approve and configure Complifly — and give administrators everything needed to operate it securely. This section doubles as the evidence pack for a security questionnaire.
Audience¶
Security architects and reviewers, identity administrators, integration developers, internal audit.
Prerequisites¶
- Technical Architecture Overview
- Installation Guide complete, for the configuration steps
Steps¶
Two authentication planes, deliberately separate¶
Complifly authenticates people and machines by different mechanisms, and they share no credentials.
| People | Machines | |
|---|---|---|
| Who | Users in a browser | ERP systems calling the API |
| Mechanism | Sign-in producing a session token; optionally an external identity provider | An identity-provider OAuth token, or a scoped static key |
| Scope | Role permissions plus GSTIN access | GSTIN scope on the credential |
| Lifetime | Short session | Short-lived token, or a long-lived key that must be rotated |
| Documented in | User Authentication | Machine-to-Machine Authentication |
The separation is the point: revoking an ERP credential cannot lock a person out, and disabling a user cannot stop an integration. It also means a compromised integration credential cannot be used to sign in to the application.
The pages¶
| Page | Covers |
|---|---|
| User Authentication | Sign-in, identity providers, sessions, one-time codes, account lifecycle |
| Machine-to-Machine Authentication | ERP credentials, OAuth, scoped keys, rotation, migration between them |
| Security Hardening | Transport, secrets, host, database, logging and the review checklist |
| Data Protection and DPDP | Personal data handling, consent, retention, and the privacy module |
Tenant isolation is documented once, in Multi-Tenancy and Row-Level Security. It is the page to hand a reviewer who asks how one customer's data is kept from another, and it contains the evidence procedure.
The five things a security review will focus on¶
Authorisation scope comes only from a verified identity. The tenant scope applied to every request is derived from the verified token or an equivalent server-derived identity — never from a client-suppliable path or body parameter. Taking it from client input would turn ordinary access into privilege escalation, so this is a property worth stating explicitly to a reviewer.
Isolation is enforced in the database, not only in application code. Security policies filter rows inside the engine. Isolation therefore does not depend on every query being written correctly.
Machine credentials are scoped to specific registrations. An ERP credential can submit documents only for the GSTINs in its scope. A document for any other registration is refused, whatever the credential is otherwise permitted to do.
Segregation of duties is enforced, and relaxing it is a recorded decision. The person who prepares a document is not the person who commits it, unless the customer has deliberately chosen otherwise. See Segregation of Duties.
Downloads are signed and time-limited, not session-authenticated. Generated files are served from a separate origin that never receives the session cookie. That is a deliberate design decision with a security consequence in both directions — see Domains and URLs.
Validation¶
A security review is complete when the reviewer can evidence each of these — by testing, not by reading:
| Property | Evidence |
|---|---|
| Cross-tenant access is impossible | Sign in as tenant A, request a tenant B record, receive nothing |
| Scope is server-derived | Alter a client-supplied identifier; the result does not change |
| Machine credentials are scoped | Submit a document for an out-of-scope registration; it is refused |
| Credentials can be revoked | Revoke one and confirm calls stop immediately |
| Secrets are protected | Configuration file permissions restricted; nothing secret in the front-end bundle |
| Transport is secure | TLS version and cipher policy meet the customer's standard |
| Actions are attributable | The audit trail shows who did what and when |
| Segregation is enforced | A preparer cannot commit, unless relaxation is recorded and authorised |
Troubleshooting¶
| Symptom | Cause | Action |
|---|---|---|
| Review stalls on isolation | Reviewer expected application-only isolation | Provide Multi-Tenancy and Row-Level Security |
| Review asks for certification evidence | Not available in this portal | Request certificates and test summaries from Complifly. Recorded as assumption E5 in the Assumptions Register |
| Review asks for the password policy | Not stated in this portal | Recorded as assumption E3 |
| Review objects to secrets in a file | No vault integration documented | Recorded as assumption E2; discuss supported options with Complifly |
| Review objects to a long-lived integration key | Static keys are supported for migration | Move to identity-provider tokens. See Machine-to-Machine Authentication |
Related Articles¶
- Multi-Tenancy and Row-Level Security — the isolation model
- User and Role Administration — who can do what
- Assumptions Register — the security facts this portal cannot confirm