portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "McClelland, Mark" <Mark.McClell...@divine.com>
Subject RE: Change to PSMLManagerService interface
Date Tue, 14 Aug 2001 15:32:14 GMT
> > 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,

> 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

> 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

> I would think that if you are going to store PSML in LDAP, 
> then you would want to also store the user info there.

I am storing user info in LDAP.

In response to a couple of additional questions from Raphael's message
(to keep this thread simple):

- I don't need to be able to read the user password from LDAP; I just
need to be able to send a user's credentials and verify that the user
can be authenticated.

- I am not using a database.

- I want my LDAP binding to be user-related -- I don't want the
application to be able to access LDAP without the credentials of a
current user.  To do this, I believe that the binding has to be either
on the session or recreated for each secure function.  For now, I chose
to go with the approach of rebinding for each secure function.

Thank you for your help on this.


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

View raw message