[jboss-jira] [JBoss JIRA] (WFCORE-3041) Cannot add policy resource with no parameter

[Brian Stansberry (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-3041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474831#comment-13474831 ] 

Brian Stansberry commented on WFCORE-3041:
------------------------------------------

I'm poking at this because I'm concerned that correcting this general area should be a Blocker for WF 11.

tl;dr; skip to #5.

1) This resource is an effective singleton, because creating more than one will result in a failure due to trying to register POLICY_RUNTIME_CAPABILITY more than once. 

a) The resource description doesn't state the max occurrences of the resource type is 1. The fact that's missing is a Major at worst. 

b) If the resource type isn't meant to be a singleton, we have at least a Critical, because the POLICY_RUNTIME_CAPABILITY handling is preventing more than one.

2) Despite being an effective singleton, the resource can have a dynamic name.  That's odd. Now we're starting to approach Blocker territory because this is odd, we want API to be correct in WildFly .Final releases, and we can't change things incompatibly thereafter.

3) The reason the resource can have a dynamic name is there has to be a "default policy" and instead of making the resource a singleton with a static name and making the default-policy attribute required, instead there's this weird thing where if default-policy is not configured we use the resource name instead. Not a clear Blocker in and of itself, but again getting into blocker territory because we want our API right in WildFly .Final releases, and we can't change things incompatibly thereafter.

4) The 'default-policy' attribute is actually a model reference, referring to one of the elements in the sibling jacc-policy or custom-policy lists. Typically we would want to use a capability reference for this kind of model ref, but we can't here:

a) Doing so would require unique names for the elements across the 2 lists. Which doesn't sound like much of a problem, but isn't something we can't impose after WF 11 Final.

b) This business of the value of the last attribute of the resource name being the capability ref isn't something describable. I do not want to support that kind of thing in our management model and our provisioning tooling; i.e. if we have this kind of usage it likely precludes using a capability reference for it.

5) Digging more after writing all the above, I can't see what the point of the jacc-policy and custom-policy lists is anyway. The code is going to work out the default policy, either from the attribute or the resource name. Then it is going to search the jacc-policy *list* and then the custom-policy *list* looking for an element whose name matches. As soon as it finds a match it stops. All other elements are irrelevant. So what's the point of these lists? Why doesn't jacc-policy just store a single item, and custom-policy stores a single item, with both attributes required but are alternatives to each other? And then since only one policy can be declared the whole default-policy business goes away.

I'm going to raise sorting this to Blocker because unless I've missed something this is complex to the point of just being broken and it can't be readily fixed in a later release.

> Cannot add policy resource with no parameter
> --------------------------------------------
>
>                 Key: WFCORE-3041
>                 URL: https://issues.jboss.org/browse/WFCORE-3041
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>            Reporter: Claudio Miranda
>            Assignee: Michal Petrov
>             Fix For: 3.0.5.Final
>
>
> subsystem=elytron/policy resources has no required attributes, but it fails to add a resource with no parameters.
> {code}
> /profile=full/subsystem=elytron/policy=policy_test:add
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"server-one" => "Could find policy provider with name [policy_test]"}}}}}},
>     "rolled-back" => true,
>     "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
>         "outcome" => "failed",
>         "failure-description" => "Could find policy provider with name [policy_test]",
>         "rolled-back" => true
>     }}}}}}
> }
> {code}
> To add is necessary to inform either custom-policy or jacc-policy
> {code}
> /profile=full/subsystem=elytron/policy=policy2:add(jacc-policy=[{name=policy2}])
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
>         "outcome" => "success",
>         "response-headers" => {
>             "operation-requires-reload" => true,
>             "process-state" => "reload-required"
>         }
>     }}}}}}
> }
> {code}
> There is also a problem related to "default-policy" being set to a non existent policy.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)