{"owner":"apereo","repo":"cas","hasSkills":true,"totalSkillsCount":32,"totalTokensCount":24300,"categories":["anthropic-skill","root-instruction","claude-rule","copilot-instructions","cursor-rule"],"hasMcp":true,"mcpConfig":{"mcpServers":{"cas":{"command":"npx","args":["-y","@modelcontextprotocol/server-cas"]}}},"found":[".claude/skills/cas-groovy-scripting/SKILL.md",".claude/skills/cas-handoff/SKILL.md",".claude/skills/cas-build-ci/SKILL.md",".claude/skills/cas-google-authenticator/SKILL.md",".claude/skills/cas-attribute-consent/SKILL.md",".claude/skills/cas-actuators/SKILL.md",".claude/skills/cas-docs-site/SKILL.md",".claude/skills/cas-import-pr/SKILL.md",".claude/skills/cas-interrupt-notifications/SKILL.md",".claude/skills/cas-ldap/SKILL.md",".claude/skills/cas-heimdall-authzen/SKILL.md",".claude/skills/cas-mcp-server/SKILL.md",".claude/skills/cas-oauth-oidc-authentication/SKILL.md",".claude/skills/cas-oauth-oidc/SKILL.md",".claude/skills/cas-oid4vc/SKILL.md",".claude/skills/cas-passwordless-webauthn/SKILL.md",".claude/skills/cas-protocol/SKILL.md",".claude/skills/cas-puppeteer-scenarios/SKILL.md",".claude/skills/cas-saml/SKILL.md",".claude/skills/cas-sandbox-verification/SKILL.md",".claude/skills/cas-service-registries/SKILL.md",".claude/skills/cas-session-stores/SKILL.md",".claude/skills/cas-startup-performance/SKILL.md",".claude/skills/cas-storage-backends/SKILL.md",".claude/skills/cas-testing/SKILL.md",".claude/skills/cas-ticket-registries/SKILL.md",".claude/skills/cas-ui/SKILL.md",".claude/skills/cas-web-security/SKILL.md","AGENTS.md","CLAUDE.md",".github/copilot-instructions.md",".cursorrules (testrail-test-case-cursorrules-prompt-file.mdc)"],"skills":{".claude/skills/cas-groovy-scripting/SKILL.md":"---\nname: cas-groovy-scripting\ndescription: \"Review and change Groovy scripting support (core/cas-server-core-scripting): ScriptResourceCacheManager, CompiledGroovyScript, inline vs external scripts, compiling off the request path, script security. Use when touching Groovy scripts or any module that runs them.\"\n---\n\n# Groovy and scripting\n\n## Groovy and scripting\n\n- Start at `core/cas-server-core-scripting`; roughly fifty modules delegate to the same five classes, so\n changes there are changes to authentication, attribute release, MFA, AUP, OIDC, SAML and themes at once.\n- `ScriptResourceCacheManager` is a singleton whose `close()` clears the entire cache — it must never be\n used in a try-with-resources block.\n- `CompiledGroovyScript.of` decides how a script runs: a stateless script (only final fields holding immutable\n values) gets a fresh instance per call and runs in parallel; a stateful one keeps a shared instance serialized\n on a blocking lock, on purpose, so its fields stay consistent. Do not report that lock as a bottleneck. Review every script-backed\n decision for what a `null` result means and prefer fail-closed defaults at security boundaries — MFA\n triggers and AUP read `null` as \"skip\". Never guard script execution with a timed `tryLock`; a timeout\n that returns `null` is indistinguishable from a script that declined.\n- Do not compile scripts on a request path (`fromScript`/`fromResource` per call). Go through\n `resolveScriptableResource`, or hold the compiled script in a transient field, and remember `fromResource`\n also starts a file-watcher thread that nothing closes. The cache manager comes from\n `ApplicationContextProvider` and is absent outside Spring, so always fall back to the factory instead of\n throwing, or you will break components and tests that are constructed directly.\n- Inline (`groovy { ... }`) and external (`file:`/`classpath:`) scripts behave differently: only external\n scripts honour `failOnError` and support reload, and only inline scripts support bindings (the\n `setBinding` interface default is a no-op). Inline scripts swallow `GroovyRuntimeException`. Test both\n forms, and cover bindings with concurrent and pooled-thread tests — `GroovyShellScriptTests.BindingTests`\n is the pattern.\n- Treat compiling a Groovy script as running it: AST transformations execute inside the compiler. Script\n text that comes from anywhere other than deployment configuration must be parsed\n (`ScriptingUtils.validateGroovyScript`), never compiled.\n- Puppeteer coverage lives in the 18 `ci/tests/puppeteer/scenarios/*groovy*` scenarios\n (`service-access-strategy-groovy`, `surrogate-login-groovy`, `mfa-provider-selection-trigger-groovy`,\n `interrupt-afterauthn-groovy`, `webflow-groovy-action`, …). None of them exercise concurrency, script\n errors, or cache expiry, so a change in this area needs new coverage rather than a rerun.\n",".claude/skills/cas-handoff/SKILL.md":"---\nname: cas-handoff\ndescription: \"Finish and hand off a change in the CAS repository: Checkstyle on changed Java files, no stale .git/index.lock, release-notes and puppeteer cross-checks, and the ready-to-use commit message. Use at the end of every task that changed files in cas-server, before reporting the work as done.\"\n---\n\n# Handing off CAS work\n\nRun these steps, in order, before reporting the work as done. The rules behind them follow.\n\n1. Compile what changed, main and test sources, with Error Prone, each changed module on its own class path so a\n missing test dependency shows (see Conventions in AGENTS.md, the `cas-testing` skill and, in a sandbox without\n Gradle, the `cas-sandbox-verification` skill).\n2. Run Checkstyle on every changed Java file (rule below), and fix overloads, imports and file length it reports.\n3. Run `git --no-optional-locks diff --check`.\n4. Cross-check the puppeteer scenarios that cover the change and update them (`cas-puppeteer-scenarios` skill).\n5. Add the release-notes entry when the work calls for one (security notes: see \"Test, concurrency, and hand-off\n expectations\" in AGENTS.md; release-notes format: `cas-docs-site` skill).\n6. Record new, durable lessons in AGENTS.md or in the matching skill under `.claude/skills/`.\n7. Check `ls .git/*.lock` and clear what is left.\n8. End with the commit message (rule below). Say clearly what was not run.\n\n## Test, concurrency, and hand-off expectations\n\n- When the work is done, end the hand-off with a ready-to-use commit message covering only the uncommitted changes\n (`git --no-optional-locks status`): a conventional subject (`fix:`, `feat:`, ... as in `git log`) and a short body.\n The maintainer commits; do not commit yourself.\n\n## Environment limits\n\n- Leave no `.git/index.lock` behind. `git status` and `git diff` take that lock to refresh the index, and in a remote environment that cannot delete files the lock survives the command and blocks every subsequent git operation the maintainer runs. Read git state with `git --no-optional-locks status` / `git --no-optional-locks diff`, which never takes it, and before finishing check `ls .git/*.lock` and clear anything left. If deletion is refused, request it rather than leaving the repository wedged.\n- Maintainer: run Checkstyle on every changed Java file before handing work off, even without Gradle. Use the version in\n `gradle/libs.versions.toml` (`checkstyle--all.jar` from the Checkstyle GitHub releases; 14.x needs Java 21+) as\n `java -Dcheckstyle.suppressions.file=style/checkstyle-suppressions.xml -Dcheckstyle.importcontrol.file=style/import-control.xml\n -jar checkstyle.jar -c style/checkstyle-rules.xml `. When the workspace JDK is older, tar the files and `style/` into\n `build/` (deletable without asking) and run it where Java 21 is available.\n",".claude/skills/cas-build-ci/SKILL.md":"---\nname: cas-build-ci\ndescription: \"Gradle build settings (configuration cache, Isolated Projects, build cache, test-category discovery) and the GitHub Actions workflows (tests.yml coverage job, setup-gradle caching, daemon reuse, CodeQL). Use when changing build logic under buildSrc or gradle/, the root Gradle settings, or anything under .github/workflows or ci/.\"\n---\n\n# CAS build and CI workflows\n\n## Workflows that matter here\n\n- Gradle 9.8.0 enables build caching, the configuration cache, parallel execution and Isolated Projects here.\n Isolated Projects configures every project on a cache miss and ignores configuration on demand. Compare representative\n scoped commands before changing either setting. User-home `gradle.properties` overrides the repository's JVM settings.\n- Test category discovery runs inside `TestCategoryTagsValueSource`: only its sorted tag list is a configuration input.\n Implementation edits retain the cached graph; adding/removing categories invalidates it. Do not move source reads back\n into the convention script or restore the old `.gradle/cas-test-tags` fingerprint cache.\n- An IDE `JetGradlePlugin` error about `setExcludedTaskNames` comes from the IDE integration, not category discovery.\n Use `--no-isolated-projects` for the affected IDE invocation until that integration supports Isolated Projects; keep\n configuration caching enabled and do not disable Isolated Projects globally to hide an IDE-only violation.\n\n## Practical boundaries\n\n- Unit-test matrix jobs (`tests.yml`) record JaCoCo data only (`testcas.sh --with-coverage` only turns on the agent) and upload the `.exec` files; the single `coverage` job builds `jacocoRootReport` and does every Sonar/Codecov/Coveralls/Codacy upload. Do not move `jacocoRootReport` or `sonar` back into the matrix: the root report compiles all ~430 projects and Sonar re-analyses the whole code base, which is what made each category job 17 minutes instead of 7.\n- Every `gradle/actions/setup-gradle` step sets `gradle-home-cache-excludes: caches/build-cache-1` and\n `cache-encryption-key: ${{ secrets.GRADLE_ENCRYPTION_KEY }}`. Preserve both: the local build cache duplicates Develocity\n outputs, and the encryption key enables saving/restoring the project configuration cache. Fork PRs without this secret\n can still build, but cannot restore the encrypted configuration cache. Do not layer `setup-java` or GraalVM Gradle\n caching over `setup-gradle` in the same job.\n- CI permits Gradle daemon reuse within a job; `ci/init-build.sh` must not append a disabling user-home property.\n Release, documentation and scenario scripts preserve daemon reuse across their Gradle invocations. CodeQL keeps\n `--no-daemon` for compiler tracing. Test categories and Puppeteer scenarios are fetched once per discovery\n job; print the captured result and split scenario JSON with `jq`, preserving the existing matrix boundaries.\n- The CodeQL job (`analysis.yml`) applies `--no-build-cache --rerun-tasks` after its shared build options so traced\n compilation actually runs. The current `settings.gradle` has no CodeQL-specific `JavaCompile` cache guard. Preserve\n these workflow flags: CodeQL only extracts compilations it observes, so restored or up-to-date outputs empty the scan.\n",".claude/skills/cas-google-authenticator/SKILL.md":"---\nname: cas-google-authenticator\ndescription: \"Review and change Google Authenticator (GAuth) MFA credential repositories across backends (JPA, Redis, Mongo, DynamoDB, LDAP, JSON, REST, in-memory): owner-scoped deletes, encoding, counts, verification flags, the Redis index, crypto. Use when touching support/cas-server-support-gauth*.\"\n---\n\n# Google Authenticator MFA repositories\n\n## Google Authenticator credential repositories (all backends)\n\n- Review every backend against the same contract, with crypto on: `cas.authn.mfa.gauth.crypto.enabled` defaults to `true`, but every puppeteer scenario and the repository tests turn it off, so undecoded returns and double encryption never show up in CI.\n- A device delete must be scoped to its owner. WebAuthn, YubiKey and Duo device managers delete by username and id; `OneTimeTokenCredentialDeviceManager` and `GoogleAuthenticatorDeleteAccountAction` delete by id alone, and ids are guessable (JPA sequence; `currentTimeMillis` before 42bcde1).\n- `BaseOneTimeTokenCredentialRepository.encode()` mutates its argument. Never pass an object you will keep or save again; JPA `get(id)` and InMemory `get(id)` return stored, undecoded instances, and updating them double-encrypts.\n- `count()` means devices in Redis, JPA, Mongo and DynamoDB, but users in InMemory, JSON and LDAP; check which a caller assumes.\n- A repository read that fails must not look like \"no devices\": `OneTimeTokenAccountCheckRegistrationAction` sends empty or null results to enrollment (REST returns null, JSON returns empty on errors).\n- When testing deletes or updates, store devices for two users and two devices per user, and assert the others survive; single-user tests hid the DynamoDB `GE` filter and the LDAP update bug.\n- To make a range-filter bug visible in a DynamoDB delete test, pick keys that a wrong comparison would sweep up: the kept user's name sorts after the deleted one (\"z…\" vs \"a…\"), and the kept device ids are larger than the deleted id. Random UUIDs alone pass by luck half the time.\n- DynamoDB tables keyed by `id` should delete with `DeleteItem` on that key, not a scan followed by deletes.\n- Webflow actions and device managers that take a device id from the request must load it with the owner-scoped `get(principal.getId(), id)` and act only on what that returns. Unscoped `get(id)` / `delete(id)` are for the actuator and internal paths.\n- Every repository read returns a decoded copy (JPA detaches before decoding); `update()` must persist `properties`, which the verification flags of the delete and confirm actions live in.\n- The delete/confirm verification flags are stored on the account as `:` and expire (`GoogleAuthenticatorAccountVerificationUtils`). They cannot live in flow or conversation scope: the login webflow keeps its execution state client-side, and the AJAX check and the form submit carry different execution keys.\n- `CasReentrantLock.tryLock(supplier)` returns null when the lock is not acquired; never let that null reach a caller as \"no accounts\".\n- `BaseOneTimeTokenCredentialRepository.encode()` returns an encoded copy and leaves its argument alone; store and return the copy, and read normalized values (lowercased username) from it, not from the argument.\n- Per-tenant ciphers must be built once and reused: a cipher built from settings with blank keys generates its own keys, so a new instance per call cannot decode what the previous one encoded. `BaseOneTimeTokenCredentialRepository` caches them by tenant and crypto settings.\n- WebAuthn FIDO metadata: `FidoMetadataDownloader.refreshBlob()` always downloads; `loadCachedBlob()` uses the cache until the BLOB's `nextUpdate`. CAS refreshes at startup and falls back to the cache on `IOException` (the FIDO service rate-limits with HTTP 429). `CompositeAttestationTrustSourceTests` downloads from the real service; a 429 there with no cache from an earlier run is an outage, not a regression.\n- Active Directory keeps a single value of `description` on user objects. The LDAP GAuth repository therefore writes all of an entry's accounts as one JSON array value; writing one value per account loses all but one device on AD.\n- A webflow action that validates a GAuth token and then updates the device must read the device again after validation: the validator updates its own copy (used scratch code, last-used time), and updating an older copy undoes that.\n\n## Google Authenticator Redis repository\n\n- Accounts live twice: the record at `CAS_TOKEN_ACCOUNT:` and a copy as a member of the set `CAS_TOKEN_PRINCIPAL:`. `get(username)`, `count(username)` and OTP validation read the set, not the record, so a delete that removes only the record leaves a device that is still listed and still validates.\n- Reads must not repair the index. A read that removes set members whose record \"does not exist\" acts on whatever the read saw; with `read-from` sending reads to replicas, and the record and the set on different cluster slots, a lagging replica makes a live device look orphaned and the removal on the primary is permanent. Repair belongs on the explicit `delete(id)`: when the record is missing the owner is unknown, so it scans `CAS_TOKEN_PRINCIPAL:*` in batches and removes members with that id.\n- Remove set members by the raw bytes Redis returned (`executePipelined(..., RedisSerializer.byteArray())` then `sRem`), not by re-serializing a deserialized account; the value serializer is LZ4 over JDK serialization, and a removal only matches if the bytes are identical.\n- Spring Data Redis pipelining works on Lettuce cluster connections (`LettuceClusterConnection` does not override `openPipeline`) and key `SCAN` spans all nodes, so pipelines and scans here are cluster-safe.\n",".claude/skills/cas-attribute-consent/SKILL.md":"---\nname: cas-attribute-consent\ndescription: \"Review and change attribute consent: ConsentDecision, the consent webflow gate, ConsentQueryResult, repositories and their lookups and deletes, decision decryption, dates and the consent scenarios. Use when touching support/cas-server-support-consent*.\"\n---\n\n# Attribute consent\n\n## Attribute consent review discipline\n\n- Start at `ConsentDecision`, not at a repository. `id` is a primitive `long` with\n `@GeneratedValue`, so only JPA generates one. That single field is the key in four\n backends: LDAP merges by it, Redis keys on `ConsentDecision::`, Mongo maps\n it to `_id` by naming convention, and DynamoDB uses it as the table HASH key. It used to\n stay `0` on every one of them, which collapsed each user (LDAP, Redis) or the whole\n deployment (Mongo, DynamoDB) onto a single decision. `DefaultConsentDecisionBuilder.build`\n now assigns a random positive id, JPA still replaces it with a generated one, and LDAP's\n `mergeDecision` assigns one when `id <= 0`. Anything that creates a `ConsentDecision`\n outside the builder -- the actuator's `/import`, say -- still arrives with id `0`.\n- `BaseConsentRepositoryTests` used to call `decision.setId(1/100/200)` before every store,\n which is why the id defect never failed a test. `verifyMultipleDecisionsForPrincipal` now\n stores builder-produced decisions for two users across two services and then deletes by id\n and by principal, against every backend; `getOtherUser()` is overridden where the second\n user must already exist (LDAP). The class holds a `@ResourceLock` because\n `verifyDeleteRecordsForPrincipal` calls `deleteAll()` on the shared repository.\n- Consent is a gate in the login webflow, not a filter at attribute release.\n `ConsentWebflowConfigurer` prepends `CheckConsentRequiredAction` to the login flow's\n `generateServiceTicket` state; the only other consumer is\n `SamlIdPConsentSingleSignOnParticipationStrategy`. Nothing in\n `RegisteredServiceAttributeReleasePolicy` reads a stored decision, so the consented set\n never constrains what is released, and any path that issues without the login flow --\n REST protocol tickets, proxy tickets, OIDC refresh/userinfo, the OpenID4VCI\n pre-authorized code grant -- releases attributes with no consent check at all.\n- Follow `ConsentQueryResult`. It carries the decision, the service and now the resolved\n consentable attributes, and it used to be thrown away: `ConsentActivationStrategy` returned\n a bare boolean and `CheckConsentRequiredAction` reduced it to an event, so\n `prepareConsentForRequestContext` repeated the full `getConsentableAttributes` evaluation\n (person directory included) and the repository read in the same request. The strategy now\n returns the result and the action hands it to `prepareConsentForRequestContext`, which\n resolves nothing when the result carries attributes -- a result built by a custom strategy\n carries none and still falls back to resolving. What remains per consent interaction is one\n evaluation and read for the prompt, one of each inside `storeConsentDecision` on confirm,\n and one more from the `generateServiceTicketAfterConsent` clone that re-runs the check;\n `getRegisteredServiceForConsent`, and with it the access strategy, still runs twice per\n prompt. Count these by request before claiming a number.\n- `DefaultConsentEngine.executeRepositoryOperation` calls `toConsentRepository(tenant)` on\n every operation, and `TenantJdbcConsentRepositoryBuilder` builds a DataSource plus a\n Hibernate `EntityManagerFactory` inside it, then destroys them. Check the multitenant\n path before judging consent performance; the single-tenant path is not representative.\n- Repository lookups must be checked for operator and pattern correctness, not just for\n the right column names. `DynamoDbConsentFacilitator` matched SERVICE and ID with\n `ComparisonOperator.GE` (correct for the date ranges other CAS DynamoDB facilitators\n use it for, wrong for an equality lookup); it now uses `EQ`, but every read is still a\n full `scanPaginator` because `id` is the table's only key. `RedisConsentRepository`\n interpolated the raw principal into a SCAN glob; it now escapes glob characters and keeps\n only keys whose remainder is a numeric id, because the `:` delimiter alone lets principal\n `alice` reach the decisions of `alice:x`. Deleting one decision there is a `DEL` of the\n exact key rather than a scan.\n- Deletes deserve the same reading as reads. `JpaConsentRepository.deleteConsentDecisions`\n used `getSingleResult()` and so silently deleted nothing for any user with more than one\n decision; it is a bulk JPQL delete now. `ChainingConsentRepository` -- which is what the\n `consentRepository` bean always is, wrapping every configured store -- stored to every\n repository but deleted with `anyMatch`, stopping at the first success; it now asks every\n repository. `RestfulConsentRepository` sent `id` where the documented contract and the\n test's own mock server say `decisionId`, so a conforming server read a single revocation\n as \"revoke everything\". Revocation failing quietly is worse than consent failing loudly.\n- A decision that will not decipher used to be fatal: `getConsentableAttributesFrom` turned any\n failure into `IllegalArgumentException`, which propagated out of `isConsentRequiredFor` and out\n of the login flow, so key rotation or a node without the shared `cas.consent.core.crypto` keys\n locked the user out. It now logs and returns no attributes, which reads as a mismatch and\n re-prompts; the new decision is written back with the current keys. Weigh every failure on this\n path the same way -- the login flow has no recovery for an exception thrown from the consent\n check, so the question is always whether re-prompting is safe, not whether the error is correct.\n- `ConfirmConsentAction` parsed `option`, `reminder` and `reminderTimeUnit` straight off the request\n with `Integer.parseInt` / `Long.parseLong` / `ChronoUnit.valueOf` and persisted them unvalidated, so\n a missing parameter was a 500 on the confirm POST and `ChronoUnit.FOREVER` or `ERAS` parsed fine and\n then threw from `createdDate.plus(...)` on every later login. Each value now falls back on the\n configured default, and the pair is rejected unless it can actually be applied to a date -- checked by\n applying it, since `LocalDateTime.isSupported` accepts `ERAS` and only the ISO era range rejects it.\n `DefaultConsentEngine.calculateReminderExpirationDate` is the second half of that: a stored reminder\n that cannot produce a date means consent is required, never an exception, which is what protects\n decisions that were written before this validation existed or through the actuator's import.\n- `ConsentDecision.createdDate` is a zone-less `LocalDateTime` that one node writes and another compares\n against its own clock, so it is produced with `ZoneOffset.UTC`, not `ZoneId.systemDefault()`. Before that,\n the backends disagreed with each other: JPA, Redis, LDAP, DynamoDB and REST keep the wall-clock value\n verbatim, so a node in another zone read a decision as hours older or newer, while MongoDB was accidentally\n correct because Spring Data converts `LocalDateTime` through the system zone in both directions and so\n normalizes to the instant. The reminder units offered in the consent view go down to seconds, so that skew\n is not academic. `OneTimeToken.issuedDateTime` and the Google Authenticator token repositories still carry\n the same pattern with second-scale windows.\n- `cas.consent.core.active` defaults to `true`, so adding the module turns consent on for\n every service that releases attributes. Weigh findings about the consent path as if it\n is always on.\n- Wallet/OID4VCI integration is the real gap, not a defect in the consent modules:\n `BaseOidcVerifiableCredentialEncoder` reads `principal.getAttributes()` directly against\n the issuer's configured claim list, so a credential handed to a wallet carries no\n consent record, no per-claim choice, and no revocation. Selective disclosure exists in\n the SD-JWT encoder but the holder never chooses what is disclosed at issuance time.\n- Puppeteer coverage: `attribute-consent` (in-memory repository, one user, one service),\n `multitenancy-consent-jdbc`, `saml2-idp-login-consent`, `saml2-idp-login-consent-with-sso`.\n No scenario exercises LDAP, Redis, Mongo, DynamoDB or REST consent, and none stores two\n decisions for the same user, which is exactly the shape every storage defect above needs.\n",".claude/skills/cas-actuators/SKILL.md":"---\nname: cas-actuators\ndescription: \"Review and change CAS actuator endpoints: the security filter chain, access levels and IP access, REST actuator endpoints, exposure vs access, unmasked responses, request-path regexes, auditing and the actuator scenarios. Use when touching actuator endpoints or management security.\"\n---\n\n# Actuator endpoints\n\n## Actuator endpoints review discipline\n\n- There are ~63 endpoints. Inventory them with\n `grep -rl --include=*.java -E \"@(RestControllerEndpoint|ControllerEndpoint|Endpoint|WebEndpoint)\\(id\"`;\n `support/cas-server-support-reports-core` owns about a third, the rest are scattered across\n feature modules. Review them as one attack surface, not one module at a time.\n- The whole security boundary is a single `SecurityFilterChain` built by\n `CasWebSecurityConfigurerAdapter.configureHttpSecurity`. Rules are added in order --\n ignored patterns (permitAll) -> each `CasWebSecurityConfigurer.configure` -> per-endpoint\n `cas.monitor.endpoints.endpoint.*` -> `configureEndpointAccessToDenyUndefined` -> static\n resources -> form login -- and Spring Security takes the first match, so anything a\n `getIgnoredEndpoints` contributes wins over every endpoint rule that follows.\n- `prepareProtocolEndpoint` emits `/**` as well as `//**`. The first form is a\n within-segment wildcard, so an ignored endpoint also permits sibling paths sharing its\n prefix. Check that before adding an entry.\n- That chain disables security headers and logout globally, and CSRF everywhere except the paths that configurers\n declare through `getCsrfProtectedEndpoints()` (CIBA verification, WebAuthn). It is the same chain that serves the\n actuator. Any browser-reachable session credential (`cas.monitor.endpoints.form-login-enabled`) therefore leaves\n mutating actuator operations unprotected against cross-site requests.\n- `ActuatorEndpointProperties.access` defaults to `DENY` and the `endpoint` map always\n carries a synthetic `defaults` key. The adapter iterates the map and calls\n `EndpointRequest.to(\"defaults\")`, which resolves to no path and silently registers nothing;\n the real default comes from `configureEndpointAccessToDenyUndefined`. Do not read the loop\n as the place defaults are enforced.\n- `configureEndpointAccessToDenyUndefined` reads `management.endpoint..access` with\n a raw `Environment.getProperty` call and maps `UNRESTRICTED`/`READ_ONLY` to `permitAll`.\n Relaxed spellings of that key are not seen (fail-closed), but the canonical spelling turns a\n Boot-level exposure decision into anonymous Spring Security access.\n- `IP_ADDRESS` access is evaluated by `IpAddressAuthorizationManager`, which reads\n `cas.audit.engine.alternate-client-addr-header-name` (default `X-Forwarded-For`) straight off the\n request. This is intentional and is NOT a CAS defect: the fronting proxy, load balancer and\n external boot configuration are expected to set that header as a trusted header, or to blank it\n out and let Tomcat's own valves resolve the client address. Configuring that correctly is left to\n the deployer, so do not report header spoofing here as a finding.\n- `BaseCasRestActuatorEndpoint` endpoints are NOT Spring Boot operations. They are discovered by\n CAS's own `RestActuatorEndpointDiscoverer`, mapped by `RestActuatorEndpointHandlerMapping`, and\n their handlers are Spring MVC mappings rather than `@ReadOperation`/`@WriteOperation` methods.\n Boot applies an access level by filtering operations, and these endpoints declare none, so\n `management.endpoint..access=READ_ONLY` does not stop their `@PostMapping`, `@PutMapping`,\n `@PatchMapping` or `@DeleteMapping` handlers the way it stops a Boot write operation. That is\n the gap `RestActuatorEndpointHandlerMapping.isMappingPermittedByAccessLevel` closes: it resolves\n the endpoint's access through the `EndpointAccessResolver` bean and applies the same rules Boot\n applies to operations, registering nothing under `NONE` and only `GET`/`HEAD`/`OPTIONS` mappings\n under `READ_ONLY`. Note that `configureEndpointAccessToDenyUndefined` maps `READ_ONLY` to\n `permitAll`, which is why the write methods used to get through, and maps `NONE` to `denyAll`, so\n a `NONE` endpoint is usually refused by security before the missing mapping matters.\n `ActuatorEndpointAccessControlTests` covers all of it, with `releaseAttributes` beside\n `registeredServices` as the Boot operation endpoint that has always behaved this way.\n- Before changing what an access level does to these endpoints, measure the blast radius rather\n than reasoning from the annotation: every REST actuator endpoint declares\n `defaultAccess = Access.NONE` and the web application ships `management.endpoints.access.default=NONE`,\n which suggests widespread breakage, but in fact all 44 test classes and all 69 puppeteer scenarios\n that call one already declare `management.endpoint..access` or `management.endpoints.access.default`\n explicitly. Walk the test tree and `ci/tests/puppeteer/scenarios/*/script.json` and count.\n- Do not confuse that with exposure. A REST actuator endpoint left out of\n `management.endpoints.web.exposure.include` answers `403`, not `200`: no rule is registered for\n it in `configureEndpointAccessToDenyUndefined`, and Spring Security denies a request no matcher\n claims. Verify the status a given combination of exposure and access actually produces before\n describing any of it as reachable.\n- When `management.server.port` differs, `CasCoreWebManagementContextConfiguration` registers the\n handler mappings in the child management context but no `SecurityFilterChain`. Verify what\n actually secures that port before assuming the main chain applies.\n- Several endpoints are authentication primitives, not diagnostics: `casValidate`,\n `samlValidate` and `samlPostProfileResponse` mint CAS assertions and signed SAML responses\n for an arbitrary username, and the `password` parameter is optional -- with no password they\n fall through to `PrincipalResolver` and succeed. Anything that widens actuator access widens\n impersonation. `tokenAuth` only validates a JWT and answers the principal with the service's\n id, name and service id; it no longer issues tokens, and must never return service properties.\n- These endpoints return configuration values and service definitions unmasked, unlike Boot's own\n `/env` and `/configprops`. `casConfig` `/retrieve` returns raw property values and\n `registeredServices` serializes `OAuthRegisteredService.clientSecrets` (the `value` field carries\n no `@JsonIgnore`). Masking was proposed and rejected, so do not re-propose it without agreeing\n the approach with the maintainer first. `casConfig` `/encrypt` and `/decrypt` are a deliberate\n operator tool that Palantir exposes in its UI, not an oracle to close.\n- Before proposing masking on any actuator response, work out how the admin UI consumes it: grep\n `support/cas-server-support-thymeleaf/src/main/resources/static/js/palantir-*.js`. Palantir's\n service editor does a full `GET /registeredServices/{id}` -> edit -> `PUT` round-trip\n (`palantir-services.js`), so masking any path it reads would write the mask back into the\n registry, and `/export` has the same requirement; redacting there needs the save path to preserve\n existing secrets first. `casConfig` `/retrieve` does not have that problem, because\n `palantir-pac4j.js` reads only `name` and `propertySource` from it.\n- User-supplied strings are compiled into regular expressions on the request path:\n `configurationMetadata/{term}` (then matched over every known property in a `parallelStream`)\n and `casConfig` `/retrieve`. Treat these as ReDoS/CPU-exhaustion boundaries; actuator endpoints\n are not covered by CAS's authentication throttling.\n- No actuator endpoint carries `@Audit`. Session destruction, service deletion, key rotation,\n configuration mutation and token minting all happen without an Inspektr record. Check for this\n before claiming an administrative action is traceable.\n- Puppeteer coverage: `actuator-endpoint-cors`, `actuator-endpoint-login-jdbc`,\n `actuator-endpoint-management`, `actuator-endpoint-metrics`, `actuator-endpoint-reports`,\n `actuator-endpoint-roles`, `actuator-form-login`, `actuator-form-login-ldap`,\n `actuator-form-login-ldap-roles`, `actuator-form-login-ldap-userauthz`,\n `configuration-refresh-endpoint`, `sso-sessions-endpoint`, `tomcat-forwarded-headers`\n (the only `IP_ADDRESS` scenario). Every one of them asserts that an *authorized* caller gets\n 200; none asserts 401/403 for an unauthenticated one, and 158 scenarios run with\n `management.endpoints.web.exposure.include=*`. A change to endpoint security therefore needs a\n new negative scenario rather than a rerun.\n",".claude/skills/cas-docs-site/SKILL.md":"---\nname: cas-docs-site\ndescription: \"Edit the CAS documentation site (docs/cas-server-documentation, Jekyll plugins, site.js/site.css, ci/docs/publish.sh, the docs data generator) and release notes: page titles and descriptions, setting links, settings rules, release-notes front matter and tags, Quick Start wizard, sidebar, mobile layout. Use when editing any documentation page or release_notes/RC*.md.\"\n---\n\n# CAS documentation site\n\n## Practical boundaries\n\n- Documentation pages on gh-pages are pre-rendered per version, but they load the stylesheet and script from the shared site root, and every publish overwrites those root files. The current design ships as `stylesheets/site.css`, `stylesheets/site-print.css` and `javascripts/site.js`; the root `stylesheet.css`, `print.css` and `main.js` belong to the released versions' old markup. A redesign that changes page markup must use new asset names, never replace the ones older versions link.\n- The documentation data generator (`docs/cas-server-documentation-processor`) runs as `java @build/casdocsgen.args ...`, an argument file written by its `docsGeneratorArguments` task from `sourceSets.main.runtimeClasspath`; `publish.sh` no longer builds the ~1 GB `casdocsgen.jar` boot jar. Its Gradle run adds `-DskipErrorProneCompiler=true` (override with `DOCS_GENERATOR_GRADLE_OPTIONS`, an empty value restores Error Prone). It still needs every CAS module compiled: actuators, feature toggles and shell commands are found by ClassGraph scans of the runtime classpath, and third-party settings come from the dependencies' metadata. Those lookups go through `CasDocumentationClassIndex`, one ClassGraph scan of `org` shared by the exporters; add new class lookups there rather than calling `ReflectionUtils`, which scans the whole classpath on every call.\n- `ci/docs/publish.sh` exit codes carry meaning for the workflow retry (`retry_on_exit_code: 1`): 1 is a failure worth another attempt, 3 is broken internal links/images/scripts (fails at once, nothing is published), 4 is broken external links only (the site is published first, then the job fails). Keep new failure paths on 1 unless a rerun cannot help. External links are checked only on the weekly schedule or when asked (`--proof-external`, the `proofReadExternal` input or `vars.DOCS_PROOF_EXTERNAL`), with successful results cached for 7 days in `build/htmlproofer`.\n- Actuator endpoint blocks (`_includes_site/actuators.html`) take their operations from the `cas_actuator_operations` filter in `_plugins/cas_actuators.rb` (sorted, parameters normalized, curl built there), and settings snippets from `cas_actuator_enable_snippet` / `cas_actuator_security_snippet` via `cas-actuator-snippet.html` in all three formats. Per operation, render only what differs (parameters, response, example); setup, security, settings and troubleshooting are rendered once per include in the shared tabs. The operations table is excluded from `responsiveTables()`.\n- Settings search: `ci/docs/index.js` writes `assets/data//index.json` as `{generated, docs}` (no lunr index; each doc carries name, short type, description, default, kind required/optional/thirdparty, module, duration, deprecation). `site.js` searches it directly (`searchCasSettings`, shared by the Configuration Properties page and the Shift-Shift palette); the page state lives in the URL (`?q=&exact=1&scope=name&kind=cas|thirdparty&deprecated=hide`). The layout exposes `data-docs-base`, `data-docs-version` and `data-docs-build` on `` for these URLs.\n- Feature toggles (`Configuration-Feature-Toggles.md`) render through `_includes_site/cas-feature-toggles.html` from the `cas_feature_catalog` filter in `_plugins/cas_features.rb`, which derives feature and module from the `CasFeatureModule.[.].enabled` property, groups features by area and links docs only when the target page exists for that version. Add title overrides, groups or docs links there, not in the include. The environment variable form maps both `.` and `-` to `_` (`CasFeatureEnabledCondition` reads through `Environment.getProperty`), unlike the relaxed-binding form used for regular settings.\n- Module dependency tabs (`_includes_site/casmodule.html`, included through `include_cached`) are plain Bootstrap tabs: no inline script, the default tab and pane are chosen together in Liquid, and pane ids use the full coordinates plus the variant options. Do not add per-include scripts or truncated ids; either one lets the selected tab and the visible pane drift apart.\n- Local serving (`publish.sh --serve true`) keeps the configured `baseurl: /cas`, so the site answers at `http://localhost:4000/cas//` exactly like production. `variables.html` always sets `basePath` to `/cas` and `site.js` has no localhost path branches; do not reintroduce `--baseurl \"\"` or localhost-specific paths.\n- Release notes (`release_notes/RC.md`) carry a `release:` front matter block (summary, facts, upgrade notes, highlights, optional spotlight over a front matter image list) and open with `{% include release-digest.html %}` and end with `{% include release-footer.html %}`. Tag New & Noteworthy topics with a block IAL on the line after the heading and Other Stuff bullets with a list item IAL (`- {: .fixed} ...`): types are `new`, `changed`, `fixed`, `action`, `removed`; add `data-area=\"...\"` only when the first link does not identify the area. The area must be a key of `AREAS` in `_plugins/cas_release_notes.rb` (SSO cookies and sessions are `tickets`; there is no `sso`). `_plugins/cas_release_notes.rb` normalizes the tags, groups Other Stuff by area and resolves `section:` names to kramdown GFM heading ids before rendering; a `section:` that names no heading logs a warning. Upgrade notes may point at an Other Stuff area group by its label. `release_notes/RC.md` (front matter `release_aggregate:`) is generated from every RC page in the same folder: topics with the same title are merged and show each release candidate's notes, identical Other Stuff items are listed once with all their release candidates, and the `` marker is where the generated changes go. Never edit changes into that page by hand.\n- Section heading icons come from `CAS_SECTION_ICONS` in `site.js` and apply only to direct `h2` children of the article whose id is in that map; add an entry there rather than icons in markdown.\n- In the development docs, `site.js` wraps every table inside `#cas-docs-container` in a framed `.table-scroll` card, so do not use `` for layout inside components (buttons, headers, badges); use flex markup instead.\n- Documentation property blocks get their settings from the `cas_properties` / `cas_third_party_properties` filters in `docs/cas-server-documentation/_plugins/cas_properties.rb`; do not loop over `site.data` in Liquid for this, it scans ~14k entries per block. Liquid `assign` inside an include writes to the page scope, so a `casproperties` include nested inside another block's panels must pass `topics=\"false\"` (and usually `intro=\"false\"`) or it resets the outer block's state. Their output is wrapped in `{::nomarkdown}`, so include them at the start of a line in markdown or pass the capture through `markdownify` (with `|`, not `||`). Catalog descriptions carry raw `<`/`>` (for example `management.endpoint..access`); the plugin escapes every tag outside `INLINE_TAGS` into `descriptionHtml` / `summaryText`, so print those fields and never unescape descriptions in Liquid: one stray tag inside the actuator modal makes kramdown drop the closing tags and everything after it on the page.\n- Documentation page titles must be unique: use `title: CAS - `, and give overview pages a `description:`\n front matter entry (under 160 characters). Pages without one get their meta description from the first paragraph in\n `_layouts/default.html`, which skips dependency boilerplate, short or colon-ended lead-ins and \"see this guide\" lines.\n- The Versions menu lists `documentation_versions` from `docs/cas-server-documentation/_config.yml` (development plus\n maintained releases); update it together with the EOL schedule in `developer/Maintenance-Policy.md`.\n- Third-party CSS and JS in `_layouts/default.html` are pinned to exact versions with `integrity` (sha384) and\n `crossorigin=\"anonymous\"`. Recompute the hash whenever a version changes; Google Fonts and the gtag script cannot carry one.\n Analytics is the GA4 tag `G-W3M8JXP7GP`, loaded only on `apereo.github.io`.\n- Do not dim muted text with `opacity`: `--docs-muted` on its own meets 4.5:1 in both themes, and opacity drops it below.\n `--docs-amber` is darker in light mode for the same reason.\n- In `casmodule.html`, only the tab links sit inside `role=\"tablist\"`; the Resources dropdown is a sibling `
` for layout inside components (buttons, headers, badges); use flex markup instead.\n- Documentation property blocks get their settings from the `cas_properties` / `cas_third_party_properties` filters in `docs/cas-server-documentation/_plugins/cas_properties.rb`; do not loop over `site.data` in Liquid for this, it scans ~14k entries per block. Liquid `assign` inside an include writes to the page scope, so a `casproperties` include nested inside another block's panels must pass `topics=\"false\"` (and usually `intro=\"false\"`) or it resets the outer block's state. Their output is wrapped in `{::nomarkdown}`, so include them at the start of a line in markdown or pass the capture through `markdownify` (with `|`, not `||`). Catalog descriptions carry raw `<`/`>` (for example `management.endpoint..access`); the plugin escapes every tag outside `INLINE_TAGS` into `descriptionHtml` / `summaryText`, so print those fields and never unescape descriptions in Liquid: one stray tag inside the actuator modal makes kramdown drop the closing tags and everything after it on the page.\n- Documentation page titles must be unique: use `title: CAS - `, and give overview pages a `description:`\n front matter entry (under 160 characters). Pages without one get their meta description from the first paragraph in\n `_layouts/default.html`, which skips dependency boilerplate, short or colon-ended lead-ins and \"see this guide\" lines.\n- The Versions menu lists `documentation_versions` from `docs/cas-server-documentation/_config.yml` (development plus\n maintained releases); update it together with the EOL schedule in `developer/Maintenance-Policy.md`.\n- Third-party CSS and JS in `_layouts/default.html` are pinned to exact versions with `integrity` (sha384) and\n `crossorigin=\"anonymous\"`. Recompute the hash whenever a version changes; Google Fonts and the gtag script cannot carry one.\n Analytics is the GA4 tag `G-W3M8JXP7GP`, loaded only on `apereo.github.io`.\n- Do not dim muted text with `opacity`: `--docs-muted` on its own meets 4.5:1 in both themes, and opacity drops it below.\n `--docs-amber` is darker in light mode for the same reason.\n- In `casmodule.html`, only the tab links sit inside `role=\"tablist\"`; the Resources dropdown is a sibling `
` for layout inside components (buttons, headers, badges); use flex markup instead.\n- Documentation property blocks get their settings from the `cas_properties` / `cas_third_party_properties` filters in `docs/cas-server-documentation/_plugins/cas_properties.rb`; do not loop over `site.data` in Liquid for this, it scans ~14k entries per block. Liquid `assign` inside an include writes to the page scope, so a `casproperties` include nested inside another block's panels must pass `topics=\"false\"` (and usually `intro=\"false\"`) or it resets the outer block's state. Their output is wrapped in `{::nomarkdown}`, so include them at the start of a line in markdown or pass the capture through `markdownify` (with `|`, not `||`). Catalog descriptions carry raw `<`/`>` (for example `management.endpoint..access`); the plugin escapes every tag outside `INLINE_TAGS` into `descriptionHtml` / `summaryText`, so print those fields and never unescape descriptions in Liquid: one stray tag inside the actuator modal makes kramdown drop the closing tags and everything after it on the page.\n- Documentation page titles must be unique: use `title: CAS - `, and give overview pages a `description:`\n front matter entry (under 160 characters). Pages without one get their meta description from the first paragraph in\n `_layouts/default.html`, which skips dependency boilerplate, short or colon-ended lead-ins and \"see this guide\" lines.\n- The Versions menu lists `documentation_versions` from `docs/cas-server-documentation/_config.yml` (development plus\n maintained releases); update it together with the EOL schedule in `developer/Maintenance-Policy.md`.\n- Third-party CSS and JS in `_layouts/default.html` are pinned to exact versions with `integrity` (sha384) and\n `crossorigin=\"anonymous\"`. Recompute the hash whenever a version changes; Google Fonts and the gtag script cannot carry one.\n Analytics is the GA4 tag `G-W3M8JXP7GP`, loaded only on `apereo.github.io`.\n- Do not dim muted text with `opacity`: `--docs-muted` on its own meets 4.5:1 in both themes, and opacity drops it below.\n `--docs-amber` is darker in light mode for the same reason.\n- In `casmodule.html`, only the tab links sit inside `role=\"tablist\"`; the Resources dropdown is a sibling `
` for layout inside components (buttons, headers, badges); use flex markup instead.\n- Documentation property blocks get their settings from the `cas_properties` / `cas_third_party_properties` filters in `docs/cas-server-documentation/_plugins/cas_properties.rb`; do not loop over `site.data` in Liquid for this, it scans ~14k entries per block. Liquid `assign` inside an include writes to the page scope, so a `casproperties` include nested inside another block's panels must pass `topics=\"false\"` (and usually `intro=\"false\"`) or it resets the outer block's state. Their output is wrapped in `{::nomarkdown}`, so include them at the start of a line in markdown or pass the capture through `markdownify` (with `|`, not `||`). Catalog descriptions carry raw `<`/`>` (for example `management.endpoint..access`); the plugin escapes every tag outside `INLINE_TAGS` into `descriptionHtml` / `summaryText`, so print those fields and never unescape descriptions in Liquid: one stray tag inside the actuator modal makes kramdown drop the closing tags and everything after it on the page.\n- Documentation page titles must be unique: use `title: CAS - `, and give overview pages a `description:`\n front matter entry (under 160 characters). Pages without one get their meta description from the first paragraph in\n `_layouts/default.html`, which skips dependency boilerplate, short or colon-ended lead-ins and \"see this guide\" lines.\n- The Versions menu lists `documentation_versions` from `docs/cas-server-documentation/_config.yml` (development plus\n maintained releases); update it together with the EOL schedule in `developer/Maintenance-Policy.md`.\n- Third-party CSS and JS in `_layouts/default.html` are pinned to exact versions with `integrity` (sha384) and\n `crossorigin=\"anonymous\"`. Recompute the hash whenever a version changes; Google Fonts and the gtag script cannot carry one.\n Analytics is the GA4 tag `G-W3M8JXP7GP`, loaded only on `apereo.github.io`.\n- Do not dim muted text with `opacity`: `--docs-muted` on its own meets 4.5:1 in both themes, and opacity drops it below.\n `--docs-amber` is darker in light mode for the same reason.\n- In `casmodule.html`, only the tab links sit inside `role=\"tablist\"`; the Resources dropdown is a sibling `