> > 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.
> 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 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.
-mark
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
|