WIP: Auth by proxy + restricted functionalities for non-admin users

[ballfather]

Hey there.

Navidrome's guide on implementing Authentik 1 2 made me wish Audiomuse could also be easily setup with something like Authentik.

Changes:

1. Introduces "auth by proxy" mode. Relegates user/sessions management to a tool such as Authentik.
2. Ability to assign users to an admin group, giving them access to pages I've deemed "sensible". NOTE: Currently audiomuse-admin (sic) group (will change to Audiomuse-AI Admins).

Notes:

• Compatible with people not changing their configuration when upgrading. Will still work with AUTH_ENABLED defined as true, false or undefined.
• This sort of overrides/deprecates AUTH_ENABLED. Edits coming.
• Tested with Authentik but should work with alternatives.
• My usecase is a set of docker services behind a Caddy reverse-proxy. Each publically available web service (navidrome, audiomuseai, authentik, grafana, etc..) is hosted on its own subdomain.

TODO (commits coming later):

• AUTH_ENABLED Deprecation warnings (???)
• Proper setup guide for at least my usecase (Caddy + Authentik)
• Extra variables such as username and groups header names, split token, admin group name, etc..
• ???

Still WIP, may rebase.

I still need to make my case about the ENV. Edits coming.

[NeptuneHub]

Hi and thanks for this PR. I want to say that the idea is interesting but let's share some high level requirements:

• Ok to have an Admin and an User role;
  • Admin role should see everything;
  • User role I'll suggest to hide all the administration functionality, but also the Analysis/Clustering => so basically it shouldn't be able to change the status of AudioMuse-AI itself or run high computational activity. User role could be helpful also to share a demo server
• In the administration menu, a submenu to admin user is needed. So ok if you use authentik to support it, but user without Authentik should be also be able to do everything in AudioMuse-Ai. Think that big part of the user have very simple deployment.
  • You should be able to create/delete/edit an user
  • For each Music Server, the new user should also have the ability to still create playlist as "admin" OR setup his own music server user
  • An Admin can be able to edit/delete other admin user. It's important that at least an admin user remain
• It's important that all of this will work for all the music server so Jellyfin, Emby, Navidrome, Lightweight Music Server and Lyrion.
• it's important that all is documented with practical exemple. I would like to have at least example with Authentik deployed on Kubernetes and Traefik AND and example just with the use of AudioMuse-AI on a simple docker (this last one is like how most of the user use AudioMuse-AI).

A nice to have would be that user see only the library configured for his user. But this is BETTER be implemented in an FUTURE PR to not overcomplicate this.

To be ready the PR you need to share in human written word how do you addressed the above functionality and any additional functionality. You also share which test you did to proof that each of them worked on all the actual music server.

You can stay at high level in general, but I want to have low level details for everything that impact on:

• Database => like new table, new column;
• Music Server API => if you add additional call / modify the already present;

IMPORTANT: Use of AI is accepted for coding, but with the above request I want to be sure that behind the AI there is a human that give correct direction and checked the output.

Excuseme if I ask a lot of details on this but for this kind of trasversal functionality is needed. One bug here can block everything.

[ballfather]

Hello, thanks for the prompt reply. I have to head out but I can at least answer this:

User role I'll suggest to hide all the administration functionality, but also the Analysis/Clustering

That is what I went for. I had disabled access to the root page and found that i couldn't load the app anymore since the landing page was restricted :) I have gone with routing to the /chat page. This reminds me: Ability to define a default landing page, some people might like to have the app open to the /map page by default perhaps. (Will create a separate issue.)

Excuseme if I ask a lot of details on this but for this kind of trasversal functionality is needed. One bug here can block everything.

Yes absolutely. I am currently testing all cases and will take care of testing upgrades etc :)

share in human

Ah since you are testing my meatiness I am absolutely a human. Yes I have used some AI tool to help me but it was 2 minutes with opencode and 10 hours reviewing / rewriting. So for your request:

Firstly, as it stands I have phrased it as "admin" role but it is nothing more than the ability to access or not some pages. I have barely been using Authentik for a day now and just have basic auth concepts, but I know how important it is, which is why I'd rather trust Authentik and have this patch be as simple as possible so any obvious failure can stick out! Coming to the next point.

In the administration menu, a submenu to admin user is needed. So ok if you use authentik to support it, but user without Authentik should be also be able to do everything in AudioMuse-Ai. Think that big part of the user have very simple deployment.
You should be able to create/delete/edit an user
For each Music Server, the new user should also have the ability to still create playlist as "admin" OR setup his own music server user
An Admin can be able to edit/delete other admin user. It's important that at least an admin user remain

