Password & Secrets Management

Audience: MSP and organization administrators connecting a password manager, and technicians using credentials from a ticket. Scope: 1Password (the one provider that ships), the credential inventory, vault mapping, linking, reveals, and the audit trail.

---

What it is

Solidlio links credentials that live in your password manager to the assets, tickets, runbooks and sites they belong to, and brokers an audited reveal when a technician needs one.

Solidlio never stores a credential value. It stores a reference — vault id, item id, title, category, tags, when the item last changed — and nothing else. If the password manager is unreachable, Solidlio cannot reveal; that is the deliberate cost of holding nothing.

---

Concepts

---

Before you connect: three 1Password facts

Read these before creating the service account. Two of them cannot be fixed afterwards.

1. A service account’s vault access is fixed when it is created. You cannot widen it later. Adding a client vault six months from now means creating a new service account and reconnecting. Select every vault you expect to need at creation time.

2. A service account cannot see Personal, Private, Employee or the default Shared vault. Client credentials must live in purpose-made shared vaults. A token scoped only to personal vaults authenticates perfectly and then lists nothing — Solidlio refuses that setup with an explanation rather than storing it.

3. The token is shown once. Save it in 1Password before leaving the creation screen.

Create it under Developer → Directory on 1Password.com, or:

op service-account create "Solidlio" \
  --vault "Acme Corp:read_items" \
  --vault "Northgate Ltd:read_items"

read_items is sufficient. Solidlio does not write to your password manager (see §9).

---

Connecting

MSP portal: Integrations → 1Password. Organization portal: Integrations → 1Password.

Solidlio tests the token against 1Password before storing anything. If it can authenticate but sees no shared vault, the connection is refused with the explanation from §3 — a connector that reports “connected” and then fails on every call is worse than one that refuses.

On success the metadata sync is scheduled (default every 6 hours) and runs once immediately.

---

Choosing a mode

Link-only gives strictly better attribution in your password manager’s own logs and needs a weaker grant. Reveal-in-Solidlio gives a better workflow and a richer Solidlio-side record. You can change the mode at any time under Settings; it does not require reconnecting.

---

Mapping vaults to clients

Vault placement identifies the customer; connection ownership controls access.

On an MSP install the connection belongs to the MSP’s own organization while the credentials inside belong to your clients. Solidlio will not guess: a vault with no mapping imports nothing, and no credential is ever filed under the MSP because its connector happens to live there.

Integrations → 1Password → Vaults. Each row offers:

• Not mapped — the default. Nothing imports.
• Ignore this vault — record the decision so the row stops looking unfinished.
• A client organization — items in that vault import under that client.

Personal vaults are listed but not selectable. Mapping requests a metadata sync. Organization-owned connections default newly discovered vaults to their own organization; MSP connections require explicit placement unless an administrator selects a default. Unmapping or ignoring a vault immediately archives its references. A vault with existing credential history cannot be reassigned to a different customer: use a separate vault.

An MSP-owned connection stays accessible to that MSP when its records are linked to customer assets. Customer portal users and another servicing MSP do not gain access. An organization-owned connection is available to its authorized organization administrators and servicing MSP staff, subject to visibility and reveal policy. Managing the customer’s connection settings remains the customer’s administrative responsibility. A 1Password deep link always requires the visitor’s own access to the linked account and vault. Solidlio’s service-account read permissions do not grant that personal access.

---

Using credentials

Where they appear

Revealing

1. Click Reveal and provide the required ticket or reason.
2. Use Load available fields if needed; this is an audited provider read with the same policy checks as a reveal. Select the field and click Reveal.
3. The value appears with a countdown and a Copy button. It clears on the timer, on close, on unmount, and when you switch browser tabs.

Revealing from a ticket attaches that ticket to the audit record automatically. That is the whole reason the panel is on the ticket and not only on the asset.

What is recorded, every time: who you are (email and role, denormalized so the evidence survives your account being deleted), which field, the reason, the ticket, your IP, the time, and the outcome — including DENIED when policy refused you and PROVIDER_ERROR when 1Password failed. The initial record is PENDING and is saved before 1Password is contacted. A completed read changes the outcome once. A crash can leave a pending attempt; it is not reported as a success. An audit-store or rate-limiter outage prevents brokered reads.

Use Link a credential on an asset, ticket, knowledge article or location. Only records placed under the same organization can be linked. Access history shows the credential’s events and linked records, with an Unlink control. Copy requests and provider launch requests are recorded, but those records do not claim that the browser clipboard succeeded or that 1Password authenticated the visitor.

---

Access policy

Integrations → 1Password → Settings.

Role floors. MSP portal: MSP technician. Organization portal: organization administrator. They are configured independently on purpose — MSP technician ranks above organization administrator in Solidlio’s hierarchy, so a single floor set to the technician role would lock every org admin out of their own organization’s credentials.

