Conversation
Four pins moved, resolved from origin with git ls-remote rather than copied from a PR body: actions/checkout v7.0.0 to v7.0.1 (3d3c42e5), actions/upload-artifact v4.6.2 to v7.0.1 (043fb46d), golangci/golangci-lint-action to ba0d7d2e and aquasecurity/trivy-action to ed142fd0. The last two are NOT version changes - both are annotated tags, and the pin was the tag object rather than the commit it points at; same v9.3.0 and v0.36.0 as before. Every other pinned action was already on its latest release and on the right object. Signed-off-by: GatisB <l22exc@gmail.com>
The rest of the pinned actions move to their current releases: anchore/sbom-action v0.24.0 to v0.24.2, docker/build-push-action v6.19.2 to v7.3.0, docker/metadata-action v5.10.0 to v6.2.0, docker/setup-buildx-action to v4.3.0 and docker/login-action to v4.6.0. The last two had been pinned at TWO different versions across the workflows (buildx v3.12.0 and v4.2.0; login v3.7.0 and v4.4.0); both now carry one version everywhere. Every SHA resolved from origin, using the peeled commit where the tag is annotated. Also pinned: the Trivy SCANNER, version v0.74.0 - the action was running whatever its own default was, which is v0.70.0 and lags the scanner's releases. Every touched file was verified by parsing the YAML and asserting the trivy step still carries its image-ref. Signed-off-by: GatisB <l22exc@gmail.com>
OIDC_UPSTREAM_COUNTRY is removed: the field, the override onto the connector, and the README row documenting it. It was never bound to its environment variable, so setting the documented variable did nothing and said nothing. Binding it was the obvious repair and the wrong one. The setting supplies one country for every person who logs in through a provider, so a user base holding codes from more than one national register would have had some of them filed under another register's country - a valid-looking canonical key belonging to the wrong person, with no error to notice it by. That is the guess the rest of the identity path refuses to make: the card login takes the country from the certificate's own subject attribute, a fact about the person holding the card, and the store refuses a code it cannot canonicalise rather than storing one under an assumption. The connector's Country field stays, set by a provider profile in code, where it is a statement about that provider's claim format rather than about a deployment's users. eParaksts is unaffected - its profile sets LV for itself and its claims carry the country anyway. A provider that sends bare codes is now answered by a claim mapping at that provider, where the identity type can be stated alongside the country instead of being assumed. Adds the test the defect was invisible to: every upstream configuration key, derived from the struct's own mapstructure tags rather than a hand-kept list, must be reachable from its environment variable. Falsified - re-adding the unbound field makes it fail, naming the key and the fix. Signed-off-by: GatisB <l22exc@gmail.com>
…d a person can be registered before their first login At token issue the register is asked by sub:<person id> — the session's subject, equal to the token's sub — never by the identity code; a service account is still asked for by its client id. No token changes shape and no new claim is minted: every consumer derives the key from sub the same way. The refusal 'the login carries no identity code' is gone with it. POST /identity/persons (identity:admin) creates the person row in the identity store with the canonical identity code and the name, no credential — a record, not an account — idempotent on the code, 201 created / 200 known / 422 err:identity:invalid, recorded as a GDPR identity write with the administrator as actor. The store's procedure refusals are typed so a validation is answered as a refusal, never as an outage. Signed-off-by: GatisB <l22exc@gmail.com>
…ogin is admitted into the tenant that attached it, and two upstream families refuse to start Upstream connector: discovery captures the provider's issuer and jwks_uri; when a key set is known, every login must carry an id_token that verifies - signed with a published key (RS256, PS256, ES256 only), iss, aud, exp and iat with the configured leeway, the flow's nonce (sent with every authorize request, step-up included), and a subject equal to userinfo's. A missing or failing id_token refuses the login (401, audited with the reason, no claim value). The id_token's claims win over userinfo's where both carry one; its acrs join the amr list for the assurance vocabulary. Without a key set the login behaves exactly as before (the eParaksts profile is pinned userinfo-only). Two claim maps: OIDC_UPSTREAM_CLAIM_DIRECTORY_ID (default sub; oid for Microsoft Entra ID) names the durable identifier the credential is stored under, OIDC_UPSTREAM_CLAIM_ACCOUNT_STATUS with OIDC_UPSTREAM_ACCOUNT_STATUS_GUEST tells a member of the provider's directory from a guest. OIDC_UPSTREAM_ISSUER and OIDC_UPSTREAM_JWKS_URL set the two facts for a provider configured by explicit endpoints. Token issue: a person who came through the upstream provider and holds no membership is offered to the membership register's admission door (POST /api/v1/directory-admissions, the membership:claim scope this service already holds); admitted, they are resolved again and the token is minted for the tenant that attached the issuer with an empty scope set. A guest in the directory is not offered; an issuer nobody attached admits nobody; a person already holding a membership is never offered. The door unreachable fails the issue closed. The session carries the issuer it came through and the guest flag. Configuration: setting both OIDC_UPSTREAM_* and EPARAKSTS_* now refuses to start instead of picking the generic one silently. Tests: the connector against a stand-in that publishes a real RSA key set (verification, the merge, the guest flag, eleven refusals incl. alg none, HMAC, a foreign key, an unknown kid, a subject mismatch; userinfo-only without a key set; startup refused for a key set without an issuer; the eParaksts profile pinned), the admission seam (admitted then resolved; nobody attached; guest not offered; member not offered again; failure closed), the one-upstream rule. Gates: gofmt, vet, build, go test, golangci-lint 0 issues, govulncheck 0. Two mutants each killed by the test that owns the rule. Signed-off-by: GatisB <l22exc@gmail.com>
…n is the provider profile's property The generic connector signs out locally by default: the service's own session ends and the browser returns to the registered redirect_uri, and the session the provider keeps in the browser — for a directory provider, the person's whole estate — is left alone. A deployment that wants the front-channel hop for a generic provider lists the methods in OIDC_UPSTREAM_METHODS_FEDERATED. The eParaksts profile is unchanged: it lists its own federated methods, and its short-lived SSO session on a shared device is the reason the hop exists. Tests pin both halves at the connector and at the logout route; the test application builder yields to a generic connector put in the environment first. Signed-off-by: GatisB <l22exc@gmail.com>
Signed-off-by: GatisB <l22exc@gmail.com>
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.