directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
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 <enriquer9@gmail.com> wrote:
>
> On 3/15/07, Alex Karasulu <akarasulu@apache.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.
> >
> > 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.

Alex

Mime
View raw message