|
Home > Archive > Apache Directory Project > March 2007 > [core] Best way to internally authenticate for getting a DirContext
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[core] Best way to internally authenticate for getting a DirContext
|
|
| Enrique Rodriguez 2007-03-13, 1:11 am |
| Hi, Directory developers,
Each of the protocol providers needs to access the DIT for purposes of
looking up users, principals, DNS records, etc. What's the best way,
currently, for authenticating? Is the current and only option to use
the admin DN and password with "simple" authentication?
Enrique
| |
| Alex Karasulu 2007-03-15, 7:11 pm |
| 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.
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?
Alex
On 3/13/07, Enrique Rodriguez <enriquer9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Hi, Directory developers,
>
> Each of the protocol providers needs to access the DIT for purposes of
> looking up users, principals, DNS records, etc. What's the best way,
> currently, for authenticating? Is the current and only option to use
> the admin DN and password with "simple" authentication?
>
> Enrique
>
| |
| Enrique Rodriguez 2007-03-15, 7:11 pm |
| On 3/15/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.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.
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.
> 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.
Enrique
| |
| Emmanuel Lecharny 2007-03-15, 7:11 pm |
| On 3/15/07, Enrique Rodriguez <enriquer9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> On 3/15/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
> currently. I
> however
>
> Yeah, I kind of knew that. Really, the only way to restrict access
> intra-VM is to get into the whole code permissions thing.
> 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.
We have to find a place in the roadmap for OSGI, that's for sure ! I bet
that the best timing to start a first drop of OSGi code will be after
1.5.0release, around may or june.
Emmanuel
--
Cordialement,
Emmanuel Lécharny
www.iktek.com
| |
| Alex Karasulu 2007-03-15, 7:11 pm |
| On 3/15/07, Enrique Rodriguez <enriquer9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> On 3/15/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
> currently. I
> however
>
> 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
> time. We
> issue
>
> 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
|
|
|
|
|