Better handling of app-level auth

[grtjn]

It would be nice if app-level auth would be handled more elegantly with deployments. As a workaround this could be used in app_specific:

  alias_method :original_deploy_src, :deploy_src
  alias_method :original_deploy_rest, :deploy_rest

  def deploy_src
    if @properties["ml.authentication-method"] == "application-level"
      change_authentication("digestbasic")
    end
    original_deploy_src
    if @properties["ml.authentication-method"] == "application-level"
      change_authentication(@properties["ml.authentication-method"])
    end
  end

  def deploy_rest
    if @properties["ml.authentication-method"] == "application-level"
      change_authentication("digestbasic")
    end
    original_deploy_rest
    if @properties["ml.authentication-method"] == "application-level"
      change_authentication(@properties["ml.authentication-method"])
    end
    change_permissions(@properties["ml.modules-db"])
  end

  def change_authentication(auth)
    r = execute_query %Q{
      xquery version "1.0-ml";
      import module namespace admin = "http://marklogic.com/xdmp/admin" at "/MarkLogic/admin.xqy";
      let $config := admin:get-configuration()
      let $config := admin:appserver-set-authentication($config, xdmp:server("#{@properties["ml.app-name"]}"), "#{auth}")
      return
        admin:save-configuration-without-restart($config)
    },
    { :app_name => @properties["ml.app-name"] }
    r.body = parse_json r.body
    logger.info r.body
    logger.info "Changed authentication to #{auth}.."
  end

[dmcassel]

That approach could be problematic for an app an server that's in active use -- ie, it would effectively disable normal use of the app server during deployment. I imagine the alternative of having Roxy log in wouldn't be as simple, though.

[grtjn]

For deploying rest extensions the only alt would be to toggle default user to rest admin or admin. Not sure that would be much better..

[dmcassel]

If you're using the REST API, you should be using a middle tier, in which case that tier can hold the credentials used for digest auth. I don't see much motivation to use app-level security with REST.

[grtjn]

Just an observation, but i see a lot of people using rest api, app level, 2-tier. I'll leave it to you and pm to convince them otherwise..

[dmcassel]

The old App Builder started a bad habit. It's analogous to exposing an ODBC connection to the world; it wouldn't be hard to convince people that's a bad idea. I don't think we should put work into Roxy that makes it easier to do this.

[grtjn]

An ml app server and an odbc connection are quite different beadts. The comparison goes wrong on various levels. Custom auth with ml has been a common thing but depends on app level auth..

[dmcassel]

App-level authentication with a 2-tier, non-REST-API application is fine. A 2-tier REST API application is a security problem, regardless of which type of authentication we choose. The REST API doesn't (and isn't meant to) provide sufficiently fine-grained control to protect content if directly exposed. A 2-tier app that uses custom endpoints should be secure; a 3-tier app where the middle tier controls access to the REST API should be secure.

I'll expand on this in a blog post.

[grtjn]

You know as well as I that applying custom auth would have been trivial if engineering would have implemented the rewriting differently (or would open up some extra hooks to it for that purpose). That would also allow a far better security control (which I would recommend, even for a 3-tier design) than the rest-api has built in right now.

Besides one might have compelling reasons to have to use app-level auth in a 3-tier design. Why should a Roxy deployer be the judge in that?

[dmcassel]

I won't be so categorical as to say there are no valid reasons to use app-level auth with the REST API in a 3-tier app (though I haven't heard one). That said, 1) it does violate the stateless intent of a RESTful API and 2) it's all to common to see 2-tier w/ REST, which I maintain is a bad practice.

We do provide a workaround via app_specific. Elevating that to a feature, which will then likely be used as part of an anti-pattern (2-tier w/ REST), doesn't seem like a good idea to me.

[grtjn]

Who says app-level auth will be used to keep state? I would never use session-fields that are tied to a host for that..

[grtjn]

See also #194

[grtjn]

Wondering if temporarily 'amping' the default-user could fix this, but that is not failsafe either.

In retrospect, I don't think it is useful to add this as general pattern, but we could consider adding this to a wiki for the few that have an explicit desire to use REST-api with app-level auth, even if it is just to allow custom login logic..

[grtjn]

https://github.com/marklogic/roxy/wiki/Switching-app-level-auth-during-deployment