PlatformIdentity & access
An account proves who you are. It does not decide what you may do.
In continON those are separate questions with separate answers. Signing in establishes an identity and stops there. What that identity may reach is assembled afterwards, from the employment record it belongs to, the licence the organization holds, the seat the person occupies, and the privileges that seat resolves to — worked out at sign-in, every time.
The consequence Because authority is derived rather than stored per person, moving somebody changes what they can do without anything being reissued — and a list of personal permissions never exists to drift out of date in the first place.
Six things have to be known. They are known in this order.
- Account
A continON ID
That the person at the keyboard is who the account says they are — and, where they have turned it on, that they also hold the second factor.
Still undecidedEverything. An account on its own reaches nothing: it is not yet attached to a company, a job or a permission.
- AccountEmployment record
The employee the account belongs to
Which organization this person works for. The account is linked to an employment record, and that record belongs to exactly one organization.
Still undecidedWhich parts of continON that organization has at all, and what this particular person may do inside them.
- AccountEmployment recordOrganization licence
What the organization is licensed for
Which modules exist for this organization, and until when. The licence is the outer bound: nothing inside it can grant more than it allows.
Still undecidedWhich of those licensed modules this person reaches, and with what rights.
- AccountEmployment recordOrganization licenceSeat
The position they hold, in a unit
Which permission bundles apply. Bundles are granted to the seat on the org chart, so they follow the seat rather than the individual.
Still undecidedThe exact applications and the exact privileges the bundle resolves to.
- AccountEmployment recordOrganization licenceSeatPermissions
The bundle, or an explicit assignment
Which applications open, and which named privileges come with them. A person can inherit from their position, take a bundle, or be given an explicit set.
Still undecidedWhat that means at the level of a single screen and a single button.
- AccountEmployment recordOrganization licenceSeatPermissionsForm and action
A privilege on a named form
The answer. Rights are held per form and per action — read, create, update, delete, download — not as one coarse role that means the same thing everywhere.
Still undecidedNothing. This is where the chain ends, and it is re-derived at the next sign-in rather than stored and left to age.
One session, and the applications trust it.
Every continON application is a client of one authorization service, so a person signs in once and moves between applications without authenticating again. The chain above is resolved into that session, which is why each application can decide what to show without keeping its own copy of who anybody is.
The authorization service is continON’s own and is deployed per environment, alongside the rest of the workload. Where it runs is a deployment question rather than an identity one. Where continON runs
- Business Administration
- Finance
- Goods & Services
- Human Resources
- Work Management
- Online Recruitment
The last two links, in the product.
Where the bundle comes from
Privileges are inherited from the employee’s position, taken from a bundle, or assigned explicitly — and the licence summary beside them is the bound none of those can exceed.
What a privilege actually is
Not a role. A named form, and the individual actions on it — read, create, update, delete, download — each granted or not.
What the account itself controls — and what it does not.
A second factor, by authenticator app
Any account can enrol an authenticator app by QR code, keep recovery codes, and remember a browser. It is challenged at sign-in once enrolled.
It is enabled by the account holder. continON does not currently offer an organization-wide setting that forces every account to use one.
A password policy with reuse history
Passwords have a minimum length and complexity, cannot repeat recent ones, and are reset by the account holder over email rather than through an administrator.
The personal data on the account
From their own profile, a person can export the personal data held against their account and request its deletion, confirmed with their password.
This is self-service on the account. There is no administrator-side workflow for handling a request made on someone else’s behalf.
Who can create an account at all
Self-registration is switched off. Accounts exist because the organization created them, which is why the chain above can start from an employment record.
Not claimed here This page describes how authority is derived. It does not make a claim about certification, and it does not describe federating an outside identity provider — that wiring exists in the estate but is not enabled in the state we can verify, so it is not published as a feature.
Move one person and watch their access move with them.
On a sanitized tenant: sign in once across the applications, then reassign a seat and see what the same account can reach afterwards — without anything being granted by hand.