[jboss-jira] [JBoss JIRA] (ELY-184) Update the properties KeyStore so a different type is used to distinguish between an enabled and disabled entry.

[ https://issues.jboss.org/browse/ELY-184?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-184: --------------------------------- A couple of thoughts. Historically in a UNIX password database situation, a user account could be disabled by setting the password to a "hash" with no known reverse, or by truncating it, or otherwise using a special character sequence in place of a hash. This would keep the account around but unable to login. Another option is to prepend something to the hash like "x" so that the password failed to function but the original password data was retained. These approaches are all dependent on the peculiarities of the modular crypt format, however. In a keystore the concept of enabled/disabled doesn't really exist, thus this JIRA. However I don't really think we should try to make a keystore-based password store be a fully featured thing either - overloading entries with this kind of data may open a door to rarely-used complexity that we'd rather leave shut. Whereas currently we have a simple keystore which can be simply consumed by a keystore-backed realm, with this kind of change we now have another kind of two-way interaction with key stores, which is a bit of a "smell" to me. In addition, other kinds of credentials could be stored in the keystore, and it'd be rather odd if you couldn't disable them the same way. What I'm getting at is, the functionality of the realm should generally be dictated by what's backing it. A keystore-based realm would have very limited functionality, whereas a realm backed by an IDM would have potentially much more. An LDAP or JDBC realm might fall somewhere in the middle based on how extensively the realm is configured. As a final point, using the entry type itself is a slippery slope towards a cliff in that it is potentially equally valid to encode other similar information in the same sort of way, but the type can only really be overloaded once before you have a cartesian explosion of combinations. -- This message was sent by Atlassian JIRA (v6.3.15#6346)