You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Aaron Evans <aa...@yahoo.ca> on 2005/11/22 19:53:18 UTC
j2 - storage of user attributes
I have implemented a custom security SPI to use our ldap schema for
users, groups and roles. I would now like to also have user attributes
stored and retrieved to/from LDAP.
Could someone tell me which interface I need to implement and which spring
config component to change?
I started poking around, but couldn't find it.
thx,
aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: j2 - storage of user attributes
Posted by Aaron Evans <aa...@yahoo.ca>.
Ron Wheeler <rwheeler <at> artifact-software.com> writes:
>
> I gather, from what I read on the Apache site, that Apache DS is not as
> performant as OpenLDAP which seems to be capable of handling large
> structures and high transaction rates.
>
> I did find this reference
> http://portals.apache.org/jetspeed-2/multiproject/jetspeed-security/ldap.html
>
> It seems to be a bit short on details about what needs to be done. There
> is a big effort underway to improve the documentation. Perhaps your
> questions will help focus on what needs to be added here.
>
> Ron
>
Ron, I have looked at this and am aware of the work David has been doing.
However, so far (AFAIK) the LDAP implementation is limited to authentication
and does not handle roles and groups.
Anyway, this stuff seems to be quite separate from the storage of user
attributes.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: j2 - storage of user attributes
Posted by Ron Wheeler <rw...@artifact-software.com>.
I gather, from what I read on the Apache site, that Apache DS is not as
performant as OpenLDAP which seems to be capable of handling large
structures and high transaction rates.
I did find this reference
http://portals.apache.org/jetspeed-2/multiproject/jetspeed-security/ldap.html
It seems to be a bit short on details about what needs to be done. There
is a big effort underway to improve the documentation. Perhaps your
questions will help focus on what needs to be added here.
Ron
Aaron Evans wrote:
>Ron Wheeler <rwheeler <at> artifact-software.com> writes:
>
>
>
>>Did you build a custom schema for this?
>>What does it look like?
>>
>>Ron
>>
>>
>>
>
>At the moment, I'm developing against Sun ONE but I plan on switching to either
>Open LDAP or Apache DS in the near future.
>
>So, I have just created extensions to the standard Sun ONE inetorgperson,
>nsmanagedroledefinition and groupofuniquenames objects (users, roles and
>groups respectively). I extended them so I can add my own custom attributes.
>
>If you are unfamiliar with this schema, inetorgperson has an nsrole attribute
>for storing one or more references to roles to which the user belongs.
>A groupofuniquenames object has a uniquemember attribute for storing one or
>more references to users that belong to the group (the latter being a little
>backward, but this is the way it has always been).
>
>In addition, I'm storing users in our own hierarchy of companies and then
>groupings within those companies, so the DN of a user is constructed to
>reflect this.
>
>So, any idea what I need to do to have user attributes stored in LDAP?
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: j2 - storage of user attributes
Posted by Aaron Evans <aa...@yahoo.ca>.
Ron Wheeler <rwheeler <at> artifact-software.com> writes:
>
> Did you build a custom schema for this?
> What does it look like?
>
> Ron
>
At the moment, I'm developing against Sun ONE but I plan on switching to either
Open LDAP or Apache DS in the near future.
So, I have just created extensions to the standard Sun ONE inetorgperson,
nsmanagedroledefinition and groupofuniquenames objects (users, roles and
groups respectively). I extended them so I can add my own custom attributes.
If you are unfamiliar with this schema, inetorgperson has an nsrole attribute
for storing one or more references to roles to which the user belongs.
A groupofuniquenames object has a uniquemember attribute for storing one or
more references to users that belong to the group (the latter being a little
backward, but this is the way it has always been).
In addition, I'm storing users in our own hierarchy of companies and then
groupings within those companies, so the DN of a user is constructed to
reflect this.
So, any idea what I need to do to have user attributes stored in LDAP?
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: j2 - storage of user attributes
Posted by Ron Wheeler <rw...@artifact-software.com>.
Did you build a custom schema for this?
What does it look like?
Ron
Aaron Evans wrote:
>I have implemented a custom security SPI to use our ldap schema for
>users, groups and roles. I would now like to also have user attributes
>stored and retrieved to/from LDAP.
>
>Could someone tell me which interface I need to implement and which spring
>config component to change?
>
>I started poking around, but couldn't find it.
>
>thx,
>aaron
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Pre-defined accounts in j2
Posted by Aaron Evans <aa...@gmail.com>.
As I recall, I the default admin account is admin/admin.
The pre-defined accounts are listed here:
http://portals.apache.org/jetspeed-2/getting-started.html#Default_installed_user_accounts
There is some documentation at http://portals.apache.org/jetspeed-2/. There
is also some included with the source.
The contributors are working on creating more documentation as we speak
getting ready for J2 final.
On 11/30/05, Athanasis Nikolaos <at...@geo.aegean.gr> wrote:
>
> Hello,
>
> I have problems to login as admin user in jetspeed-2.
>
> I have worked with jetspeed-1, and the admin password was "jetspeed".
>
> But, when i write this to j2 (in order to login as administrator), I get
> a:
> Invalid password.
> Warning: only one login attempt remains for this account
>
> Are there any other predefined accounts?
>
> And something else:
> Where can I find documentation about j2? (like a tutorial --- any j2 books
> available???).
> In jetspeed-1 there was a tutorial and explained the basic features of it.
> Is something like that available for j2?
>
> Thank you for your attention,
>
> Athanasis Nikolaos
> Postgraduate Student
> University of the Aegean
> Department of Geography
> University Hill
> 81100 Mytilene, GREECE
> TEL +30-22510-36437
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
Re: Pre-defined accounts in j2
Posted by Philip Mark Donaghy <ph...@gmail.com>.
On 11/30/05, Athanasis Nikolaos <at...@geo.aegean.gr> wrote:
>
> Hello,
>
> I have problems to login as admin user in jetspeed-2.
Use the login admin which has administrative permissions. It's password is
admin.
I have worked with jetspeed-1, and the admin password was "jetspeed".
>
> But, when i write this to j2 (in order to login as administrator), I get
> a:
> Invalid password.
> Warning: only one login attempt remains for this account
>
> Are there any other predefined accounts?
user manager password manager has manager and user permissions
user jetspeed password jetspeed has manager only permissions
user user password user has user only permissions
And something else:
> Where can I find documentation about j2? (like a tutorial --- any j2 books
> available???).
> In jetspeed-1 there was a tutorial and explained the basic features of it.
> Is something like that available for j2?
>
> Thank you for your attention,
>
> Athanasis Nikolaos
> Postgraduate Student
> University of the Aegean
> Department of Geography
> University Hill
> 81100 Mytilene, GREECE
> TEL +30-22510-36437
>
>
--
Philip Donaghy
donaghy.blogspot.com del.icio.us/donaghy/philip
Skype: philipmarkdonaghy
Office: +33 5 56 60 88 02
Mobile: +33 6 20 83 22 62
Pre-defined accounts in j2
Posted by Athanasis Nikolaos <at...@geo.aegean.gr>.
Hello,
I have problems to login as admin user in jetspeed-2.
I have worked with jetspeed-1, and the admin password was "jetspeed".
But, when i write this to j2 (in order to login as administrator), I get a:
Invalid password.
Warning: only one login attempt remains for this account
Are there any other predefined accounts?
And something else:
Where can I find documentation about j2? (like a tutorial --- any j2 books available???).
In jetspeed-1 there was a tutorial and explained the basic features of it.
Is something like that available for j2?
Thank you for your attention,
Athanasis Nikolaos
Postgraduate Student
University of the Aegean
Department of Geography
University Hill
81100 Mytilene, GREECE
TEL +30-22510-36437
Pre-defined accounts in j2
Posted by Athanasis Nikolaos <at...@geo.aegean.gr>.
Hello,
I have problems to login as admin user in jetspeed-2.
I have worked with jetspeed-1, and the admin password was "jetspeed".
But, when i write this to j2 (in order to login as administrator), I get a:
Invalid password.
Warning: only one login attempt remains for this account
Are there any other predefined accounts?
And something else:
Where can I find documentation about j2? (like a tutorial --- any j2 books available???).
In jetspeed-1 there was a tutorial and explained the basic features of it.
Is something like that available for j2?
Thank you for your attention,
Athanasis Nikolaos
Postgraduate Student
University of the Aegean
Department of Geography
University Hill
81100 Mytilene, GREECE
TEL +30-22510-36437
Re: j2 - storage of user attributes
Posted by Aaron Evans <aa...@yahoo.ca>.
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: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: j2 - storage of user attributes
Posted by Ron Wheeler <rw...@artifact-software.com>.
If there was an LDAP schema for portal preferences would that change
your view?
I am attracted to the idea of a single data repository but do not know
enough yet to know how hard that would be to implement or whether it
would be more grief than benefit.
Microsoft has certainly put a lot of its data into Active Directory and
the Windows Registry which are both hierarchical
rather than relational. Searching is not as easy as with a relational
database but the access is down a line of keys LDAP seems pretty fast
and it seems easy to provide useful tools which are not application
specific.
Ron
Aaron Evans wrote:
>Furthermore, if I understand correctly that user portlet preferences
>and user traits/attributes are both being stored in this medium, IMHO, I think
>that these should be seperated out.
>
>The storage of portlet preferences involves storing arbitrary keys and values.
>But user attributes are generally going to be made up of a list of fixed
>attributes for a specific portal implementation (eg. email address, first
>name, last name and a whole host of other information that will be necessary
>to maintain).
>
>At least in my case anyway, I am not interested in storing portal preferences
>in LDAP as the schema will not really allow for this. However, I do want
>to maintain all the other fixed user traits in LDAP and have them loaded by
>the user manager to possibly be made available to portlet applications.
>
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: j2 - storage of user attributes
Posted by Aaron Evans <aa...@yahoo.ca>.
David Sean Taylor <david <at> bluesunrise.com> writes:
>
> We *can* change the API....
> It seems like the UserInfoManger API is a bit empty anyway.
> IMO, I'd prefer something more like the Portlet API's preferences: get a
> map, and edit the map, and then have a store() method. Seems wasteful to
> have atomic updates everytime you put a property. The more I see the
> Java Prefs api, the less I like it.
>
> I'd like to see a User Info impl that persists to LDAP
> Willing to work with you on this, change the API to suit your needs, its
> up to you....
>
David,
I don't think I will have any time to work on a generalized solution until
sometime in the new year. I have a pretty tight deadline to get version one
of our portal out the door. I think some discussion would have to take place
as to what kind of schema would be needed to support this anyway.
In the mean time, I suggest you guys only change the API if you think feel that
it needs it. If you prefer to leave it as is for now so that you can focus
on getting j2 final out the door, then by all means. I will work with
whatever.
cheers,
aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: j2 - storage of user attributes
Posted by David Sean Taylor <da...@bluesunrise.com>.
Aaron Evans wrote:
> David Sean Taylor <david <at> bluesunrise.com> writes:
>
>>Well, thats one solution, but why not go directly from UserInfoManager
>>to LDAP?
>>Why not write a UserInfoLDAPManagerImpl and store the user info
>>attributes in LDAP, leaving the Prefs impl as is?
>>
>
>
> The biggest reason is because of the method signature of getUserAttributes in
> the org.apache.jetspeed.security.User interface. It returns a Preferences
> object.
>
> Preferences getUserAttributes();
>
We *can* change the API....
It seems like the UserInfoManger API is a bit empty anyway.
IMO, I'd prefer something more like the Portlet API's preferences: get a
map, and edit the map, and then have a store() method. Seems wasteful to
have atomic updates everytime you put a property. The more I see the
Java Prefs api, the less I like it.
> So I'd have to create a Preferences instance from the LDAP values at some
> point anyway (either in a UserInfoManager implementation or in a User
> implementation or some combination).
>
> The second reason (although much more minor) is that when the security
> application updates user attributes, it simply adds/updates a value in this
> preferences object and leaves it to the Preferences implementation to persist
> it:
>
> user.getUserAttributes().put(userAttrName, value);
>
The security portlet can be easily changed
> (see org.apache.jetspeed.portlets.security.users#updateUserAttribute).
>
> Again, this second reason is not such a big deal because I will no doubt
> need to make some mods to the security app anyway. I would like the
> edit attributes portion of the user details portlet to display a pre-defined
> list of attributes rather than letting the user add any arbitrary value.
>
> I figure if I just keep the "attributes" preferences object and "preferences"
> preferences object separate in a User implementation and have the former
> persist data to LDAP, that that would be the least intrusive customization.
>
I'd like to see a User Info impl that persists to LDAP
Willing to work with you on this, change the API to suit your needs, its
up to you....
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: j2 - storage of user attributes
Posted by Aaron Evans <aa...@yahoo.ca>.
David Sean Taylor <david <at> bluesunrise.com> writes:
> Well, thats one solution, but why not go directly from UserInfoManager
> to LDAP?
> Why not write a UserInfoLDAPManagerImpl and store the user info
> attributes in LDAP, leaving the Prefs impl as is?
>
The biggest reason is because of the method signature of getUserAttributes in
the org.apache.jetspeed.security.User interface. It returns a Preferences
object.
Preferences getUserAttributes();
So I'd have to create a Preferences instance from the LDAP values at some
point anyway (either in a UserInfoManager implementation or in a User
implementation or some combination).
The second reason (although much more minor) is that when the security
application updates user attributes, it simply adds/updates a value in this
preferences object and leaves it to the Preferences implementation to persist
it:
user.getUserAttributes().put(userAttrName, value);
(see org.apache.jetspeed.portlets.security.users#updateUserAttribute).
Again, this second reason is not such a big deal because I will no doubt
need to make some mods to the security app anyway. I would like the
edit attributes portion of the user details portlet to display a pre-defined
list of attributes rather than letting the user add any arbitrary value.
I figure if I just keep the "attributes" preferences object and "preferences"
preferences object separate in a User implementation and have the former
persist data to LDAP, that that would be the least intrusive customization.
thanks for the help,
aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: j2 - storage of user attributes
Posted by David Sean Taylor <da...@bluesunrise.com>.
Aaron Evans wrote:
> David Sean Taylor <david <at> bluesunrise.com> writes:
>
>>interface in jetspeed-api:
>>
>>org.apache.jetspeed.userinfo.UserInfoManager
>>
>
>
> Thanks for the reply David. I have looked at the implementing class and it
> seems as though portlet preferences as well as user traits/attributes are
> both stored in a Preferences object. Is this correct?
>
Yes, but you don't need to implement your version with Prefs.
> Furthermore, if I understand correctly that user portlet preferences
> and user traits/attributes are both being stored in this medium, IMHO, I think
> that these should be seperated out.
>
> So, I think what I would need to do to accomplish this is:
> 1. Create an LDAP backed implementation of java.util.prefs.Preferences
Well, thats one solution, but why not go directly from UserInfoManager
to LDAP?
> 2. Extend/Override UserImpl to keep user (portal) preferences and user
> attribute "preferences" separate.
> 3. Extend/Override UserManagerImpl to use the new User implemenation.
> 4. Do the appropriate spring config changes.
>
> Does this sound right?
>
Why not write a UserInfoLDAPManagerImpl and store the user info
attributes in LDAP, leaving the Prefs impl as is?
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: j2 - storage of user attributes
Posted by Aaron Evans <aa...@yahoo.ca>.
David Sean Taylor <david <at> bluesunrise.com> writes:
> interface in jetspeed-api:
>
> org.apache.jetspeed.userinfo.UserInfoManager
>
Thanks for the reply David. I have looked at the implementing class and it
seems as though portlet preferences as well as user traits/attributes are
both stored in a Preferences object. Is this correct?
I have not worked with the java.util.prefs API much before, so please excuse
my ignorance in this regard. Looking at the java.util.prefs.Preferences class,
it says "this data is stored persistently in an implementation-dependent backing
store. Typical implementations include flat files, OS-specific registries,
directory servers and SQL databases."
However, I cannot find where the Preferences tree is actually being persisted.
I can see gets and puts to the Preferences, but not where they are being written
to some storage medium such as a file or database.
This is the piece I am missing.
Furthermore, if I understand correctly that user portlet preferences
and user traits/attributes are both being stored in this medium, IMHO, I think
that these should be seperated out.
The storage of portlet preferences involves storing arbitrary keys and values.
But user attributes are generally going to be made up of a list of fixed
attributes for a specific portal implementation (eg. email address, first
name, last name and a whole host of other information that will be necessary
to maintain).
At least in my case anyway, I am not interested in storing portal preferences
in LDAP as the schema will not really allow for this. However, I do want
to maintain all the other fixed user traits in LDAP and have them loaded by
the user manager to possibly be made available to portlet applications.
So, I think what I would need to do to accomplish this is:
1. Create an LDAP backed implementation of java.util.prefs.Preferences
2. Extend/Override UserImpl to keep user (portal) preferences and user
attribute "preferences" separate.
3. Extend/Override UserManagerImpl to use the new User implemenation.
4. Do the appropriate spring config changes.
Does this sound right?
Thanks for the help,
aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: j2 - storage of user attributes
Posted by David Sean Taylor <da...@bluesunrise.com>.
Aaron Evans wrote:
> I have implemented a custom security SPI to use our ldap schema for
> users, groups and roles. I would now like to also have user attributes
> stored and retrieved to/from LDAP.
>
> Could someone tell me which interface I need to implement and which spring
> config component to change?
>
> I started poking around, but couldn't find it.
>
interface in jetspeed-api:
org.apache.jetspeed.userinfo.UserInfoManager
2 impls found are under the 'portal' component
See the Spring assembly, userinfo.xml
<!-- Single Source User Info -->
<bean id="org.apache.jetspeed.userinfo.UserInfoManager"
class="org.apache.jetspeed.userinfo.impl.UserInfoManagerImpl"
>
<constructor-arg index="0"><ref
bean="org.apache.jetspeed.security.UserManager"/></constructor-arg>
<constructor-arg index="1"><ref
bean="org.apache.jetspeed.components.portletregistry.PortletRegistry"/></constructor-arg>
</bean>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org