This is by design. The enforcement of rejecting end-user requests to servers is done by OperationContextImpl if the OSH attempts to make a call involving write access to the configuration model.
We can't drop that check, as it's the critical safeguard. Relying on accurate metadata to do security enforcement is weaker than just preventing the low level check.
OTOH, you make a good point in IRC that it's bad to hide ops in things like read-operation-names that can actually be invoked. The limitation in read-operation-names is based on the metadata.
Making that consistent though would mean rejecting requests if the OperationDefinition didn't report the op as being runtime-only. That would further break subsystems, particular concern being external ones not tested by our testsuite, that have problems like WFLY-5418.
That might be an ok thing to do; I'm somewhat in favor, but IMHO it's too late for that. It needs to be in an early Beta release for a Major, and really that means an EAP major, not just a WildFly one.
In HipChat you mentioned the "describe" op. That's a somewhat different case where we don't report the op in the API because it's marked private, but we make it accessible. Same thing applies to "composite". Really we should just make those public. Theres' a JIRA for doing that for "composite". The only reason I haven't done that one is a lame concern that the description for these is not "complete", i.e. the params and responses are not fully described (and can't be.) That's kind of lame though. Obviously the system is massively impaired if "composite" can't be called by a user.
If we made "composite" and "describe" public, rejecting end user calls to private methods would be more feasible. It has similar issues in terms of potential breakage and being "too late for this major" as rejecting non-runtime-only would. It should be a smaller issue, as I don't expect subsystem to have private ops that users are meant to invoke anyway. Really that's kind of a bug in the subsystem. 
Bug
Minor
Brian Stansberry
made changes -
Jeff Mesnil
created issue -
This is by design. The enforcement of rejecting end-user requests to servers is done by OperationContextImpl if the OSH attempts to make a call involving write access to the configuration model.
We can't drop that check, as it's the critical safeguard. Relying on accurate metadata to do security enforcement is weaker than just preventing the low level check.
OTOH, you make a good point in IRC that it's bad to hide ops in things like read-operation-names that can actually be invoked. The limitation in read-operation-names is based on the metadata.
Making that consistent though would mean rejecting requests if the OperationDefinition didn't report the op as being runtime-only. That would further break subsystems, particular concern being external ones not tested by our testsuite, that have problems like
WFLY-5418.That might be an ok thing to do; I'm somewhat in favor, but IMHO it's too late for that. It needs to be in an early Beta release for a Major, and really that means an EAP major, not just a WildFly one.
In HipChat you mentioned the "describe" op. That's a somewhat different case where we don't report the op in the API because it's marked private, but we make it accessible. Same thing applies to "composite". Really we should just make those public. Theres' a JIRA for doing that for "composite". The only reason I haven't done that one is a lame concern that the description for these is not "complete", i.e. the params and responses are not fully described (and can't be.) That's kind of lame though. Obviously the system is massively impaired if "composite" can't be called by a user.
If we made "composite" and "describe" public, rejecting end user calls to private methods would be more feasible. It has similar issues in terms of potential breakage and being "too late for this major" as rejecting non-runtime-only would. It should be a smaller issue, as I don't expect subsystem to have private ops that users are meant to invoke anyway. Really that's kind of a bug in the subsystem.