portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raphaƫl Luta <raphael.l...@networks.groupvu.com>
Subject Re: Change to PSMLManagerService interface
Date Tue, 14 Aug 2001 17:30:25 GMT
McClelland, Mark wrote:

>>>Would you consider committing a change to the interface and 
>>>its various
>>>implementations to allow for this increased level of security?
>>>
>>The ProfileLocator already has a user object, but it isn't 
>>required that its filled valid.
>>Sometimes you are working with groups or roles, so when you 
>>say a user, do you mean an admin-type user, or just the current user?
>>
> 
> What I want to do is use the current user's credentials to determine
> whether they have access to admin functions, such as adding and removing
> roles or assigning a user to a role.  I don't want the application to
> have any security privileges of its own -- everything should be based on
> the username and password of the portal user (in this case,
> admin/jetspeed).
> 

> 
> 
>>There aren't a lot of methods left after we complete the deprecation:
>>
>>    public PSMLDocument getDocument( ProfileLocator locator );
>>    public boolean saveDocument(PSMLDocument doc);
>>    public PSMLDocument createDocument( ProfileLocator locator );
>>    public Iterator list( ProfileLocator locator );
>>
> 
> It is my understanding that the user on the ProfileLocator is the owner
> of the PSML document -- not necessarily the user currently logged in.  I
> want an admin user to be able to log in and make a change that affects
> other users.  In a corporate setting, this sort of change is fairly
> common.
> 


I don't think so, I believe that if you don't specify a "user" parameter
the user object in the locator is the currently logged in User, otherwise
it's a User describing the owner of the profile resource.
Note that this is simple to implement a ProfileLocator and Profiler service
implementation to change this (for example adding owner User and current User).


> 
> 
>>It would be easy to add a single parameter to all methods - 
>>perhaps RunData would be more useful although it ties the 
>>methods to rundata requests.
>>
>>Do you plan on integrating it with Turbine Security?
>>There has been a lot of talk on the mailing list, but I don't 
>>think the Turbine folks ever got around to actually 
>>implementing a Turbine LDAP Security Service. 
>>
> 
> I am indeed planning on integrating it with TurbineSecurity, which also
> seems to have no notion of the currently logged-in user once you get to
> methods like addRole().  I expect that I will have to extend the
> TurbineSecurity and TurbineSecurityService interfaces, to add user or
> rundata objects to every method where a secure function is performed.  I
> re-bind to the LDAP server for each secure call.  Perhaps this should be
> reconsidered?
> 


I don't think you need to go to such drastic measures. Implementing a
subclass of the User interface (or simply using getPerm()/setPerm()) is
IMO better for your purpose than extending the PsmlManager interface.

Since your User object would be tied to the LDAP persistence backend and
all the data you want to access is specific to the User, you can keep
all the LDAP related code abstracted by the User interface and in your
PsmlManager implementation you can rely on the User interface to access
your ressource information.


If you still want to go and implement directly a LDAP based, per user
PsmlManager implementation, you should probably create a new implementation
of ProfileLocator that would enable you to store and retrieve the credentials
and LDAP backend access parameters.

--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message