[Freeipa-devel] per-group password policy proposal

[Rob Crittenden]

Dmitri Pal wrote:
> Rob Crittenden wrote:
>> Dmitri Pal wrote:
>>> Rob Crittenden wrote:
>>>> So am I on the right track here?
>>>
>>> I am not sure.
>>> I was envisioning it quite differently.
>>> The ambiguity in this case critical and might be not acceptable since 
>>> it would be hard to determine which policy should be used in case 
>>> user is a member of different groups.
>>
>> Ok, the requirement that caused me to look at was:
>>
>> * Allow setting different password policies per different 
>> (non-overlapping) groups of users.
>>
> 
> I think the requirement was worded by me under the assumption of doing 
> it the way I proposed.
> 
>>> Management of priorities is also a pain and creates complex  UI and CLI.
>>> I was more thinking about having a specific policy per user. AFAIR 
>>> the software can check the user related password policy attributes 
>>> right now without any changes to the code. There attributes just not 
>>> there. So we need to give admin the ability to set them. I was 
>>> thinking that defining password policies is a bulk operation that 
>>> updates specific users that belong to a group and creates the 
>>> attributes in the user entries. If we do it this way we would be able 
>>> to say:
>>>
>>> Password policy is XYZ.
>>> Apply this password policy to users in this group (including or not 
>>> including sub groups) for those users that do not have the policy set 
>>> or for all users in the given group.
>>> There might be other conditions for the query.
>>
>> This would be slow if a lot of users are affected.
> 
> Yes. But is is not a frequent operation so the admin should be aware.
> I think it is acceptable.

I think we'll have to test against a large user base to see what the 
impact would be.

How do you change/override a password policy? Are you proposing a switch 
that will let a user that has a policy to get a new one?

We'll also need to make extremely clear that this is a one-off 
operation. Getting added to a group itself does not set the password policy.

> 
>>
>>> In such case it is easy to control who gets the policy when the 
>>> policy is defined and easy to determine what policy is active for the 
>>> user (for audit purposes) since there is no ambiguity.
>>
>> There is no ambiguity in my method either though audit does bring up 
>> some interesting points because we don't track changes so knowing what 
>> the policy was at any given point in time is impossible.
>>
> This is exactly my point. Knowing the policy that worked and having a 
> clear change log is very important.
> One of my previous employers had the same problem with groups and policy 
> ambiguity the customers could not pass audit because of that.

There is no change log (nor a requirement for one that I know of).

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20090612/9798af0d/attachment.bin>