Evaluate TSEC in an afternoon

1 Install the chart ~15 min

Generate a master key first. The chart will not render without one:

openssl rand -base64 32

helm upgrade --install tsec oci://ghcr.io/tricasollc/charts/tsec \
  --version 26.10.0 \
  --namespace tsec --create-namespace \
  --set secret.masterKey="$(openssl rand -base64 32)" \
  --set secret.databasePassword="$(openssl rand -base64 24)"

That brings up the runtime, the builder and Postgres. The OIDC server (tsecAuth), the login front-end (tsecIdp), the SDK harness and the mock user store all default to off — you turn on only what you are assessing. We enable two of them in step 3.

One thing worth noticing while it comes up: that master key is not optional and not defaulted. The chart refuses to render without it and rejects the old CHANGE_ME_… placeholder outright, and every service independently refuses to start on a known, blank or short key. One secret signs admin tokens and identity assertions and encrypts the secret store, so a guessable value means no security at all — we would rather fail your install than hand you a facade.

2 Run your first expedition ~20 min

Port-forward the builder and sign in with the bootstrap admin. Open the seeded expedition — a START → SCREEN → SCREEN → COMPLETE login — and run it with the in-app Try it harness.

Then change something: add a DECISION node that branches on a field, and publish. Publishing creates an immutable, content-hashed version; the previous one stays exactly where it was.

The thing to understand here is the division of labour. The runtime decides what happens next and returns data; your application decides what it looks like. There are no TSEC screens shipped into your UI. Expressions are scoped — session, field, nodes.<id>.output, response, device, risk, env — so what a node can read is bounded and legible.

3 Put a real OIDC client in front of it ~30 min

Enable the authorization server and the login front-end, and the mock user store so you have somebody to sign in as:

helm upgrade tsec oci://ghcr.io/tricasollc/charts/tsec \
  --version 26.10.0 --namespace tsec --reuse-values \
  --set tsecAuth.enabled=true \
  --set tsecIdp.enabled=true \
  --set mockUsers.enabled=true

mockUsers is a test stand-in, not a product. In a real deployment your directory stays where it is and the flow reaches it with an API-call module.

Check discovery, then register a client and drive a normal authorization-code login with PKCE:

curl -s https://<your-auth-host>/.well-known/openid-configuration | jq .

You will get the endpoints you expect — /oauth2/authorize, /oauth2/token, /oauth2/jwks, /userinfo — because this is Spring Authorization Server underneath, not a homegrown implementation. PKCE with S256 is required, not optional. The id_token is signed RS256 and verifiable against the published JWKS.

The point of this step: the login behind that standards-compliant flow is the expedition from step 2. Change the flow, and every downstream application's login changes, with no redeploy of anything.

4 Bind a device and read the decision ~30 min

This is the step that tells you whether the product is real. Add device intelligence to the login flow: a device assessment node, a DECISION that routes on the result, a TOTP step on the risky branch, and a bind node on success.

Then sign in twice from the same browser.

The first sign-in should challenge you for a second factor and, on success, bind the device to the account. The second should recognise the device and skip the challenge. That is adaptive step-up doing the only thing anyone actually wants from it: less friction for the people you already recognise, without lowering the bar for anyone else.

Now open the run log for both sessions. You should be able to see which signals matched, what each contributed, which rule fired and what the resulting decision was. Compare the two runs side by side. If you cannot reconstruct why the second login skipped the factor, the explainability claim on our homepage is not true and you should hold us to it.

5 Try to break it ~45 min

Most vendor evaluation guides stop before this part. Here is what we expect you to try and what should happen. If any of these behaves differently in your install, that is a finding and we want it.

Forge a weak master key

Install with --set secret.masterKey=CHANGE_ME_TO_A_32_BYTE_BASE64_KEY, or a short string, or none at all. Expected: the chart refuses to render, and if you bypass that, every service refuses to start with an explicit error. Overriding it requires setting an opt-in flag by hand, which is deliberately an audit trail rather than a default.

Tamper with a continuation token

Capture the continuation token mid-flow, flip a byte, and resubmit. Then try replaying a valid one after the expedition version has been republished. Expected: rejection in both cases — the token is HMAC-protected, and a revision guard stops a session continuing against a definition that has changed underneath it. Also check the idle and lifetime timeouts; they default to 15 minutes and 1 hour.

Point an outbound call at your metadata service

Author an API-call node targeting http://169.254.169.254/latest/meta-data/, then try 127.0.0.1, then an internal RFC 1918 address. Expected: blocked. Loopback, link-local, cloud-metadata and private ranges are refused by default; reaching an internal host requires an explicit allowlist entry. A Kubernetes NetworkPolicy is available as a second layer, and we would rather you ran it.

Replay a signed agent request

If you are assessing the automated-client detection, capture a validly signed Web Bot Auth request and replay it. Expected: rejected by nonce replay protection. Then try spoofing a known agent's user-agent string without a signature — expected: it classifies as a hint, not as proof, and the builder told you that when you wired the node.

Verify the audit chain, then break it on purpose

Publish an expedition and change a secret, then run the chain verifier against the database. Now go into Postgres and edit one audit_event row — change an actor, a timestamp, anything — and run it again. Expected: exit 0 the first time, and the second time a non-zero exit naming the first sequence number that no longer validates. Deleting a row should be caught too. The verifier reads the chain directly and does not go through the application, which is the entire point: it has to be trustworthy when the app, or whoever operates it, is not.

Try to read a secret back out

Store an API credential, then attempt to retrieve it through the builder or its API. Expected: you cannot. The secret store is write-only to the console and AES-256-GCM encrypted at rest; flows reference secrets without ever returning them.

Brute force things

Hammer the admin login, then a TOTP verification. Expected: admin login locks out with a Retry-After, and a locked account is detected before the password is checked, so it is not a timing oracle for whether a username exists. TOTP has its own configurable attempt and lockout policy with admin unlock.