Pentaho

I thought you can edit the /pentaho-solutions/system/kettle/slave-server-config.xml to restrict access to the /status directive, as well as, anything else.  Note, because you are blocking the API call, there is no message, just an error that something went wrong (as if the URL did not exist).  The page will still work for those with Execute rights.

See Attached.

But after testing and going back to the page, it seems to let me in.  Might be a caching issue.  But it is a direction that might lead to a solution.  

NOTE: if you have not, you can also add the status page to the Tools menu by editing tomcat/webapps/pentaho/mantle/xul/mantle.xul and uncommmenting the entry.

Hi Stephen

Thank you for your suggestions

unfortunately like you the page was still accessible.  Flushed caches and restarted server, same.

Interestingly the default configuration lacked a binding for /status (which your sample did) and also /transStatus 
I added both, no change

I then changed require to a nonexistent role which I expected would block everyone, even admin, or force an error
 <require>org.pentaho.repository.execute2</require>
Again no change which suggests the page rendering code is not checking slave-server-config.xml

Do you happen to know where the kettle endpoints are executed/rendered?  I suspect it is somewhere in tomcat but trying to save a night of coffee and head scratching! 

Could it be a slave server configuration issue?  Running V9.3.0.0.428 with a file repository 

I believe that I may have mislead you.  As I dug in, the UNAUTHORIZED message is from line 78 of RoleBoundCarteServlet.  Which is 'com.pentaho.pdi'. [aka Enterprise Edition].

78: resp.sendError( HttpServletResponse.SC_UNAUTHORIZED, BaseMessages.getString( CLASS, "RoleBoundCarteServlet.Response.Unauthorized" ) );

The CE code which it extends, does not contain any such role checks.  This would also explain why your slave-server-config.xml did not contain these values.  

Sorry, I should have clued in earlier that role-based access and multi-tenancy would lean into EE and not a CE function. 

Closing the loop; using your test of "execute2" it does indeed restrict admin as well.

Thanks for the clarification Stephen.  I was looking at that repo earlier and trying to unravel where the permissions are read from, in one sense it's reassuring to learn I couldn't find it because it isn't there.  But that doesn't solve my problem...

Is there less granular control available in CE that would achieve the same result, assuming the fewer options in the CE slave-server-config.xml still have some functionality?

As a workaround I'm thinking of either blocking those endpoints globally from tomcat or commenting out most of the status page on the kettle side.  Those workarounds could be disabled if necessary for troubleshooting, but having an independent dev server would make that need infrequent.  Neither option is very appealing but unfortunately EE is not an option at this time.

Asking a HV person how to work around CE limitations is probably pushing my luck, but as we say here in Oz, if you don't ask you don't get!

"Asking a HV person how to work around CE limitations is probably pushing my luck" #facts

You may indeed be able to work with tomcat restrictions to limit access to those URL endpoints.  Not my skillset.  There may be options in the authentication filter chain in Spring.   I will have to defer to the community at large for samples and workarounds.

Found a solution, posting here for the benefit of others who may find it useful.  Note we're using V9.3.0.0.428 so other versions may work slightly differently

In pentaho-server/pentaho-solutions/system/applicationContext-spring-security.xml

<bean id="filterInvocationInterceptor" class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor">
    <property name="authenticationManager" ref="authenticationManager" />
    <property name="accessDecisionManager" ref="httpRequestAccessDecisionManager" />

    <!-- allow anyone to see the wsdl of various services -->
    <!--
        Note - the "Nobody" below is saying that resource URLs with those
        patterns not be available through a web call.
    -->
    <property name="securityMetadataSource">
      <!-- http://stackoverflow.com/questions/30099851/spring-security-samples-preauth-xml-example-fails-to-run#answer-30105317 -->
      <sec:filter-security-metadata-source request-matcher="ciRegex" use-expressions="false">
        <sec:intercept-url pattern="\A/kettle/status" access="Administrator" />  
        <sec:intercept-url pattern="\A/osgi/cxf/hadoop-cluster/runTests.*\Z" access="Authenticated" />

Added the following as the first rule as rules are matched sequentially.  If a more permissive rule was above then the new rule would never be applied

<security-constraint>
    <display-name>Test Kettle Status Constraint</display-name>
    <web-resource-collection>
      <web-resource-name>Kettle Status</web-resource-name>
      <url-pattern>/kettle/status</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>?????</role-name>
    </auth-constraint>
    <user-data-constraint>
      <transport-guarantee>NONE</transport-guarantee>
    </user-data-constraint>
  </security-constraint>