On 3/15/07, Enrique Rodriguez <email@example.com> wrote:
On 3/15/07, Alex Karasulu <firstname.lastname@example.org> wrote:
> This totally stinks for now but you're right it's the only way currently. I
> could expose an API to just request a context without authentication however
> this would allow stored procedures in the server to do that as well and
> assume any user.
Yeah, I kind of knew that. Really, the only way to restrict access
intra-VM is to get into the whole code permissions thing.
Exactly. We're going to have to re-evaluate everything to do that correctly.
Incidentally, this is handled nicely in the OSGi service platform.
People have different ideas of what OSGi is; perhaps modular bundles,
jar metadata, etc., but when it comes down to it, it is a
comprehensive framework. Like any good framework, written by
experienced developers, you find yourself needing certain
functionality that it already has a story for. In this case, we could
use bundle permissions to restrict access between, for example, an
LDAP protocol provider bundle and a core DIT bundle.
Yeah this is certainly a big benefit that we'll be able to get along with JMX
for free. Hopefully.
> SPs will use JNDI too to work on the server while emebedded in it via the
> server side JNDI (core context factory) provider. We need to figure out
> something better but for you SASL effort this may not happen in time. We
> should use this workaround for now and consider revamping this design issue
> sometime later in the 1.5 branch.
Yeah, too big to fix right now. I'll use simple authentication
internally; have to add that to the beans for each of the protocol
providers. Today they rely on the JNDI env parameters being set in
server.xml, which makes it hard to start them programmatically,
again the use case is embedding or integration tests.
Yeah I like using beans instead of using env properties. Get's crazy fast when dealing with them. This way we'll have good typing and qualification within the bean.