The jso-protector/governance module gives release tooling a shared authorization, identity-configuration, provisioning, and audit contract. The account dashboard now adds durable organization, SCIM-token, directory-user, and audit storage plus a bearer-authenticated /v1/scim/Users.ashx endpoint. Apply App_Data/CreateEnterpriseGovernanceTables.sql before enabling it.
Role-based release policy
Built-in roles are owner, admin, developer, reviewer, and viewer. Permissions distinguish protection runs, project changes, evidence export, member/token administration, billing, and audit review.
const governance = require("jso-protector/governance");
const policy = governance.createGovernancePolicy({
members: [
{ id: "release-bot", role: "developer" },
{ id: "security-review", role: "reviewer" }
]
});
if (!policy.authorize("release-bot", "protect").allowed) {
throw new Error("release actor is not allowed to protect this build");
}
Scoped automation tokens
Token descriptors validate known scopes, expiration, and revocation metadata without storing or printing the secret. Supported scopes cover protection, evidence read/export, project changes, and audit read access. The hosted service must still authenticate the token and enforce the result server-side.
Tamper-evident audit trail
Each local audit event includes its sequence and the SHA-256 hash of the previous event. verify() detects changed, removed, or reordered evidence before a release packet is handed to a reviewer. Store the resulting events in your governed log destination; this local chain is not a substitute for hosted immutable retention.
Enterprise identity and SCIM lifecycle
validateEnterpriseIdentityConfig() validates HTTPS OIDC issuer/client configuration or SAML SSO/entity/signing-certificate configuration, verified domains, enforcement mode, and default role. After the deployment adapter verifies the assertion signature, authenticateEnterprisePrincipal() enforces issuer, audience, expiry, nonce, verified email, and organization domain before mapping a role. The hosted /v1/scim/Users.ashx route supplies bearer-authenticated SCIM create, read, filter, replace/patch, and deactivate behavior with organization isolation; tokens are displayed once and stored only as SHA-256 hashes.
const directory = governance.createOrganizationDirectory({
organizationId: "customer-42"
});
const scim = governance.createScimService({
directory,
bearerToken: process.env.JSO_SCIM_TOKEN
});
// Mount through the HTTPS adapter used by your deployment:
const result = scim.handle({ method, url, headers, body });
Hosted enterprise boundary
Organization and SCIM directory persistence are implemented in the hosted product and administered at /dashboard/enterprise-governance.aspx. Production rollout still requires the database migration, backup/retention policy, IdP metadata exchange, and an OIDC/SAML callback that verifies provider signatures before creating a session. The presence of these controls is not a SOC 2 certification; certification requires an independent audit of operating controls.
Frequently asked questions
What does the governance module actually decide?
Who is allowed to do what, expressed as a policy your release tooling can consult before it acts. Roles cover owner, admin, developer, reviewer and viewer, and the permissions distinguish running a protection build, changing a project, exporting evidence, administering members and tokens, handling billing, and reviewing the audit trail. The module answers the authorisation question locally so your pipeline can refuse an action early, with a clear reason, rather than discovering the problem after a build.
Is the local policy check a security boundary?
No, and treating it as one is the mistake to avoid. It is there so tooling can fail fast and give a useful message. The hosted service still authenticates the caller and enforces the result on its own side, which is where the decision actually binds. The correct mental model is that the local check saves you a round trip and a confusing failure, while the server check is what makes the answer count.
How do the automation tokens handle secrets?
They avoid holding them. A token descriptor validates the scopes it claims, its expiry and its revocation metadata without storing or printing the secret itself, so a descriptor can travel through configuration and logs without becoming the thing you have to protect. Scopes cover protection runs, reading and exporting evidence, changing projects, and reading the audit trail, so a build agent can be given exactly the authority it needs and nothing beside it.
What makes the audit trail tamper-evident?
Each event records its sequence number and the hash of the event before it, so the log forms a chain rather than a list. Verifying it walks that chain and detects an entry that was changed, removed or reordered, because any of those breaks the link at the point it happened. That is a meaningfully stronger property than an append-only file, and it is what makes the trail usable as evidence rather than as a convenience.
What has to be in place before we enable single sign-on enforcement?
Two things, in order, and skipping either produces a confusing failure. Apply the governance table migration so the durable organization, token, directory-user and audit records have somewhere to live, then configure your identity provider trust settings. Turning on enforcement before the directory can store users is the usual cause of a lockout during rollout, so stage it on a non-production organization first.
What happens to our tokens if the plan lapses?
Creating new tokens and using the provisioning API require an active Enterprise plan, and a downgraded account keeps dashboard access specifically so existing tokens can still be disabled. That is a deliberate arrangement: losing the plan should not leave you unable to revoke credentials you have already issued. Plan a token inventory review as part of any downgrade rather than discovering scope you can no longer manage.