3 ms·
As a sysadmin, I simply want on-prem software to be able to take the username entered, create an LDAP DN, and try to do a simple LDAP BIND attempt against the s
by throw0101a 4y ago
As a sysadmin, I simply want on-prem software to be able to take the username entered, create an LDAP DN, and try to do a simple LDAP BIND attempt against the server:port of my choice.
And I don't want to have to create a service account for the software to do things like searches: try to do the bind, and let the person in if it works. Anything else must be optional (all the world is not AD).
- imglorp 4y agoWhat 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 agoThese 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 agoJust 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 agoThanks for clarifying!