Hi,
with your help, I was just able to get OIDC running for my freshly installed instance. Thanks again!
When I then logged in via my Keycloak provider, I noticed that my Keycloak identity was not mapped to my existing Vikunja account. They share the same email address.
Is there a way to map a Keycloak identity to existing Vikunja accounts? If not, I would propose this as a feature.
Thanks!
Hi again,
this is currently not implemented, so what you’re seeing is expected behaviour. There’s no built-in way to map an existing identity to OIDC.
What would be the expected behaviour in your opinion for these cases?
Technically, Vikunja isn’t using the mail address to identify the user when logging via OIDC; rather its the combination of the sub (subject) claim which is guaranteed to be unique per identity provider and the issuer.
The approach I, personally, like the most and find the most useful is that the accounts are automatically linked or merged in a way to allow me to login to the same account locally and via OIDC.
Linking/merging could also happen when the email exists in multiple OIDC provider logins.
An email address should be unique enough to safeguard that it is the same user.
Understood. IMHO this wouldn’t be possible without a major refactor, but I’m far from fully understanding the codebase. Out of curiosity, what is the use case for you?
We’re also using a SSO / Keycloak setup in our org, and even have disabled local account creation altogether. What’s the use case behind supporting both?
I just like to be able to access my data even if my SSO provider is offline (I guess that doesn’t happen all that often but I feel safer this way).
I am just a hobbyist self hoster and sometimes one or the other service goes down for whatever reason. And, as murphy’s law predicts, this happens mostly when I am not able to repair it right away (i.e. away from home). And if this happens to my Keycloak instance and I need to access data that is accessible only after logging in via Keycloak, that would be… .
Alright, got you. Ultimately that’s for @kolaente to decide. IMHO this seems a bit like a niche use case though and it would be hard to justify bigger refactors to support it.
I’ve also not come across another implementation that allows fallback login with the same user account once SSO is enabled for it. If you think about it from a security perspective, it defeats the purpose of having SSO in the first place.
I see where you are coming from. Nevertheless, allow me to give just a few examples where you can (and where I do) have both a local and an SSO login: Nextcloud, Rocketchat, Wekan, Gitlab, Synapse. So it is not that uncommon.
For me, SSO login is not so much about security as it is about convenience. Therefore, I don’t see it as a decrease in security (especially, if one can protect the local login with a second factor).
But for the moment, it is enough for me to know that I can’t have a local and an SSO login for the same account in Vikunja. So for the time being, I will experiment with Vikunja using the SSO login but I won’t migrate my wife to Vikunja just yet (because if she weren’t able to access her lists and I can’t fix this right away, her acceptance of my self hosting all of our apps would be gone…). Which is a shame, because it is Vikunja’s migration feature that had me hoping that I could move her away from MS Todo.
Maybe in the future.
I was interested in this as well. Would you accept PR on that ?
Btw, search on issues seems to be broken on the gitea instance.
It depends on the implementation. What do you have in mind?
I would have to give it more thoughts but something like the following :
In the yaml config file for OIDC config add a new optional element “mappingproperties” (per provider)
auth:
openid:
[...]
providers:
- name: Authelia
[...]
mappingproperties:
- Issuer
- username
- email
In there (mappingproperties), we put what we want to match for the given provider (one or more, if empty apply current behaviour).
By doing so, I can keep the current behaviour for external providers, and allow email and/or username match for a provider that I manage and trust.
It could allow multiple provider email matching to the same account as well.
It is up to the admin that setup the instance to “open a security hole” since Wasabi kinda concidered it that way in previous messages.
Ok, so after digging a bit, I think I have a fairly simple solution;
Add a new key in the provider config allowing a fallback search.
Basically :
email and/or username). I would map the username to the OIDC subject i suppose.What do you think about that ?
I think that could work. Would you make the fallback permanent (= update the user account so that they will only be able to log in through openid in the future) or only at log in time?
We should make it clear that this is potentially dangerous and non-reversible, but I’d merge a change like that.
It would only be at login time, no permanent change on the local user.
The way I see it serves 2 objectives (at least for me 
) :
I agree. I just (painstakingly, just 5 minutes ago) setup the IODC in Anthelia but found this behavior. No biggie, I just exported the local account and imported into the OIDC one but now I depend on the OIDC to ever be available.
Having a way to map to the local account provides peace of mind in the moment the OIDC provider goes down/is not reachable.
Edit: As this is the behavior now, I tried to “bypass” it. Used the CLI to set a new password on the OIDC account and used the username shown in the CLI.
But upon trying to login, Vikunja gave me: “This account is managed by a third-party authentication provider.”
Just tried something 
I’m facing a similar issue with Vikunja. My Authentik instance was wiped, and now all users have different UUIDs. When users log in via OIDC, Vikunja creates a new user account, even if the email address is the same. I do have both usernamefallback: true and emailfallback: true enabled, though. An option like that to merge accounts and overwrite the local uuid of the user in the vikunja db would be much appreciated.