The standard Identity Manager that ships with DiF2 is a RAM-based implementation.
The objects live on the JVM memory as long as it's up. Once the JVM terminates the objects are deleted. This might look restrictive but it really isn't. The RAM-based implementation is useful for development environments or for small personal sites. See the following sub-section to learn more on the advantages of this implementation as well as to understand how it works.
Once the framework is started the code generation module read the DEM classes and processes the @AccessControl annotation. The user/group pairs supplied on the annotation are checked for existence on the Identity Manager. If they don't exist, the entries are created. As this implementation is RAM-based, there will never be any entities on the identity manager when the JVM starts and so they will always be created on the first access.
A web-based management application can also be developed to create the entities on demand.
After the creation, the entities will live on the JVM as long as it persists or until they are removed explicitly (through the web-based management application, for example). While they're available on RAM the framework can use the information for identity checking. When the JVM ceases to exist the entities die as well. As such, this implementation DOES NOT offers persistence.
This implementation forces that every user and every group have AT LEAST the ID field with a valid (ie, non-null, empty, " " or "N/A") value. If this rule is not followed new users and groups will not be added to the Identity Manager.
To learn more about this implementation check the following resources: