Support Actors for Process Starters

[StephenOTT]

Description

Continuation of https://github.com/kiegroup/kogito-apps/issues/1200

From section 5.3: https://docs.jboss.org/kogito/release/latest/html_single/#proc-bpmn-model-creating_kogito-developing-process-services

The ProcessResourceGenerator.java supports the securityRoles. Would you accept a PR for adding Actor support so Process Start security mirrors that of User Task security?

Implementation ideas

The ProcessResourceGenerator and related locations that implement the securityRoles check will have a few lines added to support an actors check so specific users can be supported.

[cristianonicolai]

@StephenOTT tricky one. See this other JIRA as well https://issues.redhat.com/browse/KOGITO-4962. We actually intend to rely more on the security context. By doing that, and hooking into standard mechanisms for auth, like using @RolesAllowed to secure REST endpoints, it brings extra flexibility on how this can be configured and avoid us having to create a layer to manually do these checks. The downside is, as you noticed, no support for user direct mapping. But point is that in most cases we believe that roles would end up being used anyway so in that case maybe is better to just work around and for instance create an artificial role in a properties file, mapping the users you would like to grant access to.

[StephenOTT]

@cristianonicolai yes roles in practice are the best practice and SHOULD be used over usernames. In real world though, there are many times where you need to code in usernames for dev, quick fixes, "just get it done", etc use cases. Same concepts to why UTs have Who the task is claimed to, the candidate Actors and candidate groups rather than just groups.

If we are going to create groups as the standard, then we need a ability to easily create sudo-groups that can be created through app config or somewhere else. Something as simple as: "i am building a new process, and need a group created, but i can't create the group in my ODIC yet" becomes a blocker to dev without some faux/internal/app-memory-group ability.

[cristianonicolai]

@StephenOTT yep, I totally get that. The point is that I think there are specific libs/frameworks that can help that better than us creating something. Of course, we can create dev specific helpers, if that is somehow too much work, but see this file-based properties from Quarkus as an example: https://quarkus.io/guides/security-properties that can be easily enabled for dev, as long as we rely on standard auth.

[StephenOTT]

@cristianonicolai can the sec properties be used in parallel with ODIC/openid auth? (was under the impression you have to pick ~one of the providers such as Sec Properties file OR openID)

[cristianonicolai]

@StephenOTT I haven't checked that but I would believe it works, possibly by setting up different Quarkus profiles like mentioned in https://quarkus.io/guides/security-testing#configuring-user-information. Maybe if you're willing to check that, we can figure if that meets the requirement.

[StephenOTT]

But profiles would mean different ENVs. In my scenario it is all the same ENV configurations: Process Starters that are coded to specific usernames would be at a dev level, but also at a production level.

If only roles are being used, are you planning to modify how user tasks function and only support "groups" / roles?