SRVLOGIC-98-security: Incorporated Peer reviewer and Walter suggestions

Author: Kalyani Desai

_attributes/common-attributes.adoc

@@ -113,12 +113,12 @@
 :ServerlessOperatorName: OpenShift Serverless Operator
 :ServerlessLogicOperatorName: OpenShift Serverless Logic Operator
 :FunctionsProductName: OpenShift Serverless Functions
-:ServerlessProductVersion: 1.35.0
-:ServerlessLogicQuarkusVersion: 3.15.3.redhat-00004
-:ServerlessLogicOrgKieVersion: 9.102.0.redhat-00005
+:ServerlessProductVersion: 1.36.0
+:ServerlessLogicQuarkusVersion: 3.15.4.redhat-00001
+:ServerlessLogicOrgKieVersion: 9.103.0.redhat-00003
 :ServerlessLogicOauthDependencyVersion: 2.9.0-lts
-:ServerlessLogicRegistryVersion: registry.redhat.io/openshift-serverless-1/logic-swf-builder-rhel8:1.35.0
-:ServerlessLogic-DDL-Script-url: link:https://maven.repository.redhat.com/ga/org/kie/kogito/kogito-ddl/9.102.0.redhat-00005/kogito-ddl-9.102.0.redhat-00005-db-scripts.zip[kogito-ddl-9.102.0.redhat-00005-db-scripts.zip]
+:ServerlessLogicRegistryVersion: registry.redhat.io/openshift-serverless-1/logic-swf-builder-rhel8:1.36.0
+:ServerlessLogic-DDL-Script-url: link:https://maven.repository.redhat.com/ga/org/kie/kogito/kogito-ddl/9.103.0.redhat-00003/kogito-ddl-9.103.0.redhat-00003-db-scripts.zip[kogito-ddl-9.103.0.redhat-00003-db-scripts.zip]
 //service mesh v2
 :product-dedicated: Red Hat OpenShift Dedicated
 :SMProductName: Red Hat OpenShift Service Mesh

modules/serverless-logic-security-example-auth-token-propagation.adoc

@@ -7,7 +7,7 @@
 
 {ServerlessLogicProductName} supports token propagation for OpenAPI operations that use the `oauth2` or `http` bearer security scheme types. Token propagation enables your workflow to forward the authorization token it receives during workflow creation to downstream services.This feature is useful when your workflow needs to interact with third-party services on behalf of the client that initiated the request.
 
-You must configure token propagation individually for each security scheme. Once enabled, all OpenAPI operations secured using the same scheme will use the propagated token unless explicitly overridden.
+You must configure token propagation individually for each security scheme. After it is enabled, all OpenAPI operations secured using the same scheme uses the propagated token unless explicitly overridden.
 
 The following example defines the `sayHelloOauth2` operation in the `security-example.json` file. This operation uses the `oauth-example` security scheme with the `clientCredentials` flow:
 
@@ -68,7 +68,7 @@ You can use the following configuration keys to enable and customize token propa
 
 [NOTE]
 ====
-The tokens are automatically passed to downstream services while the workflow is active. When the workflow enters a waiting state such as a timer or event-based pause, the token propagation stops. After the workflow resumes, tokens are not re-propagated automatically. You must manage re-authentication if needed.
+The tokens are automatically passed to downstream services while the workflow is active. When the workflow enters a waiting state, such as a timer or event-based pause, the token propagation stops. After the workflow resumes, tokens are not re-propagated automatically. You must manage re-authentication if needed.
 ====
 
 [cols="2,1,1",options="header"]

modules/serverless-logic-security-example-oauth-authentication.adoc

@@ -5,7 +5,7 @@
 [id="serverless-logic-security-example-oauth-authentication_{context}"]
 = Example of clientCredentials OAuth 2.0 authentication
 
-The following example shows how to secure an OpenAPI operation using the OAuth 2.0 `clientCredentials` flow. The OpenAPI specification defines the `sayHelloOauth2` operation, which uses the `oauth-example` security scheme. Unlike simpler authentication methods such as HTTP Basic or API keys, OAuth 2.0 authentication requires additional integration with the Quarkus OpenID Connect (OIDC) Client.
+The following example shows how to secure an OpenAPI operation using the OAuth 2.0 `clientCredentials` flow. The OpenAPI specification defines the `sayHelloOauth2` operation, which uses the `oauth-example` security scheme. Unlike simpler authentication methods, such as HTTP Basic or API keys, OAuth 2.0 authentication requires additional integration with the Quarkus OpenID Connect (OIDC) Client.
 
 .Example OpenAPI specification with OAuth 2.0
 [source,json]
@@ -128,6 +128,6 @@ quarkus.oidc-client.oauth_example.credentials.client-secret.value=secret
 
 In this configuration:
 
-* `oauth_example` matches the sanitized name of the `oauth-example` scheme in the OpenAPI file. The link between the sanitized scheme name and the corresponding `OidcClient` is by using that simple naming convention.
+* `oauth_example` matches the sanitized name of the `oauth-example` scheme in the OpenAPI file. The link between the sanitized scheme name and the corresponding `OidcClient` is achieved by using that simple naming convention.
 
 * The OidcClient handles token generation and renewal automatically during workflow execution.

modules/serverless-logic-security-overview-openapi-service-authentication.adoc

@@ -27,7 +27,7 @@ When a workflow calls a secured operation, it references these defined schemes t
 }
 ----
 
-If the OpenAPI file defines `Security Schemes` but does not include  `Security Requirements` for operations, the generator can be configured to create them by default. These defaults apply to operations without explicitly defined requirements.
+If the OpenAPI file defines `Security Schemes`, but does not include `Security Requirements` for operations, the generator can be configured to create them by default. These defaults apply to operations without explicitly defined requirements.
 
 To configure that scheme, you must use the `quarkus.openapi-generator.codegen.default-security-scheme` property. The `default-security-scheme` property is used only at code generation time and not during the runtime. The value must match any of the available schemes in `securitySchemes` section, such as `http-basic-example` or `api-key-example`: