Hi,

1. I've implemented a custom JPA entity, let's call it DeviceEntity (by making direct changes to the org.keycloak.keycloak-model-jpa module, as Entity SPI is not yet available). Now I want to have an entity, let's name it DeviceCredentialEntity, that would inherit from CredentialEntity an would extend it in the follwing ways:

 a) it would reference DeviceEntity in a many-to-one manner (one device supplies several credentials);

 b) it would introduce a lockout mechanism (if a device is lost/stolen, all its credentials should be locked out), maybe a boolean field.

All the custom functionality (assigning devices, locking/unlocking) will be handled by my extensions; otherwise, device credentials should behave identically to normal ones.

I see two ways of implementing this:

- extending CredentialEntity directly, adding necessary fields and making DeviceCredentials live in a separate table. This design is fairly straightforward, but it will introduce additional SQL and probably modifications to authenticator (to support per-credential locked-out bit);

- not creating a dedicated entity, but rather emulating many-to-one with many-to-many relationship (intermediate table between devices and credentials + unique constraint on credential ID) and emulating locked-out status by setting credential type to something invalid. This is less clean, but also less intrusive, as it will require no modifications to authenticator.

Which way is better at the moment (v1.9.7)? Will the upcoming v2.0.0 + Entity SPI address problems like this?

2. Imagine the storage contains a lot of CredentialEntities with user field set to null (in other words, a pool of non-owned credentials available for enrollment). Wouldn't it break the system? Wouldn't these entities be considered orphaned and be "scavenged" by some kind of cleanup process?

Thanks!

Mitya