How do perople support UserDetails.isEnabled?

[erjablow]

The UserDetails interface declares a boolean isEnabled() method. The classes that implement it have ways of setting an instance enabled variable; the User class has constructors with an enabled argument, while the LdapUserDetailsImpl/Person/InetOrgPerson classes are constructed from their Essence static nested classes and those have setEnabled(boolean) methods.

However, I'm not sure what the best way of supporting enabling and disabling sers (or locking and unlocking them). The LdapUserDetailsImpl class and its children have a nice collection of supporting classes; however, these default to ignoring enabled and locked. I guess I would have to define a custom mapper extending an associated mapper's class to call InetOrgPerson.Essence.setEnabled(boolean) appropriately. Where would this get its data? I probably would create an auxiliary object class with attributes enabled and locked. That is a bother.

How do the other readers of this forum handle enabling and locking, and what is the practical difference between disabling and locking anyway? I might just use the approach in one of the security blogs and use vote-based authorization, together with a JMX-enabled voter that holds the distinguished names of disabled users.

[tazboy78]

From the API docs, "Concrete implementations should be immutable (value object semantics, like a String)."

Seems like maybe enabling/locking is not well thought out? I would think that any implementation of enabling/locking would break the contract that requires objects to be immutable. Seems like the two are mutually exclusive?

Matthew
Brampton, ON

[erjablow]

From the API docs, "Concrete implementations should be immutable (value object semantics, like a String)."

Seems like maybe enabling/locking is not well thought out? I would think that any implementation of enabling/locking would break the contract that requires objects to be immutable. Seems like the two are mutually exclusive?

Matthew
Brampton, ON

The Person.Essence object and its friends are static nested classes. An instance of Person does not actually contain an instance of Person.Essence. Person.Essence is mutable, but Person is immutable. Person.Essence.setEnabled(boolean) exists, but Person.setEnabled(boolean) does not.

I was asking what real difference there is between a disabled Person instance and a locked Person instance. How should I mark a node in the directory as being disabled? How should I mark a node in the directory as being locked?

[Luke Taylor]

I was asking what real difference there is between a disabled Person instance and a locked Person instance. How should I mark a node in the directory as being disabled? How should I mark a node in the directory as being locked?

There is no real difference, unless you choose to make one in your application logic. Locked might mean that they have failed to authenticate correctly and have been locked out temporarily or until they are re-enabled by an administrator. Disabled may mean they have left the company but there account is still retained for administrative purposes.

It's up to you - they are really just flags which can be set on a UserDetails object and interpreted as you choose.

If you are talking specifically about LDAP then you would either have to link in to the password policy facilities of your directory server or just administer the data yourself within the directory (as you would do in a database).

There is some support in the latest trunk codebase for the LDAP draft password policy RFC as implemented in OpenLDAP.

[erjablow]

We're using client X.509 certificates, so there is no password policy. We'd have to maintain the disabled state in the directory, or use the vote-based system described in Oleg Zhurakousky's blog. I'm not sure which technique is better.

Thank you for your reply.

Respectfully,
Eric Jablow