4 ms·

What is the expectation for on-prem software which uses OAUTH SSO? OAUTH requires a redirect URI [1] which presents challenges for vendors wanting to sell on-p

What is the expectation for on-prem software which uses OAUTH SSO? OAUTH requires a redirect URI [1] which presents challenges for vendors wanting to sell on-prem, because it demands the customer to set up DNS as well as TLS certificates obviously. This is an ongoing challenge for us because not all shops are wild about vendors dictating these requirements. I'm very curious what other prem vendors do in this case, and what's the prem IT team's typical best case scenario here? 1. https://www.oauth.com/oauth2-servers/redirect-uris/ https://www.oauth.com/oauth2-servers/redirect-uris/

throw0101a 4y ago
> What is the expectation for on-prem software which uses OAUTH SSO? And what am I supposed to send the request to if I'm running OpenLDAP or Samba4 for accounts? If I'm running AD then there's a good chance I have Azure/cloud AD, so that's a possibility, but that could still take official IT approval. How many 'shadow IT' operations will want to run some software but can't 'official' access to account system. How much effort would it be to go through official IT channels to get something inside of an organization? Will every team that wants to use the software be willing to go through a possibly Kafkaesque process? If they can just deploy a JAR or container and fiddle with some YAML to point to and LDAP server would that reduce friction? Do you think they'd want to deal with stand-alone in-app accounts versus leveraging their existing credentials? (And perhaps only deal with in-app groups.) If a vendor wants implement something in addition to LDAP BIND they're welcome to, but the possibility of getting a simply yes/no decision for access using existing credentials gets rid of a lot of friction (and would make the auditors happy as well probably).
- imglorp 4y ago
  These are all exactly the right questions and challenges we are encountering, and we have no good answers. In all cases, customer IT would prefer vendors did not give them more work and risk. We could support LDAP instead of OAUTH, yes, but for the shops that want us to speak TLS and DNS, they still have some hassle.
  - throw0101a 4y ago
    Just to be clear: I'm asking for LDAP to be one possible choice. If an installation wants to use LDAP BIND they can use that, or if the want to use SAML they could use that, or OATH. But not at the same time: you get to choose one. Django Authentication system for example has a User object that allows different backends to feed into it: * https://django-auth-ldap.readthedocs.io/ https://django-auth-ldap.readthedocs.io/ * https://django-oauth-toolkit.readthedocs.io/ https://django-oauth-toolkit.readthedocs.io/ * https://stackoverflow.com/questions/22668434/saml-with-django-authentication https://stackoverflow.com/questions/22668434/saml-with-djang...
    - imglorp 4y ago
      Thanks for clarifying!

throw0101a 4y ago

> What is the expectation for on-prem software which uses OAUTH SSO? And what am I supposed to send the request to if I'm running OpenLDAP or Samba4 for accounts? If I'm running AD then there's a good chance I have Azure/cloud AD, so that's a possibility, but that could still take official IT approval. How many 'shadow IT' operations will want to run some software but can't 'official' access to account system. How much effort would it be to go through official IT channels to get something inside of an organization? Will every team that wants to use the software be willing to go through a possibly Kafkaesque process? If they can just deploy a JAR or container and fiddle with some YAML to point to and LDAP server would that reduce friction? Do you think they'd want to deal with stand-alone in-app accounts versus leveraging their existing credentials? (And perhaps only deal with in-app groups.) If a vendor wants implement something in addition to LDAP BIND they're welcome to, but the possibility of getting a simply yes/no decision for access using existing credentials gets rid of a lot of friction (and would make the auditors happy as well probably).

imglorp 4y ago
These are all exactly the right questions and challenges we are encountering, and we have no good answers. In all cases, customer IT would prefer vendors did not give them more work and risk. We could support LDAP instead of OAUTH, yes, but for the shops that want us to speak TLS and DNS, they still have some hassle.
- throw0101a 4y ago
  Just to be clear: I'm asking for LDAP to be one possible choice. If an installation wants to use LDAP BIND they can use that, or if the want to use SAML they could use that, or OATH. But not at the same time: you get to choose one. Django Authentication system for example has a User object that allows different backends to feed into it: * https://django-auth-ldap.readthedocs.io/ https://django-auth-ldap.readthedocs.io/ * https://django-oauth-toolkit.readthedocs.io/ https://django-oauth-toolkit.readthedocs.io/ * https://stackoverflow.com/questions/22668434/saml-with-django-authentication https://stackoverflow.com/questions/22668434/saml-with-djang...
  - imglorp 4y ago
    Thanks for clarifying!