Add SSO auth

[n1ght-hunter]

hi just wondering if you had any interest in supporting any sort of SSO

[karlomikus]

Hello,
It's definitely something I would like to have in future, but I'm prioritizing other features first.

[n1ght-hunter]

ah ya thats fair

[shotor]

Hello, It's definitely something I would like to have in future, but I'm prioritizing other features first.

@karlomikus you mind if I take a stab at this? I want to run barassistant but sso is a must for me.

I can add oidc.

[karlomikus]

Sure, give it a go

[n1ght-hunter]

probably worth using
https://github.com/thephpleague/oauth2-client
it seems popular
example
https://oauth2-client.thephpleague.com/usage/

[phillf]

@shotor, is there any forward momentum on implementing OIDC?

I echo your sentiment that lack of OIDC is a blocker for deploying this.

[skjdghsdjgsdj]

Adding my +1 to this. I'm attempting to consolidate all the services on my network with Authentik to reduce the number of logins my users need.

[skjdghsdjgsdj]

There's an easier but clunky solution: Bar Assistant could be configured, not by default, to trust a specific HTTP header that contains the user logged in by SSO. For example, an Authentik proxy sets an X-Authentik-Username HTTP header of the currently logged in user, so if Bar Assistant sees this header in the request, it should assume a local user with that username is logged in.

There are UX drawbacks to this, but it's an easier development lift than a full ODIC implementation I'd imagine.

I emphasize it should not do this by default because otherwise any external request could spoof authentication. But request proxied via the SSO strip out the header and manage it themselves, so it's safe in those scenarios.

[skjdghsdjgsdj]

Another option, this one even simpler: add a config option to just automatically log in as a specific user. Then an SSO proxy can handle the authentication and Bar Assistant doesn't need to care. This results in one shared user, but it fits my use case just fine and I imagine other people too.

I now have 12 of my network services in Authentik and Bar Assistant is the only straggler that I can't set up with SSO 😢

[phillf]

Another option, this one even simpler: add a config option to just automatically log in as a specific user. Then an SSO proxy can handle the authentication and Bar Assistant doesn't need to care. This results in one shared user, but it fits my use case just fine and I imagine other people too.

Assuming each Bar Assistant has their own ingredient/cocktail library, not having the separate libraries is the only drawback I see with this approach. I think it's a reasonable tradeoff though.

The one thing that's been nagging me with this is if individual libraries aren't a thing and there aren't plans to have that be a feature then why is there native auth in the application in the first place? If there aren't reasons to tie certain datasets to specific users then there shouldn't be auth. At that point I see this as something like an it-tools situation where it just exists on the network for anyone to access and if you want to "secure" it you can but by default it's not a thing. I maybe be crazy for thinking this.

[karlomikus]

A feature like SSO is not something you just add and it works. It requires ongoing maintenance and introduces potential issues that can be challenging to debug because it will heavily depend on user's infrastructure and setup. I'm not saying it will never come, but It's not a priority now, and I'm not interested in quick workarounds.

Assuming each Bar Assistant has their own ingredient/cocktail library, not having the separate libraries is the only drawback I see with this approach. I think it's a reasonable tradeoff though.

Not sure what you mean with this, but every user can have it's own ingredient shelf in existing bar, share his shelf or open and mange a new bar with his own cocktails.

[skjdghsdjgsdj]

So let's recap options:

Option	Benefits	Downsides
Native OpenID Connect	Best UX, most flexible, most native implementation. Users who try to change passwords or log out would go to the SSO's equivalents instead. Conceivably the SSO could even manage authorization within Bar Assistant with scope mappings.	Most complex to implement, not needed by most users, even those with SSOs
Proxy, pass special header for username	Easy to set up in SSO like Authentik's X-Authentik-Username header with modest updates to Bar Assistant's authentication system instead of sweeping changes	Requires administrators enable this functionality explicitly otherwise a bad actor can pass the header and log in as anyone.
No SSO, always log in as a specific user	No SSO to bother with for authorization, just authentication, likely easy to implement	Hackiest solution, by its definition only allows a single user

Of the options, the second one seems the best compromise: users desiring local authentication don't need to change Bar Assistant at all, and those who do want SSO don't need to change much.

The flow would be:

• Client makes an HTTP request
• Server reviews the request.
  • With no username HTTP header, or if (as by default) the option to log in via HTTP header is disabled, the current authentication flow continues.
  • If the username HTTP header exists, like X-Authentik-Username or something else an administrator has defined, then:
    • If the user exists in Bar Assistant, log in automatically as that user.
    • If the user does not exist, create one dynamically with a strong random password, then log in as that user.

An existing administrator would manage the SSO user's permissions, much as an admin today needs to manage other local users, because for all intents and purposes, an SSO user is a local user, just one who has a different authentication flow.

Some useful tweaks to apply when a user is logged in via the HTTP header:

• Disallow the user to change password as it's managed by SSO.
• Hide the logout link, or allow an administrator to change the URL for logout so they can specify the SSO's logout URL.

API users can whitelist the API endpoints in the SSO so just tokens are respected as they are today.

[shotor]

I'm just revisiting this and am starting work on this now, didn't have time before.

@karlomikus

A feature like SSO is not something you just add and it works. It requires ongoing maintenance and introduces potential issues that can be challenging to debug because it will heavily depend on user's infrastructure and setup. I'm not saying it will never come, but It's not a priority now, and I'm not interested in quick workarounds.

Yes, the main burden is maintaining the security of the solution. OIDC libraries are however fairly mature and most of the maintenance will be updating the used library in case it has a security vulnerability.

Proxy auth as proposed by @skjdghsdjgsdj is a bit trickier. You have to lock down the trusted proxy ips and I don't know what other considerations are needed. Case in point: An app I use just got updated to address a security vulnerability with their proxy auth implementation and to me the thing they changed seemed benign.

I'm fine with maintaining a fork, so I'm going to just build it. Then you can see it and we can discuss it. If you like it, keep it,.

@skjdghsdjgsdj That's a great comparison, and you're right about the implementation complexity being higher with OIDC. For me the more manageable security burden, the added flexibility of OIDC and my lack of experience with implementing proxy auth is why I favor that approach.

If in the future someone wants to add proxy auth to it, then the User Creation on external auth feature may be re-used. I'll have to implement that for OIDC auth in any case.

[phillf]

I'm just revisiting this and am starting work on this now, didn't have time before.

When you get to the point of testing it I will grab your fork and write the documentation that way it can merged in to @karlomikus's repo together.

[shotor]

Update see draft PR:
#402