Kimura SCM

Appearance

Connections, Security, Certificates, And OIDC ​

Kimura SCM is a client/server system: clients connect to the Kimura server to authenticate, read state, and perform operations. Because those operations are authoritative (they affect history, locks, access checks, and visibility), connections and identity are core concepts.

This document explains:

  • what “connecting” means in Kimura SCM,
  • how certificates are used to secure connections and verify identity,
  • and how OIDC (SSO) can be used instead of (or alongside) passwords.

Connection Endpoints (The Kimura Server vs. File Servers) ​

When you connect as a user, you connect to the Kimura server. The Kimura server:

  • authenticates you,
  • validates permissions and policies,
  • records history and operations,
  • and exposes coordination/visibility data (locks, active operations, etc.).

For transferring file content at scale, Kimura can also use file servers. File servers still authenticate and follow server rules, but they focus on file distribution and storage rather than being the source of truth for history.

Client Access To File Servers Is Federated By The Kimura Server ​

When your client needs to upload or download file content, it connects to a file server endpoint. The authentication and authorization for those transfers is federated by the Kimura server:

  • The Kimura server authenticates the user and validates permissions.
  • The server then allows file transfers by issuing/authorizing the transfer context used with the file server.

This is part of the Kimura server’s role as the coordination and trust authority: it coordinates what is being transferred (and by whom), and it establishes trust between the client and the file server so file content can be exchanged without turning every file server into a separate login and policy system.

In other words, you don’t manage separate “file server accounts” for each user: file transfer access is granted as part of the normal server-side authentication and policy checks.

Transport Security (Encrypting The Connection) ​

Kimura SCM uses SSL (TLS) to secure network connections between the client and the server.

In an SSL/TLS connection:

  • the connection is encrypted in transit,
  • the server presents a server certificate so the client can verify it is talking to the expected server (and not a man-in-the-middle),
  • and the client can optionally present a client certificate (mutual TLS) when your environment requires it.

Kimura exposes configuration around certificate verification (how strict the client should be when validating the server certificate) and around client certificates (whether the user must present a trusted certificate and/or match a specific thumbprint).

Server Certificate Verification (Trusting The Server) ​

When connecting, the client can be configured to accept the server’s certificate more loosely, or to require a certificate that is trusted by the machine’s trust store.

Why this matters:

  • If the server certificate is not validated, an attacker on the network could impersonate the server.
  • If it is validated (trusted CA / trusted chain), the client gains stronger assurance it is talking to the real server.

If your organization uses internal PKI, an administrator typically distributes the internal CA so that the server certificate is trusted on client machines.

Client Certificates (Proving Who You Are) ​

In addition to (or instead of) passwords, Kimura can require users to present a client certificate when logging in.

This is typically controlled by user policy (configured by administrators), for example:

  • a user must present a trusted certificate, and/or
  • the certificate must match an expected thumbprint.

The server validates certificate trust (chain) and thumbprint requirements during login. This is useful when you want a “something you have” factor, or when connecting from controlled machines.

OIDC / SSO (OpenID Connect) ​

Kimura can be configured to use OIDC so users can authenticate via an identity provider (IdP) such as an enterprise SSO.

Conceptually, the flow is:

  1. The client asks to log in as a specific Kimura user.
  2. The server responds with an OIDC challenge (authority/metadata, client id, scopes, redirect URI, and a nonce).
  3. The client opens the IdP login flow (usually in a browser) and receives an ID token.
  4. The client sends the ID token back to the Kimura server as the challenge response.
  5. The Kimura server validates the token (issuer, signature, audience, timestamps, nonce) and checks that a configured user-claim matches the requested Kimura username.

What this achieves:

  • Kimura does not need to store or validate the user’s IdP password.
  • Your organization can use centralized SSO policies (MFA, conditional access, etc.).
  • Kimura still maps the authenticated identity to a Kimura user (so groups and permissions continue to apply).

Security And Permissions Still Apply After Login ​

Authentication answers “who are you?”. Authorization answers “what can you do?”.

Even if you successfully authenticate (password/certificate/OIDC), operations are still restricted by:

  • your Kimura user and group memberships,
  • repository/folder/file access rules,
  • and any additional server-side policies.