#7388 Allura's LDAP provider password managing improvements

v1.2.0
closed
nobody
42cc (432)
General
Dave Brondsema
2015-08-20
2014-05-13
Igor Bondarenko
No
  • in set_password handle case, where old password is not provided ([#7342] for reference). Use admin credentials for LDAP in this case.
  • Enable forgotten_password_process for LDAP provider
  • Store hashed password (algorithm in [#7342]). Algorithm, # of rounds and salt length should be .ini options

Related

Tickets: #7387

Discussion

  • Igor Bondarenko - 2014-05-13
    • labels: --> 42cc
    • status: open --> in-progress
     

  • Igor Bondarenko - 2014-05-13
    • summary: #7387 Allura's LDAP provider password managing improvements --> Allura's LDAP provider password managing improvements
     

  • Igor Bondarenko - 2014-05-13
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,3 +1,3 @@
-- in `set_pawwsord` handle case, where old password is not provided ([#7342] for reference). Use admin credentials for LDAP in this case.
+- in `set_password` handle case, where old password is not provided ([#7342] for reference). Use admin credentials for LDAP in this case.
 - Enable `forgotten_password_process` for LDAP provider
 - Store hashed password (algorithm in [#7342]). Algorithm, # of rounds and salt length should be `.ini` options
     

  • Igor Bondarenko - 2014-05-16

    While working on this I've discovered that user_prefs.html and relevant controller does checks like this:

      {% if tg.config.get('auth.method', 'local') == 'local' %}

    Because of them /auth/preferences/ is almost empty, when using LDAP auth provider. I.e. you can't set display name, email, etc.

    I guess, this is because sfx auth method provides those settings through legacy part of sourceforge?

    To test forgotten password recovery capabilities I've changed condition to != 'sfx'.

    I wonder if this change should be commited? Maybe Allura instance on sourceforge would also rely on legacy part to provide those, but I think these preferences should be available for other deployment too, even when using LDAP auth.

     

  • Dave Brondsema

    Dave Brondsema - 2014-05-16

    Good catch. I think we'll need deeper updates to make it really work well with LDAP though. LDAP will often provide names and email addresses, and may or may not let users change those within Allura (e.g. have to change it somewhere else in LDAP directly). So this will probably have to be configurable for each provider, and likely some additional methods or hooks to keep LDAP (or any other auth store) in sync with Allura changes if allowed. Lets handle that in a separate ticket. I can create one in a while.

    For now lets just keep it as-is for name and email. Few others like password recovery I think is fine to change to != 'sfx' (And then we can clean up the 'sfx' references later, once we get rid if it)

     

  • Igor Bondarenko - 2014-05-19

    Closed #591. je/42cc_7388

    Also fixes [#7387].

    New config options:

     auth.ldap.password.algorithm = 6
 auth.ldap.password.rounds = 6000
 auth.ldap.password.salt_len = 16
     

    Related

    Tickets: #7387

  • Igor Bondarenko - 2014-05-19
    • status: in-progress --> code-review
     

  • Dave Brondsema

    Dave Brondsema - 2014-05-23
    • status: code-review --> closed
    • QA: Dave Brondsema
    • Milestone: limbo --> forge-may-30
     

  • Dave Brondsema

    Dave Brondsema - 2015-01-05
    • Milestone: unreleased --> asf_release_1.2.0
     

Log in to post a comment.