#6499 (In Topic #1673)
I've been using Composr for my personal website and I just decided to fire up a gaming community with numerous services including game hosting, clans, helpdesk tickets, cloud service, collaboration, etc.. Composr contains almost everything already out of the box but a few others are handy to have.
With that said, majority of sites these days have SSO systems and there are quite a few free and open source SSO's out there, namely Keycloak and FusionAuth, whom support OAuth2, OpenID Connect, and SAML. I've researched and I haven't found any modules for these services to integrate into Composr, and granted, most all in one CMS systems don't have such options considering they already contain almost everything.
But what if one wants to add a control panel of sorts? Or a helpdesk that's more robust like Yeti? A single sign on would be fantastic since Composr is geared toward a community style of CMS.
I'd like to start working on a module for a single sign on platform supporting at least one of these methods of authentication, however I'm no professional programmer, and actually quite a beginner to be honest, but if some participants from the community are interested, I'd like to develop this and place a tutorial here on the community for future, and current users who may be interested.
Most will default to Facebook or Google as authentication but my goal is those, plus a custom SSO like the aforementioned open source projects.
I'm getting over having the Flu this week so my brain is quite foggy, so I may not understand 100%.
- Are you proposing something like Keycloak becoming the main controller of user accounts, rather than Composr?
- And instead Composr logs in with something like oAuth, facilitated by Keycloak? Or perhaps it logs in, but transparently it is doing it by authenticating with Keycloak behind the scenes (similar to how we treat LDAP)?
- And that when a member joins on the Composr site it redirects to Keycloak? Or perhaps sends the details via some kind of back-end call also?
Regardless, I definitely agree more SSO capabilities in Composr would be great. I always get frustrated by the large number of 'standards' to choose from in this area though ;-).
Potentially what you want is what LDAP is already doing. I just Googled and saw Keycloak supports it. Composr's LDAP code almost certainly would need adjusting for whatever different schema Keycloak was using.
- If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
- If so, please let others know about Composr whenever you see the opportunity or support me on Patreon.
- If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying Composr on fun personal projects.
- If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
1) Yes, using an Auth System (Keycloak, FusionAuth, or similar SSO to "take over" logins) but work "with" it as for permissions sake within the existing structure with say, an API or "token" auth provided by SAML, Oauth2, or OID
2) Whichever would be easiest to implement, yet still maintain the permissions structure "per account" within composr, whilst still being compatible with the chosen auth system, see my answer to your 3rd question..
3) According to documentation on some open source auth systems (take fusionauth for example), the documentation notes that the login/registration/logout forms be redirected to the AUTH, and the AUTH panel has a redirect back to said site with a token. Because of this, it may have to be redirected to the auth like Keycloak. Then again, it would be "nice" to have it all function in the background, but that may be a bit more work to integrate, and as i said in my original post, ill definitely need help with this because im no professional at development.
Summarized, take for instance Google, you log in on gmail and in the background its actually going to "accounts.google" and when you go to youtube, your account goes with you. Yet in each of these, gmail, maps, youtube, etc, each site has one account login, yet they all have independent "permissions" or privileges, or profiles on each. And when you click "accounts" in the menu, it takes you to that auth system "accounts.google" to manage your account details, but in composr, you would manage your "profile" but have an option to manage your account should you go to the AUTH provider which, to make it easier for development purposes, each end user of composr webmasters could simply add a menu item for this, meaning less development on the overall implementation.
EDIT: not sure on the rules on link posting, but can i post a link to my "test" auth system? it is blank, and not in use as it's for this particular project, containing documentation and a working live system to test and develop with. If i can post a link to it, i can share details on here for login to the admin panel of it so we can work together. Again, it's a test system and does not contain any sensitive data.
The test system i currently have live is FusionAuth for the SSO. I'm still working on getting Keycloak working on a live scale but theres a bit more backend configuration needed to make it work with SQL as it requires a java mysql plugin to function, but when i get that live, i can post it too for development purposes.
1 guest and 0 members have just viewed this.