You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Extracting credentials to a separate storage area
#11164
At the last meeting of the storage group, we were talking about extracting ComponentModel out of the realm. The reason is that components are often used without the need for loading all realm details and vice versa.
This led me to think about the same with users and credentials. I don't have any analysis of this, but I think it may simplify some things around the work on LDAP user store. @ahus1 have you been thinking about this?
Thanks for raising this. I haven't thought about this yet.
Having these two independent would also break the transactional boundary that keeps these two together. Here are my thoughts:
In order to have credentials separate from a user (and also handling them in separate transactions), they would need be independent. That is: the fields stored in the user are independent/don't relate to newly created or updated credentials. Also the different credentials should relate to each other when creating new ones and updating existing. The same would need to be true when validating if a user should be allowed to log in.
There would need to be at least some constraints, as some credential types must appear only once (only one password per user, but maybe multiple password history entries). I don't know if some credential types can only be enabled for certain states in the specific user entity, and if we would run into problems when using a new user with old credentials or vice versa.
I could see that something like that would allow for a more fine grained data model for example in JPA or Infinispan. One would usually still load the user, and then only the credentials when needed.
Looking at this from an LDAP perspective, changing this wouldn't help the implementation, at least not from what I see.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
At the last meeting of the storage group, we were talking about extracting
ComponentModelout of the realm. The reason is that components are often used without the need for loading all realm details and vice versa.This led me to think about the same with users and credentials. I don't have any analysis of this, but I think it may simplify some things around the work on LDAP user store. @ahus1 have you been thinking about this?
All reactions
Replies: 1 comment
Uh oh!
There was an error while loading. Please reload this page.
Thanks for raising this. I haven't thought about this yet.
Having these two independent would also break the transactional boundary that keeps these two together. Here are my thoughts:
In order to have credentials separate from a user (and also handling them in separate transactions), they would need be independent. That is: the fields stored in the user are independent/don't relate to newly created or updated credentials. Also the different credentials should relate to each other when creating new ones and updating existing. The same would need to be true when validating if a user should be allowed to log in.
There would need to be at least some constraints, as some credential types must appear only once (only one password per user, but maybe multiple password history entries). I don't know if some credential types can only be enabled for certain states in the specific user entity, and if we would run into problems when using a new user with old credentials or vice versa.
I could see that something like that would allow for a more fine grained data model for example in JPA or Infinispan. One would usually still load the user, and then only the credentials when needed.
Looking at this from an LDAP perspective, changing this wouldn't help the implementation, at least not from what I see.
All reactions