Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable credential-free deployment #86

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

LiptonB
Copy link

@LiptonB LiptonB commented Mar 10, 2017

In my environment I would like to be able to deploy Self Service Password without storing any LDAP credentials on the box where it's running, and I realized that in many cases the user's own credentials should be enough. This modifies the tool so that ldap_binddn and ldap_bindpw can be left unset. Just thought I would share this in case you think it would be useful to others. Thanks for a great tool!

Users should have access to view their own LDAP records and change their
own passwords, so if user credentials are available, use them. This
allows self service password to be deployed without credentials of its
own and without permitting anonymous binds.

This may not work in some situations, like if the user's account is
expired, but if that's the case there's not much we could do without
manager credentials.
@coudot
Copy link
Member

coudot commented Mar 11, 2017

Hi,

why just don't allow anonymous search on LDAP directory to find user? Is this only a security issue?

@coudot coudot self-requested a review March 11, 2017 09:31
@LiptonB
Copy link
Author

LiptonB commented Mar 11, 2017

Yes, for security reasons we'd prefer not to have anonymous searches enabled. My thought was: if the user is already providing creds that can do the search, why open it up to everyone?

@coudot
Copy link
Member

coudot commented Mar 11, 2017

We only have user credentials when user is changing password. For a reset, we don't have user password, so it won't work.

You can have a SSP account that has only search rights on directory.

@LiptonB
Copy link
Author

LiptonB commented Mar 19, 2017

True, there's no way you would be able to do a reset without the app having its own credentials. We're getting around that by just having resets disabled, but I certainly acknowledge that resets are a nice feature that is missing when deployed this way.

An SSP account with only search rights would work for us, though it still wouldn't allow resets. I don't really see the advantage, though - fewer secrets makes it easier to deploy and the app still gets all the access it needs to do self-service changes. (Although I've just realized that a bad $oldpassword now gets you ldaperror instead of badcredentials, that might not be what we want...)

Anyway, no pressure. I realize the tradeoffs we've picked might not make sense for everyone. But if you like the idea and want any fixes to the code like the error message issue mentioned above, I'm happy to make them.

@coudot coudot added this to the Future milestone Mar 20, 2017
@coudot
Copy link
Member

coudot commented Mar 20, 2017

I will see if we can include this in a future release, as this can only work with change password feature, and an LDAP directory with a single user branch

@plewin
Copy link
Member

plewin commented Mar 30, 2017

Hi @LiptonB

Yes, for security reasons we'd prefer not to have anonymous searches enabled. My thought was: if the user is already providing creds that can do the search, why open it up to everyone?

What about allowing anonymous searches only from SSP's IP address ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants