Ron Wheeler <rwheeler <at> artifact-software.com> writes: > > If there was an LDAP schema for portal preferences would that change > your view? >
Ron, If you mean with regards to my opinion that the user portlet preferences and the user attributes be separated out, I am not advocating that in the vanilla installation that they be kept in separate backing stores, only that the API allow for it. And I suppose that as far as the security interfaces are concerned, they do allow for this. But, what perhaps could be improved in the vanilla implementation is to make preferences and attributes handlers that are pluggable through the spring configuration, similar to the security handler SPI components. This would make it easier for folks to do what I am trying to do. In the vanilla implementation, these two handlers (preferences and attributes) could be combined into a single component referenced in two spots by the spring config, it really doesn't matter. Anyway, it's really not a big deal, maybe my requirements are not typical. As far as storing arbitrary portlet preferences in LDAP, I'm not really sure if that would work very well. If you think about the kind of RDBMS schema that would support something like this, you would make a table that is designed to store arbitrary name value pairs (ie would have a 'name' column and a 'value' column). Contrast this with the kind of thing I am looking to do with user attributes where I would (if I were using RDBMS) use a table with columns for the specific attributes (eg a column for first name, last name, email, etc). In LDAP, that doesn't really change. Typically, you can't just add whatever attribute you like to an LDAP object, it has to be added in the schema as an attribute for the object first. The same way you just couldn't add a new column to the table. (I believe that there *are* LDAP servers when configured a certain way will actually let you do this, but it is not the norm in my experience.) So, what you would need to do is either: 1. make a new object for a user preference and store the user's dn in there as well. 2. Make a user object LDAP attribute to store name value pairs using a delimiter. But getting back to the overall philosophy, typically if you are using an LDAP server to store your users, it is because it serves as an enterprise data store for users and roles for any number of applications and single sign on purposes. It does indeed get tricky as to where to draw the line between (more or less) universal user traits and application specific traits. Typically, you would want to (again, IMHO) keep the universal ones in LDAP and minimize the application specific, having those kept in application specific databases with a local mapping to the application user ID. To me, portlet preferences would definitely not make the cut. Anyhow, I guess I should probably get back to work, enough on the philosophy of enterprise authentication and SSO for one day! :) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
