![]() ![]() Then, upon first viewing the website I can log in and get admin access, other users login and just get the user experience. Right off the bat, the app gets deployed via a container and OIDC is configured, along with generally a group which represents admin access. Whenever I go to deploy a new app into my environment I look for how to configure OIDC. OIDC is super prevalent at this time in history. I'll try to recreate a bit of my email here. ĭang, i some how accidentally deleted my post, i hope you got a copy in an email laurent, if so please repost here. If you haven't already implemented this, maybe let this guy do it. As long as you haven't reinvented the wheel, whatever accounting library you are using might already have a plugin. turns out they use a php library for their account system which is laravel, laravel has a plugin system, and people have made plugins. I browse to it and use it, I can protect it w/ oauth2-proxy, but that only password protects it, I want other people to be able to use it also. google 'harbor' and 'oidc' to see their gui config, it's a really great gui config example, but anyone using oidc would just expect to use a config file with a few values.Īnother project I like heimdall doesn't have oidc, and yet I love it. Nextcloud has an oidc config but its overly complex, so I ended up just configuring that one with ldap, but that's the old way to do things. The protocol is pretty basic really, so simple that as you look into it you might want to implement it by hand, but its always better to just use a library so you don't have to maintain anything. I invite you to look into oidc, for my team its a prerequisite for any app to be used at work, at home of course its different and sometimes you have to make an exception if something is great but lacks the oidc support. till the configured timeout then the user has to log in. In my environment for example I have 16 apps that all use oidc so if a user changes their password its changed in all apps, also once you are logged in all the websites just work for awhile. ![]() You don't want to do local accounts though, when you have active directory with a few users you don't want to manage the credentials in every app. If an app doesn't support oidc you can use something like oauth2-proxy to wrap the website in a way to gather credentials. The app uses these to know the username, and can use the groups for permissions, such as an admin group, to grant admin privileges. The login comes along with "claims", such as "username" and a list of "groups" the user is a member of. then, after the app comes up instead of logging in with a username and password there will be a button to do the oidc login, it redirects to keycloak for credentials as it can see no one is logged in, you log in via the identity provider, it redirects back to the app and you are logged in. In that yaml file you specify the container image to use, in this case joplin-server, and some configuration such as the oidc configuration to use in my case keycloak (the upstream redhat sso solution), or azure, or any identity provider really as they all support oidc. In a modern kubernetes setup, kubernetes being a container management system, along with a gitops setup (using either argocd or flux), you confgure the appliction deployment using a yaml file. and have ended up here, this post is 6 months old so i'm hoping it has already been integratedĮverything web-related is pretty much expected to have oidc support. Oidc is incredibly prevalent out in the world at this time in history, as i look into joplin to see if i might onboard it into my environment, as with all web apps i first check if it is oidc compatible. I use Seafile, which doesn't support SSO for WebDAV there's no Android client that actively syncs filesystem to Seafile with SSO credentials, so I can't use filesystem sync and Joplin Server doesn't yet support SSO.) (As an aside, this came about bc I couldn't find an acceptable way to sync Joplin notes with the sync targets when using SSO. Just tinkering, I've got OIDC login working, but don't want to code up the app password hashing/storage/UI/&c. SSO users would then use the app passwords for authentication in the Joplin clients. Would maintainers be open to a PR adding OpenID Connect support to Joplin Server? The idea would be to have a "Or log in with single sign-on" link on the login page, then an "App Passwords" section of the user form/profile page. I want to self-host Joplin Server for my own use, but I use single sign-on for all my self-hosted apps. I guess this is kind of a feature question as well, I suppose. ![]() (I posted this to Features, but I think it might've gotten buried.) ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |