[salt-api] Provide a trusted_auth or remote_user mode in salt-api

[arthurzenika]

We want to authenticate using kerberos to the salt-api.

The easiest and shortest way that we can think of (and a method we use quite often on other applications) is to have nginx or apache handle the keberos authentication and pass on a remote user header to the localhost listening salt-api. The salt-api then needs to have a mode where it trusts the remote-user header and sends back a token.

An example of this type of workflow is documented here http://flask.pocoo.org/snippets/69/ or here https://docs.djangoproject.com/en/1.8/howto/auth-remote-user/

I'm not sure how it's done, but I think you can probably do it with pipeling wsgi middle wares that handle authentication such as the http://docs.pylonsproject.org/projects/pyramid/en/latest/api/authentication.html#pyramid.authentication.RemoteUserAuthenticationPolicy in pyramid.

Any chance of seeing this in salt-api ? if so where ? any recommendations on where we could insert such an implementation to propose a pull request ?

[whiteinge]

I am not familiar enough with Kerberos to know where it would fit in. I'm definitely interested in exploring that though.

Would it work as a regular Salt auth module? I'm fuzzy on where in the pipeline Kerberos sits exactly.

If it would work as a Salt auth module, there are three possible workflows.

Option 1

1. You hit salt-api's /login URL as normal and specify the (to be written) 'kerberos' backend along with a username/password.
2. The authentication credentials are sent to whatever Kerberos server you have configured which then returns a regular Kerberos token to Salt.
3. Salt generates it's own "session" token and returns that as the response to the request to /login.
4. That Salt token is used on subsequent requests to Salt.

Option 2

1. You log in to a Kerberos server externally to Salt in order to get a Kerberos token.
2. You send that token to the salt-api /login URL as normal, which then checks it with the Kerberos server and generates a Salt "session" token.
3. That Salt token is used on subsequent requests to Salt.

Option 3

1. You log in to a Kerberos server externally to Salt in order to get a Kerberos token.
2. You use the /run salt-api endpoint to bypass Salt's session tokens and you send the Kerberos token with each request.
3. Salt uses that token to check with the Kerberos backend on each request.

Do any of those sound compatible with the Kerberos workflow?

[arthurzenika]

There are many places where Kerberos could be plugged in. I think each one of your use cases could be described in an issue.

Option1 is probably not a good idea, and doesn't really correspond to the kerberos workflow. The only tool you want to give your kerberos password is the "kinit" tool. It then negotiates with services that support that authentication (ssh, apache, nginx, nfs, etc.)

Option 2 & 3 are indeed "compatible" with the kerberos approach. That would be great if they were introduced, it's just more expensive ;-)

This present issue is a solution that does not involve any kerberos specific implementation in the salt code. We delegate the authentification to a frontend (apache or nginx for example). Once this "trust the remote user" is in place, one can use any authentication supported by the frontend (ntml for windows, ldap, basic/password, pam, kerberos, etc.). One can even have an in-house auth module.

[whiteinge]

If putting together an auth module would work (options 2 & 3), that would probably be easiest. It would require no changes in Salt core and auth modules can be quite small.

If I understand the Django docs explanation of how the REMOTE_USER thing is supposed to work we would still need an auth module in place to check the token. In fact, the workflow for X-Auth-User they mention at the end sounds identical to what we have now with X-Auth-Token. Please correct me if I am mistaken.

[arthurzenika]

As you can see, here is some code to discuss this issue. This is a (works-for-me) implementation of the trust remote user. My knowledge of master.py is not suffisent to know the consequences of such a patch (it might open up everything for a all I know!).

Let's put aside the kerberos auth for the moment (I'll go out and create a new issue for that).

[aboe76]

Did anybody think of freeipa solution? I found this blog post on how to do a kerberos webcall in python
http://adam.younglogic.com/2014/02/freeipa-web-call-from-python/

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.