Make role-based

adub - June 12, 2009 - 10:00
Project:Password policy
Version:6.x-1.0-alpha1
Component:Code
Category:feature request
Priority:normal
Assigned:Unassigned
Status:active
Description

Any thoughts on making the module (or at least password expiration) role-based? I am looking at setting up user/roles for services and it's not so good if those passwords also expire.

#1

alienbrain - September 18, 2009 - 18:34

This would be a great feature indeed. In my case, I'd like to force the policy (specifically the expiration feature) on moderators and administrators but not on normal users.

#2

kenwen - November 11, 2009 - 16:52

+1 to that. Especially useful on ecommerce sites.

I'd be willing to sponsor work for it if someone could give me details.

thanks,
Ken

#3

mrfelton - November 25, 2009 - 14:54

+1. I'd like to be able to enforce a password change on all admin users whilst leaving other users (roles) unaffected. I would also like to able to specify a password strength policy for admin users only, leaving other rolls without a policy, or possibly a different policy.

#4

deekayen - November 25, 2009 - 15:04

Where would you want role configuration to be added and how would the settings default - default expire with exemption or default exclude with inclusion.

#5

mrfelton - November 25, 2009 - 15:13

Hi @deekayen, thanks for getting back to me on this.

I think that you should be able to define multiple policies, as you can now, but that there should be an interface for assigning policies to rolls. Possibly similar to how IMCE works when assigning IMCE profiles to user roles.

I'm not quite sure I understand "and how would the settings default - default expire with exemption or default exclude with inclusion."

If password policy profiles were grouped as profiles, and explicitly assigned on a role by role basis, I don't think there would be a need for any defaults. If you don't know it already, please look at the IMCE configuration page to see what I mean regarding profiles and role assignment.

#6

bgildea - November 25, 2009 - 15:49

+1 to that

#7

deekayen - November 25, 2009 - 16:05

You can already define multiple policies and they list at admin/settings/password_policy/list. The problem is that I think you can only use one of them at a time as a global rule. I'm not sure why that is.

Is it preferable to have a page where the roles are all listed one the same screen with a dropdown option of the policy to apply to them or as a form alteration to each role configuration page (admin/user/roles/edit/16).

#8

mrfelton - November 25, 2009 - 16:18

I know that you can already define multiple policies, but to be honest I never understood the point unless you can either apply different policies to different roles, or use something like rules to determine if they should be applied or not.

I would say keep the password policy settings in the password policy configuration area. I don't know of any other modules that form alter the core role editing screen, and it may be counter-intuitive to users of passowrd policy to find half of their settings on that page. I think that a simple admin page within the admin/settings/password_policy section listing all the roles with a dropdown allowing you to assign a specific policy to each role would suffice.

#9

markevans - November 27, 2009 - 13:43

I have been having a discussion with a few people and I personally think having multiple policies is the way to go, its quite interesting how complicated it can be to achieve depending on hows its implemented.

Some of the points raised are that if multiple policies were available to be assigned on a per role basis and users can have multiple roles how do you resolve which policy should apply? We originally thought about using weighting on the policies and the highest weight would then be applied in that instance, do you's think that is the best solution though?

Also what happens when a user changes role to one with a different policy? Should their account be flagged for next login to make sure that they update their password to comply with the new policy?

Also what about auditing, should we audit when people change roles and this affects their password policy?

Currently I am just working on implementing the ability to skip password expiration based on a users role, would this be of interest to anyone if I role a patch when its completed and tested?

#10

mrfelton - November 27, 2009 - 17:27

@markevans: A patch that allows password expiration to be skipped for certain roles doesn't quite get us out of our current situation, which is that we are unable to enforce both and password strength and password change on our admin users without affecting other users. But is a step in the right direction.

Regarding the assignment of policies to roles, I think that weighting would do the trick for determining which policy gets applied. The most similar example of this I can think of is the better_formats module - which allows one input format to be applied to each role, and uses weighting to determine which one gets applied.

 
 

Drupal is a registered trademark of Dries Buytaert.