[keycloak-dev] Extending the Credential entity

[Mitya]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160604/cc826b89/attachment.html