The Guard With No Roles
Your staff are authorised by role permissions declared in a map and tested against the real routes. Your suppliers are authorised by owning the record. Two models, both correct, and knowing which applies where is the whole of portal security.
A supplier signing into your workspace holds no permissions at all. Not few — none. There is no role to give them.
This reads at first like something missing and it is the design. A portal user is not a member of your organisation with a restricted view; they are an outside party who can reach exactly the records that are theirs. Those are different security problems and they want different answers.
How staff are authorised
Every internal route that matters declares a permission, and that declaration is mirrored in a map covering both the web routes and the interface. A test compares the map against the real middleware on the real routes and fails when they disagree in either direction — a permission in the map with no route, or a route the map does not describe.
That machinery exists because of a specific failure worth naming. The controller that serves stored files checks the organisation and nothing else, by design, so the permission has to come from the route. For a period, nine file routes had no permission on them — which meant any signed-in member of a workspace could pull proof-of-payment documents, supplier invoices and quotation attachments regardless of their role. The sibling signature routes beside them were gated. The module looked covered.
The map catches a missing entry, not a missing gate
Worth being precise about, because it decides how you use it. The test compares the map against the routes, so a route with a permission and no map entry fails, and a map entry with no route fails. What it cannot detect is a route that appears in neither. That is why the instruction is to write both — the map entry is what makes the missing gate visible.
How a supplier is authorised
By two equalities. The document belongs to the organisation the supplier is registered with, and the document belongs to that supplier. Both true, or refused.
That is the whole check on the route that serves a supplier their own quotation attachment, and the same shape repeats on every action in the portal: accepting an order, rejecting one, updating a shipping status, closing a completed order. Resolve the supplier from their session, compare the record's owner against them, refuse otherwise.
| Staff | Suppliers | |
|---|---|---|
| What authorises the request | A named permission on the route | Ownership of the specific record |
| Where it is declared | On the route, and in a map tested against the routes | In the controller, as an equality |
| What it grants | A class of records — all customer payments, all adjustments | One record at a time |
| How it fails | Refused for the whole route | Refused for that record |
| What else guards it | Role assignment and plan permissions | Multi-factor authentication and a rate limit on every action |
A permission answers "may this kind of person do this". Ownership answers "is this yours".
Why ownership is the right model here
Three reasons, and the third is the one people miss.
-
There is no such thing as a supplier who may see all quotations
The set a supplier may see is defined entirely by what belongs to them. A permission model would have to express that as a filter anyway, and a filter that has to be applied everywhere is a check that will be forgotten somewhere.
-
A role is a promise about a category of user
Your organisation has categories — buyers, approvers, finance. Your suppliers are not a category with internal structure; they are hundreds of separate parties who share no interests. Modelling them with roles invites a role that spans them.
-
Ownership fails closed at the record
A missing permission on a route opens that route to everybody who can sign in. A missing ownership check has to be missing on the specific action, and the action is small enough to read in one screen. The blast radius of the mistake is the difference.
What the model costs
Being honest about this matters, because the limitation is real and it is the thing organisations meet first. A supplier login is one identity tied to one supplier record. There is no way to give a supplier's accounts clerk a read-only view while their sales manager answers quotations, because there are no roles to distinguish them — the login either is that supplier or it is not.
For most suppliers on most registers that is exactly right and nobody notices. For a large supplier with several people who interact with you, it means one shared credential, which is the outcome nobody wants and everybody arranges. That is the piece worth commissioning, and it is a smaller change than it sounds: several logins pointing at one supplier record, each with a scope.
Five questions to ask about a supplier portal
What can a supplier see?
A good answer sounds like
Only their own records, and how that is enforced.
What ours actually is
Records matching both their organisation and their own supplier identifier, checked as two equalities on every action.
Do suppliers hold permissions?
A good answer sounds like
A clear answer either way.
What ours actually is
None. The guard they sign in on has no role permissions at all, deliberately.
Can a supplier reach another supplier's quotation?
A good answer sounds like
No, with the check named.
What ours actually is
No. The document's supplier identifier must equal theirs, or the request is refused.
How are staff file routes protected?
A good answer sounds like
A permission per route, tested.
What ours actually is
A declared permission on the route, mirrored in a map that a test compares against the real middleware in both directions.
Can one supplier have several logins?
A good answer sounds like
An honest answer.
What ours actually is
Not today — one login per supplier record. Several scoped logins against one record is the piece named as commissionable.
What AWRA OpsHub does today
- A separate authentication guard for suppliers, distinct from staff accounts and from the customer portal.
- Authorisation by ownership on every portal action — the record's organisation and the record's supplier identifier both compared against the signed-in supplier.
- The same two-equality check on the route that serves a supplier their own quotation attachment, rather than a permission that would have to be filtered.
- Multi-factor authentication available on supplier logins, with a forced password change on first sign-in.
- A rate limit on every state-changing portal action, and a separate one on the multi-factor reminder.
- A declared permission on staff routes, mirrored in a map covering both web and interface routes.
- A test comparing that map against the real route middleware, failing on a mismatch in either direction.
- A file-serving controller that checks the organisation and nothing else on staff routes, by design, so the permission has to be declared where it can be tested.
More we can add to your workspace
- Several logins against one supplier record, each with its own scope, so a supplier's accounts clerk and their sales manager do not share a credential.
- A read-only supplier login, able to see orders and quotations without being able to accept, reject or close anything.
- A record of which supplier user took a portal action, which follows from the first item and is what makes an acceptance attributable.
- Supplier-side delegation, letting a supplier invite their own colleagues within limits you set.
- A last-seen and last-action view per supplier login, so a dormant portal account is visible.
- A detection for a route with neither a permission nor a map entry, which is the one shape the current test cannot see.
Where we point you to a specialist
- We will not give supplier logins role permissions that span suppliers. A role is a statement about a category of user, and your suppliers are separate parties who share no interests — a role that spans them is an invitation to grant one supplier a view of another's pricing.
- We will keep the file-serving controller checking the organisation and nothing else, and keep the permission on the route. One controller trying to decide what each of its callers should be allowed to serve is how a nine-route hole was possible in the first place.
- Who inside a supplier organisation should hold a login is their decision and your commercial arrangement. We will provide the credentials and the controls; we will not adjudicate their internal delegation.
Several scoped logins against one supplier record is the contained piece here, and it removes the shared credential that large suppliers currently arrange for themselves.
One record, several people
Ownership as the model is settled and right. What large suppliers need is for ownership to be held by more than one login, with different scopes.
Multiple logins per supplier
Several credentials against one supplier record, so nobody shares a password to answer a quotation.
A read-only scope
A login that can see orders and quotations and cannot accept, reject or close anything.
Attributable portal actions
Which person at the supplier accepted an order, not merely which supplier — which is what makes an acceptance evidence.
We publish scope, not dates.
Scope portal accessOur take
Two authorisation models in one product sounds like an inconsistency and is a deliberate match to two different problems. Inside your organisation, the question is what kind of person this is, and a role answers it — with the machinery to prove every route declares one, because the failure mode there is a whole class of records exposed to everybody who can sign in. Outside it, the question is whether this record is yours, and an equality answers it more reliably than any role could. What the outside model costs is granularity: one login, one supplier, no distinction between the person who negotiates and the person who files. That is the honest limitation, it is felt only by your largest suppliers, and it is the smallest of the things on this page to fix.
Ask who at your supplier holds the password
For most of your register the answer is one person and nothing needs changing. For your three largest suppliers it is usually a shared inbox, and that is worth knowing before an acceptance is disputed.
Talk through portal accessFrequently asked questions
Why do supplier accounts have no roles?
Because a role is a statement about a category of user and your suppliers are not a category — they are separate parties with no shared interests. The set of records a supplier may see is defined entirely by what belongs to them, so ownership answers the question directly. A role model would have to express the same restriction as a filter, and a filter applied in many places is a check that gets forgotten in one of them.
How is a supplier stopped from seeing another supplier's quotation?
By two equalities checked on the request: the document's organisation must match theirs, and the document's supplier identifier must match theirs. Both, or the request is refused. The same comparison guards accepting an order, rejecting one, updating shipping and closing a completed order.
Can we give a supplier a read-only login?
Not today. A supplier login either is that supplier or it is not, so it can do everything the portal offers for their own records. A read-only scope is on the list above, and it usually comes up alongside the request for several logins against one supplier record.
How do you know every staff route is protected?
A map declares the permission for each route, and a test compares that map against the real middleware on the real routes, failing when they disagree in either direction. The limit worth knowing is that a route appearing in neither the map nor the middleware is invisible to it — which is why the instruction when adding a protected route is to write both halves.
What happens when a supplier stops working with us?
Their login is disabled with their supplier record, and every ownership check then fails at the first equality because there is no signed-in supplier. What is worth doing deliberately is the same thing you would do for a departing employee: retire the credential rather than relying on the record being marked inactive.
Is the customer portal the same?
It is a separate guard with its own arrangements, and it deserves its own answer rather than an assumption based on this one. The principle is the same — an outside party reaching their own records — but the mechanisms differ and it is worth asking about specifically rather than generalising from the supplier side.
