davsclaus opened a new pull request, #28416:
URL: https://github.com/apache/camel/pull/28416

   _Claude Code on behalf of davsclaus_
   
   This group adds the catalog body types (CAMEL-24961) for eleven security 
components: keycloak, ldap, spring-ldap, ldif, spiffe, openfga, opa, 
openfeature, crypto, xmlsecurity-sign and xmlsecurity-verify. Each change is an 
`@BodyTypes` annotation on the Endpoint, plus the JSON it generates and the 
catalog copy. Two doc pages had their body text corrected. The change is about 
the message bodies only, not about what these components check.
   
   **What the catalog says now**
   
   | Component | Consumer | Producer input | Producer output |
   |---|---|---|---|
   | keycloak | an `EventRepresentation` (`AdminEventRepresentation` with 
eventType=admin-events) | `any`: the inputs are headers; the request object 
with pojoRequest | by operation (all 104): the representation for a get, a List 
for a list or search, a `jakarta.ws.rs.core.Response` for most creates, a Map 
for the bulk operations, or a confirmation text |
   | ldap | | the search filter as text | a `List<SearchResult>` |
   | spring-ldap | | a Map of the parameters of the operation | unchanged; a 
`List<Attributes>` for SEARCH; what the function returns for FUNCTION_DRIVEN |
   | ldif | | the LDIF as text, bytes, a stream or a file | a List of status 
texts, or null for no body |
   | spiffe | | `any`: validateJwtSvid reads the token as text when no header 
has it | the X.509 chain as a List by default; an `X509Svid` or unchanged by 
x509Response; the JWT as text for fetchJwtSvid; a `JwtSvid` for validateJwtSvid 
|
   | openfga | | `any`; a List or comma-separated text for batchCheck; a Map, a 
List or a `ClientTupleKey` for writeTuples and deleteTuples; a configured tuple 
wins | by operation: unchanged for check, write and delete; a List of Strings; 
a List of Maps for the reads; a `UsersetTree` for expand |
   | opa | | `any`: the body is the input only with includeBody; a List with 
batch | unchanged: the decision is in the CamelOpaDecision headers |
   | openfeature | | `any`: a Map is the evaluation context with 
contextFromBody | a `Boolean`, or the variant as text; unchanged with 
resultProperty |
   | crypto | | the payload as text, bytes, a stream or a file | unchanged: the 
signature is the CamelDigitalSignature header |
   | xmlsecurity-sign | | the XML as text, bytes, a stream, a file or a DOM 
(any text with plainText) | the signed XML as `byte[]` |
   | xmlsecurity-verify | | the signed XML | the content as `byte[]` |
   
   **Checked at runtime.** Throwaway tests, not part of the PR, sent text, 
bytes, a stream, a file, a Map, a POJO and no body. The setups:
   - **Containers:** OpenFGA and Keycloak (test-infra), and OpenLDAP (the image 
of the openldap test-infra). The embedded ApacheDS of the ldap tests does not 
start; see below.
   - **Mocks:** the clients of spiffe and opa.
   - **In-process:** openfeature, crypto and xmlsecurity, with in-memory keys.
   
   Not run:
   - a successful keycloak token introspection, revoke or permission evaluation;
   - the remote flagd provider of openfeature;
   - detached XML signatures.
   
   **Choices**
   - keycloak lists every operation with its result type, taken from the 
producer code. The description says that the CamelKeycloakOperation header can 
override the operation.
   - openfga depends on `object`, as a configured tuple wins over the body.
   
   **Doc fixes**
   - **spring-ldap:** the body is unchanged also for authenticate and 
modify_attributes, not only for bind and unbind.
   - **openfga:** a configured tuple wins over the body for writeTuples. The 
page said it was the other way round.
   
   PRs #28336 (camel-keycloak), #28355 (camel-xmlsecurity) and #28391 (the 
openfeature language) change these modules. This PR only adds the annotations 
to the Endpoint classes.
   
   **Bugs found, not fixed here.** The JIRAs, one per component, will follow.
   - **keycloak:**
     - With pojoRequest=true, a body of the wrong type does nothing: no call 
and no error.
     - A failed create or delete (409, 404) is not an error: the Response is 
the body, and it is never closed.
     - bulkCreateUsers with a List of Maps fails with a raw ClassCastException.
   - **openfga:**
     - batchCheck with a Map body splits its toString, and the whole exchange 
fails with an HTTP 400.
     - listRelations gives the relations in another order on every call.
   - **ldap:**
     - When no bean matches dirContextName, the producer fails with a 
NullPointerException.
     - A DirContext bean is closed after the first exchange, so the second one 
fails.
     - The embedded ApacheDS of the module tests does not start (ERR_277 
"Attribute publicKey not declared").
   - **spring-ldap:** a body that is not a Map fails with a bare 
NullPointerException.
   - **ldif:**
     - The LdapConnection bean is closed after each exchange. The next one 
reconnects without the bind and answers "modifications require authentication", 
with no exception.
     - A failure status is only the message of the root cause, so a failed 
entry can be an empty text.
     - No body gives null, not the empty text the code means.
   - **crypto:** with stream caching off, signing uses up a stream body, so the 
next step gets an empty body.
   
   **Test change:** `CatalogDocsTest` of camel-jbang-core used ldif as its 
component that declares no body types. It now uses the split EIP, as the 
catalog has no body types for EIPs.
   
   **Local checks**
   - The changed modules build, with no change to the generated files after the 
build.
   - The catalog copies equal their modules.
   - camel-catalog, camel-yaml-dsl-validator and camel-jbang-core tests pass.
   - The Endpoint and Component DSLs regenerate with no change.
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to