I have some design issues with UserProfileModule implementation First to clarify some things: 1) UserProfileModule is supposed to be an interface for access to User properties: | public Object getProperty(User user, String propertyName) | public void setProperty(User user, String name, Object property) | public Map getProperties(User user) | Main idea was to give some abstraction and enable to to mix implementations - i.e LDAP UserModule implementation and Hibernate UserProfileModule implementation. In ldap user properties are mapped to entry attributes. 2) Currently (in 2.4) with Hibernate implementation user porperties are stored in a Map mapped to a table "jbp_user_prop" The issue is that the table is related to "jbp_user" using surrogate key. The first thing was to specify which fields User object must have. As I described here I decided that minimum fields are: userName, realEmail, enabled. The reason of this is simply because not every field can be mapped to attribue that occurs in default LDAP schema. Model for User must be consistent for both DB and LDAP. The rest of information related to the user should be obtained using UserProfileModule (like familyName, signature, phone, icq, skype and etc.) The issue is that from the properties types defined in User interface many don't have proper attribute types in LDAP schema. And some of them are used by portal core features (theme, last login date, registered date...) This means that it's impossible to have truly LDAP only implementation of UserProfile that is based only on LDAP attributes. This also means that in current portal design, mapping properties to LDAP attributes must be optional ? if one is not mapped it must be persisted anyway by portal. Implementation should be transparent so not to limit the possible properties . This will act like two levels of properties persistence. The main issue here is that we can't simply use the 'jbp_user_prop' table as it uses User surrogate key managed by hibernate. We also want to avoid db schema changes in portal 2.6 as for now this would be the only change Few ideas for the LDAP implementation: 1)Make separate table like 'jbp_ext_user_prop' and map properties there using 'userName'. This should be in separate SessionFactory, independent from current identity schema. The LDAPUserProfileModuleImpl will just check if the mapping exist for LDAP attribute and if no store/retreive property in database The HibernateUserProfileModuleImpl will use existing schema. pros: it's the simplest way cons: we end up with two tables that does the same 2)Make use of existing 'jbp_user_prop'. LDAPUserProfileModuleImpl will create empty instance of user if it doesn't exist in database and then use it to store properties. Pros: we reuse the existing schem cons: there is an overhead for user creation in DB If we chose the first option and someone keeps users in both ldap and DB (for authentication purposes) and then switches identity between Hibernate/LDAP - user properties are lost. My option is the 1) one anyway as it's not intrusive for schema and simple. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987073#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...