Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Users Search
Help Dashboard Sign In Sign Up
Q&A Blog
Q&A
Posts Tags Edits
Ask Question

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.

Post History

81%
+7 −0
Q&A Is Single Sign On possible with Codidact?

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/codid...

posted 1y ago by Taeir‭  ·  edited 1y ago by Taeir‭

Answer
#5: Post edited by user avatar Taeir‭ · 2023-07-05T09:58:01Z (over 1 year ago)
  • 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.
  • **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.
  • 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.
#4: Post edited by user avatar Taeir‭ · 2023-07-03T14:35:34Z (over 1 year ago)
Small clarification for OAuth
  • 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.
  • **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.
  • 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.
  • **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.
#3: Post edited by user avatar Taeir‭ · 2023-07-03T14:33:17Z (over 1 year ago)
  • 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 smaller organisations.
  • **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.
  • 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.
  • **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.
#2: Post edited by user avatar Taeir‭ · 2023-07-03T14:15:22Z (over 1 year ago)
  • 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**: 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 smaller organisations.
  • **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.
  • 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 smaller organisations.
  • **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.
#1: Initial revision by user avatar Taeir‭ · 2023-07-03T14:14:22Z (over 1 year ago) 
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**: 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 smaller organisations.

**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.