The customer portal has no access at all, at any role. A credential inventory names every privileged account on every asset, and that list is sensitive even with every value withheld.

Step-up. SSH keys, certificates, and any item tagged break-glass require a successful sign-in within the last 15 minutes. “Step-up” here means a fresh authentication read from Solidlio’s login history — not a separate re-authentication prompt. A technician who signed in twenty minutes ago is asked to sign in again; one who signed in five minutes ago is not.

Per-item overrides. requiresReason and requiresTicket can be set on an individual credential and outrank the connection’s setting in both directions — so one break-glass account can demand a ticket on a connection that does not, and one routine credential can be exempted without loosening the tenant.

---

What this integration does NOT do

Stated plainly, because the boundary is the product:

• It does not write to your password manager. v1 cannot create, edit, rotate, share or delete items, and cannot create or delete vaults. The connection needs only read_items. Write-back is deliberately out of scope: read + link + reveal + audit is a complete, sellable feature, and a bug in a write path damages the customer’s password manager rather than Solidlio.
• The only non-secret field it ever copies out of an item is the username, and only from an item it already holds because someone revealed a field from it.
• It does not work when 1Password is down. The deep link still opens the item in the technician’s own 1Password app.
• It does not sync anything on a schedule except metadata. No scheduled job in Solidlio ever reads a credential value.

---

Legacy “unmanaged” credentials

Those rows still hold a name and a login somebody typed in, so they are kept and shown in an Unmanaged section, honestly labelled, with no reveal offered. Move them into your password manager and link them to make them usable. Nothing is deleted automatically.

---

Out-of-band detection (Events Reporting)

With an Events Reporting token configured, Solidlio walks 1Password’s own audit stream nightly and compares it with its own.

Configure the service account actor UUID in Settings. Obtain it from the 1Password Business service account/activity report and verify it belongs to this connection. Solidlio does not infer identity from matching timestamps. Previously inferred identities are ignored until an administrator confirms one. Correlation requires a real provider fetch from that actor; ordinary detail views never match. Time correlation is supporting evidence, not an exact provider request identifier.

For provider audit coverage, create an Events Reporting token in the same Business account with all three scopes: item usages, audit events and sign-in attempts. Account audit and sign-in evidence, including events for unmapped items, is available in the central audit trail under the connection owner. Missing scopes and ingestion failures appear in reconciliation results and cause the scheduled job to report failure.

Cursors are durable: a failed page leaves the last good position in place, so a transient outage does not become a permanent gap in the record.

---

Sync behaviour and rate limits

1Password does not publish service-account rate limits and throttles hard. So:

• The sync pulls metadata only — one call per mapped vault, not one per item.
• Default cadence is 6 hours. It is safe to lower, but there is little to gain.
• A throttle is reported as Rate limited, not Failed, with “credentials are fine — the next scheduled run will resume”. Reporting it as a failure would send you to re-enter a service-account token you cannot re-enter.
• Items that disappear from a vault are archived, never deleted: their access history has to outlive them.
• Auto-linking suggests, and never links. A wrong auto-link puts one client’s credential on another client’s asset page.

---

Troubleshooting

---

Reference

Data model: SecretItem (the reference), SecretLink (what it is attached to), SecretAccessEvent (the trail). Every reveal also writes an AuditLog row so it appears in the platform-wide compliance viewer.

Certificate private keys (write-back)

The Certificates section is the one place Solidlio writes into a password manager. With Allow certificate key writes turned on for a 1Password connection (off by default; the service account needs write access to the vault), Generate a CSR creates the key pair in memory and stores the private key straight in a vault mapped to the organization as a Secure Note with a concealed private key field — nobody sees it — and a PKCS#12 import can do the same. Exports that need the key (PFX, PEM bundles) go through the ordinary reveal policy and are recorded as EXPORT access events on the item. Nothing about the rule above changes: the value is never stored by Solidlio.

Audit retention and deployment

Credential event identity, reason, tenant and timestamp fields are protected against ordinary updates and deletes at the database layer. Pending outcomes and one-time provider references are the permitted completion updates. Disconnect removes stored tokens and disables reads while retaining references, event checkpoints, links and history. Hard deletion of a referenced credential or its parent is refused until the organization’s approved retention process explicitly purges the evidence.

The general audit-retention job handles AuditLog; it does not currently purge SecretAccessEvent. Credential events remain retained. Set and document the required retention period, legal holds, access reviews and immutable external evidence storage with your compliance owner. Database administrators can override database controls; these changes do not certify SOC 2 compliance or supply an independent archive.

Apply migration 20260910140000_onepassword_access_audit before deploying the updated services and web client together. See the review and verification record.