Are you asking me to implement local user management in Python? Hard pass 😨 This is why I have done this simple proxy-auth so as to have have to implement local user management :) As it stands it's not going to break any current auth configs nor would this break any further advancement into the (recently active I can see) "local" auth system. This is not a replacement, simply an optional addition.

It's important that all of this will work for all the music server so Jellyfin, Emby, Navidrome, Lightweight Music Server and Lyrion.

In theory shouldn't have any incidence there. Should only potentially improve integration for people already using a proxy-auth (following the Navidrome documentation like myself). I'll have a look if Jellyfin Emby and LMS support proxy-auth. But in theory in this case it may be "out of area of concern" (sorry for the expression).

it's important that all is documented with practical exemple. I would like to have at least example with Authentik deployed on Kubernetes and Traefik AND and example just with the use of AudioMuse-AI on a simple docker (this last one is like how most of the user use AudioMuse-AI).

My usecase is docker-compose + caddy + navidrome. I have 0 kubernetes experience. Will certainly thoroughly document my usecase!

No problem leaving this PR open for a little while ironing out everything and getting feedback. Happy to see interest in this PR. I got to go, will do my due dilligences later on! And BTW me and my friends we ❤️ Audiomuse it's so cool thnx :)

[ballfather]

@NeptuneHub also we can split the PR.

I had a little think, I understand your spefic concern. Im bringing two separate features. The auth-proxy and the "restricted pages"/"admin role".

• "restricted pages"/"admin role" is super easy to roll out with proxy-auth.
• It's not easy to roll out with a custom implementation and as you know, the risks are high.

Aware of three cases:

• you have a personal local network setup in which case auth is not important: you dont care about admin roles and access (this appears to be the philosophy this project had until the last few releases, and TBH i thought this project was always going to be "secure/expose on your own, you probably have a homelab you know what you're doing" until I saw the latest line of releases). This case is covered.
• you have a public setup but audiomuse-ai is tucked away only accesible though a tunnel for trusted users. This case is covered.
• you have a publicly available audiomuse-ai instance you want untrusted users to use but not play with sensitive things. This case appears to not be fully covered.

In anycase, I/you/we CAN totally split this PRs! (The admin role stuff comes in commits after the proxy-auth stuff)

We can have the admin role / page restriction feature only available in proxy-auth mode. We can talk about perhaps preparing for more complex and thorough types of auth like OAUTH2 etc..

[NeptuneHub]

I'm happy to brainstorm with you this PR.

The requirements that I wrote is "how a multi user management" would like in its completeness. Say that I 100% agree to do in this PR just a small piece but having in mind the full picture.

So let's tailor back a smaller scope to be more manageble but still delivering value.

• Addressing the proxy part I think is the core of your PR.
• having 2 role, and admin and user, is also ok and very useful => I was thinking at this to put on a demo server.

Avoiding to extend to much this two point BUT giving the user to address this even WITHOUT Authentik (because I have Authentik, you have Authentik, most of user not) how we can proceed?
Would we want to start with two user, one per role, addressed by env var OR Authentik if you have, and then leave an administration page for future improvement?

Like in the env var / secret you place:

• ADMIN
• ADMIN_PASSWORD
• USER
• USER_PASSWORD

and if you use Authentik you can leave the password empty and just have the auth with Authentik?

Also remember that is not only about restricting the access to some html page, but also restricting the access to the API that they call (look the different functionality have a different app*.py page with all the route).

Really thanks for your effort on this.

EDIT: Off course let me know what do you think about this proposal, having just 1 user per role in the "local" implementation with ENV var I don't think is too complex and will give the benefit also to the user without authentik. I insist of this because for a DEMO server use cases I would like to have ADMIN and USER role without having to deploy Authentik.

[rendyhd]

Hola!
I also run Authentik (w/ Traefik). Implemented group-based auth via proxy on my home page recently. Happy to test when you're at that stage.

What's the use case? You have users interested in using the explore features? If so, do you want to let any user create playlists on your media provider viewable for everyone, or do you want playlists on user account level? What did you have in mind for AI usage / token costs?

[NeptuneHub]

Here I think that the use case is simple like:

• you have an homelab;
• you deploy AudioMuse-AI and a music server in the homelab;
• You share the access to AudioMuse-AI AND the music server to your family&friends.

in this case administration functionality AND batch heavy functionality like Analysis/clustering shouldn’t be reacheable from everyone. And not only the html page but also the API.
Another use case that I have in mind is to share a Demo Server avoiding to share “distructive” functionality.

About chat functionality I think is totally an user functionality. If you don’t want to spend money you can just use a self hosted service.

The step of “each user with his own account” we said could be a next PR maybe linked to the possibility of the Ui configuration page that you’re are working on.

@ballfather if you like Jellify Discord server host an AudioMuse-AI channel here: https://discord.gg/yf8fBatktn