stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 16 Releases Wiki Activity

Add support for ГОСТ Р 34.10 digital signatures

Browse Source 
- Implemented the GostKeyValue class for handling public key parameters in ГОСТ Р 34.10 digital signatures.
- Created the GostSignedXml class to manage XML signatures using ГОСТ 34.10, including methods for computing and checking signatures.
- Developed the GostSignedXmlImpl class to encapsulate the signature computation logic and public key retrieval.
- Added specific key value classes for ГОСТ Р 34.10-2001, ГОСТ Р 34.10-2012/256, and ГОСТ Р 34.10-2012/512 to support different signature algorithms.
- Ensured compatibility with existing XML signature standards while integrating ГОСТ cryptography.
This commit is contained in:
master
2025-11-09 21:59:57 +02:00
parent 75c2bcafce
commit cef4cb2c5a
486 changed files with 32952 additions and 801 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/dev/31_AUTHORITY_PLUGIN_DEVELOPER_GUIDE.md
View File

@@ -178,6 +178,8 @@ _Source:_ `docs/assets/authority/authority-plugin-bootstrap-sequence.mmd`
- **Attribute pass-through.** `claims.extraAttributes` pairs the outgoing claim name with the LDAP attribute to read (first value wins). Only non-empty strings are written, which keeps audit/compliance data deterministic.
- **Mongo claims cache.** `claims.cache.enabled=true` wires the `MongoLdapClaimsCache` (default collection `ldap_claims_cache_<pluginName>`). Set `ttlSeconds` according to your directory freshness SLA and adjust `maxEntries` to cap disk usage; eviction is deterministic (oldest entries removed first). Offline Kit bundles now include the collection name requirements so replicas can pre-create capped collections.
- **Client provisioning audit mirror.** `clientProvisioning.auditMirror.enabled=true` persists every LDAP write into Mongo (`ldap_client_provisioning_<plugin>` by default) with `{operation, dn, tenant, project, secretHash}`. That mirror is shipped in Offline Kits so regulators can diff LDAP state even without directory access. When `clientProvisioning.enabled=false`, the registrar logs a warning and downgrades the capability at runtime.
- **Bootstrap seeding + audits.** `bootstrap.*` mirrors the provisioning contract for human operators: the plug-in writes `uid={username}` entries under `bootstrap.containerDn`, applies `staticAttributes` placeholders (`{username}`, `{displayName}`), and mirrors deterministic audit documents to Mongo (`ldap_bootstrap_<plugin>` by default) with hashed secrets (`AuthoritySecretHasher`). Bootstrap only lights up when (1) the manifest advertises the capability, (2) `bootstrap.enabled=true`, **and** (3) the plug-in proves the bind account can add/delete under the configured container. Otherwise the capability is silently downgraded and health checks surface `capabilities=bootstrapDisabled`.
- **Capability proofing.** On startup the plug-in performs a short-lived LDAP write probe (add→delete) inside each configured container. If either probe fails, the respective capability (`clientProvisioning`, `bootstrap`) is removed, `ClientProvisioning` stays `null`, and `CheckHealthAsync` reports `Degraded` until permissions are restored. This keeps read-only deployments safe while making it obvious when operators still need to grant write scope.
- **Sample manifest + binaries.** The curated manifest lives at `etc/authority.plugins/ldap.yaml` and demonstrates TLS, regex mappings, caching, and audit mirror options. Offline Kits copy both the manifest and the compiled plug-in into `plugins/authority/StellaOps.Authority.Plugin.Ldap/` so operators can drop them straight into air-gapped composer deployments.
## 7. Configuration & Secrets