Welcome to Codidact Meta!
Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.
Is Single Sign On possible with Codidact?
For an on-premise (or Cloud) hosted instance of Codidact, is there existing functionality that provides Single Sign On (SSO) in conjunction with Active Directory (AD)?
1 answer
If you are already hosting a Single Sign On Identity Provider (IDP) which is linked to your Active Directory, then yes this is possible. You can follow the instructions at https://github.com/codidact/qpixel/wiki/Setting-up-SAML-Single-Sign-On.
Otherwise, we would not be talking about Single Sign On, but rather about "same-sign on" (I don't know who came up with these names...) using LDAP, which would directly support Active Directory. Unfortunately this feature is not implemented at the moment.
Really, the world of "signing in through something else" has a lot of different options and is rather confusing. Currently Codidact only support SSO/SAML (https://en.wikipedia.org/wiki/Single_sign-on) which is commonly used by larger organisations, but we could consider adding support for AD/LDAP and for OAuth2 (used for e.g. sign in via Google/Facebook).
The main differences:
Sign-in using SSO/SAML: applications forward you to a different authentication server where you type your credentials once (the application itself does not get your credentials). You will then be sent back to the application along with (encrypted) information about you. Then for the same session you will never have to type your credentials again, even when you visit other applications/sites connected to the same SSO, you will already be signed in there too (hence the SINGLE sign on).
Sign-in using LDAP/AD: you provide your credentials directly into each linked-application and every time you want to sign in. The application uses either your credentials directly to sign into the AD on your behalf (not recommended), or uses a service account to check whether your credentials are correct. This is generally the least safe approach of the 3, as a security vulnerability in any connected application could compromise the entire AD. Additionally, each application does get your credentials sent to them, which increases the attack surface. Nonetheless, this is a common connection approach for small and medium-sized organisations and is pretty widely supported by most systems.
Sign-in using OAuth: You indicate that you want to sign-in with some trusted entity (generally not managed by the same organisation) like Google or Facebook. You are redirected to them, they indicate to you what information you would be sharing, and if you accept the information about you is sent along with some encryption to ensure that it can be trusted. Like with SSO/SAML, your credentials are not sent to the application.
0 comment threads
0 comment threads