Support Basic auth on authentication?

[shinebayar-g]

Most popular web servers like nginx, apache supports basic auth mechanism. I think you know what I mean already.
I understand that currently script-server already supports LDAP, Google Oauth. But what If user doesn't use them? Basic auth would be most suited and simple use case here. Of course, script-server shouldn't be used without any authentication. I don't know much about basic auth's security details, but I heard if it's used with SSL it's mature enough. Projects like Grafana has great integration with basic auth. If Grafana's web interface is already protected with basic auth, grafana users don't have to enter username, password again if it's already same as basic auth's credentials and they logged in immediately. Script-server has admin, group etc already, so it would be great use case here.
basic auth supports different username and password.

$ cat /etc/nginx/.htpasswd                                 
john:$apr1$ZXg1zeDa$adzaZSxRvjHEAhbvgFebXy45q/
shinebayar:$apr1$2VzvzXkox$hm.Nx6YiZdzzajZdE3HG/

[bugy]

Hi @shinebayar-g, good point. It's somehow supported already: if you have a basic auth on reverse proxy enabled, the user credentials will be used in Script server logging.
You are right, we could go further and allow access based on these credentials. With some config option, that these credentials can be trusted indeed.
The thing is, that anyone could include fabricated basic credentials in the HTTP request and there is no easy way to validate the user. But if Script server is isolated and gets requests only through reverse-proxy, this shouldn't be an issue.

[shinebayar-g]

Ah, you mean that if someone can access script server's endpoint directly (without going through nginx right?) they could attack script-server?
I think if anyone using reverse proxy on the server they would never expose backing service directly on network. At least they'd put firewall through servers.

Example scenarios are:

• Nginx reverse proxy (port 80, public exposed + Script Server listens on localhost:5000 only)
• Nginx reverse proxy (on remote machine port 80, public expose + Script server on another machine exposed on network address:5000)

1st case is secure already, on 2nd scenario your attack vector is there right? In such case, script-server should be only accessible from nginx reverse proxy. Did i get it?

[bugy]

I see at least 3 requirements for security here:

• Script server is not publically exposed
• there is no way to have a man in the middle between reverse proxy and Script server
• reverse proxy makes sure to "clean" any fraud auth headers

I'm not that good at security, so it could be some more. But I believe these 3 are definitely required, before smth like "auth": "proxy-basic-auth" could be enabled. Together with putting reverse proxy IP in the list of Script server trusted_ips.

[shinebayar-g]

Yes yes, good point. Including nginx reverse proxy's IP in truested_ips list is also good. I didn't fully get your 3rd point. Is there any configurations should be made there?

[bugy]

Imagine somebody is sending their HTTP request, with fraud basic auth headers already present there, if reverse-proxy doesn't override/clean them and they are delivered to Script server untouched, then they will be still trusted.
I hope that shouldn't be an issue and any reverse-proxies with enabled basic auth will override these headers.

[shinebayar-g]

Is there any configs to make sure that happen? ex: on like nginx? I'm dummy.

[bugy]

Ok, probably it's my bad and misunderstanding: in case of such auth client will send an Authorization header to reverse proxy anyway. And then reverse proxy will validate the header.
If the header is invalid, the request will be rejected on reserve-proxy side.
If it's valid, then it will be forwarded to Script server, including the same Authorization header (which is desired effect in this case).

Thus, if Script server can be accessed only by reverse proxy, we can be sure, that the Authorization header is always valid (if basic auth is enabled on the proxy).
However if basic auth is not enabled on reverse proxy, it makes sense to always have this config in reverse proxy:
proxy_set_header Authorization "";

[Nottt]

I'd really like this since I never used LDAP and I have no idea of how to start using it.

I'd just like a simple basic http auth for my users. And it would be even nicer if there was a variable inside the container with the logged in user.

I have scripts that need to be supplied a username/password to work and i'd love to have them just be the login the user just made.

[bugy]

Hi, @Nottt unfortunately at the moment it's not supported (it's planned for the future, but I have much more feature requests, than I can handle)

However, there is a possibility to make this work with reverse proxy:
#219 (dev version)

So, in this case, reverse proxy will perform basic authentication of the user and send the username to Script server.

I have scripts that need to be supplied a username/password to work and i'd love to have them just be the login the user just made.
Regarding this one, it's already implemented, please check:
https://github.com/bugy/script-server/wiki/Script-config#--default

[Nottt]

An alternative could be a wiki in how to create this LDAP thing, because probably many people have no idea on how to configure one, especially using the docker...

[bugy]

Hi @Nottt, I think that running a LDAP server just for script server is a huge overhead. The idea is to use LDAP auth, only when you already have LDAP authentication in your company and then you just integrate script server into existing infrastructure.
Reverse proxy in this sense is a way lightweighter solution

[Nottt]

Oh, I do plan to put the docker behind a nginx-proxy docker.

I want my script server to be multi-user, and with each user only having access to their own scripts, how would one achieve that with a nginx reverse proxy? Is that possible currently?

[bugy]

Done. Now you can specify

"auth": {
    "type": "htpasswd",
    "htpasswd_path": "path/to/.htpasswd"
  }

It would be nice to have apache htpasswd utility installed
If it's not installed, there is built-in encryption functionality in script server. But it would require python bcrypt module, if any bcrypt password is used

[bugy]

I decided to change "type" name to "htpasswd" instead. Basic auth is a known term in HTTP authorization process. And what I implemented, has nothing to do with it

If somebody already started using it, I'm sorry

So, the proper config looks like this now:

"auth": {
    "type": "htpasswd",
    "htpasswd_path": "path/to/.htpasswd"
  }

(I edit my previous comment to avoid problems, if people would read that comment instead of the last one)

[Nottt]

Is this change live already? I restated my docker container that should auto update itself and is still working with old configuration. Not sure it's something on my end

[bugy]

Hi @Nottt, yes. It was pushed at the time when I was writing the comment

[Nottt]

Strange, it's not picking up the update, while I got the history update without doing anything. But no problem, thanks.

Did you get a chance to take a look why script server doesn't work on IOS?

[bugy]

Hi Nottt, is there a ticket for it? And do you mean iOS or MacOS? Nottt <[email protected]> schrieb am So., 22. März 2020, 12:37:

…

Strange, it's not picking up the update, while I got the history update without doing anything. But no problem, thanks. Did you get a chance to take a look why script server doesn't work on IOS? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#159 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJXPJJ4TZ4AM2O54ZOGI6DRIXZ7BANCNFSM4GQC3O3A> .

[loganati]

Hi, bugy, thanks a lot for your product.

There's a question about ldap auth, is ip address of AD server and username pattern really enough to get credentials from AD? Several servers on my network use special account to connect and authorize to AD, and only after they can use ldap auth. I tried use script server with ldap as manual says, but it doesn't work, I suppose due to server doesn't auth to AD.

[bugy]

Hi @loganati, so far server and username was enough for everyone.
But I'm not ldap expert at all (never worked with it, apart from integrating with Script server)

What kind of error do you see?