I'm always on the lookout for alternative ways to do things and today I was thinking about how user systems (authentication, authorization etc.) are designed.
My current understanding of how HyperLogLog works: It computes a hash code for a string that maps to a bit address in a large address space.
It dawned on me that using HyperLogLog could potentially be useful for storing user authorization type of information (e.g. roles or permissions) or even predefined or boolean type settings.
Instead of going the traditional route of defining a list of roles/permissions beforehand and then creating relationships between the user and roles, we could instead just craft an unique string to represent a global or specific role or permission.
E.g. in terms of a user
- Is in an administrator role? -> administrator
- Is granted the permission to add users? add_user
- Can grant permissions for a specific entity? entity_{id}_grant_permissions
I'm certain there are some limitations in using this approach, but workarounds should be adequate to overcome the limitations. Some limitations I foresee:
- Hashing is a 'one-way' function, as such it implies that you cannot go from HyperLogLog -> role/permission, instead you will have to check roles/permissions against the HyperLogLog.
- Some databases currently have built in or addon HyperLogLog implementations that might not necessarily be interoperable (e.g. Redis, Postgres)
What's your opinion on the matter? What other limitations do you foresee?
I'm always on the lookout for alternative ways to do things and today I was thinking about how user systems (authentication, authorization etc.) are designed.
My current understanding of how HyperLogLog works: It computes a hash code for a string that maps to a bit address in a large address space.
It dawned on me that using HyperLogLog could potentially be useful for storing user authorization type of information (e.g. roles or permissions) or even predefined or boolean type settings.
Instead of going the traditional route of defining a list of roles/permissions beforehand and then creating relationships between the user and roles, we could instead just craft an unique string to represent a global or specific role or permission.
E.g. in terms of a user
- Is in an administrator role? -> administrator
- Is granted the permission to add users? add_user
- Can grant permissions for a specific entity? entity_{id}_grant_permissions
I'm certain there are some limitations in using this approach, but workarounds should be adequate to overcome the limitations. Some limitations I foresee:
- Hashing is a 'one-way' function, as such it implies that you cannot go from HyperLogLog -> role/permission, instead you will have to check roles/permissions against the HyperLogLog.
- Some databases currently have built in or addon HyperLogLog implementations that might not necessarily be interoperable (e.g. Redis, Postgres)
What's your opinion on the matter? What other limitations do you foresee?