directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [core] Best way to internally authenticate for getting a DirContext
Date Fri, 16 Mar 2007 00:07:26 GMT
On 3/15/07, Enrique Rodriguez <> wrote:
> On 3/15/07, Alex Karasulu <> 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

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
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.
> >
> > WDYT?
> 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
> the 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.


View raw message