You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Enrique Rodriguez <en...@gmail.com> on 2007/05/25 00:16:10 UTC
[ApacheDS] Internal vs. external lookups
Hi, Directory developers,
I have some use cases for Kerberos that require an interceptor to know
whether a request is coming from internal vs. external to the server.
For example, if a principal lookup is being performed by the Kerberos
protocol provider or by an LDAP search. In other words, internal JNDI
access or LDAP-over-the-wire. Unfortunately, I think everything looks
like it's coming from CoreContextFactory to the interceptors.
I've thought of a couple hacks, such as using a special principal for
protocol providers to use for binding with JNDI. Today we use the
admin principal everywhere (startup config, internal JNDI). But,
using a special principal still allows that principal to be used for
internal or external access, ie it's not very explicit. So, the
solution I keep coming back to is to create a new Authenticator, the
InternalAuthenticator, and to use that as the authenticationLevel
"internal" (vs. "simple" or "strong").
Eventually, the solution might be both the InternalAuthenticatior in
conjuction with service principal DN's that each protocol provider
would need to use to bind internally and that we could use in ACI to
tighten security. Today protocols bind with the admin account and
have full access to the DIT.
Is there any way to tell already if a lookup is internal vs. external?
Is the InternalAuthenticator a viable option? The implementation
would be trivial (I just did the StrongAuthenticator).
Enrique
Re: [ApacheDS] Internal vs. external lookups
Posted by Alex Karasulu <ak...@apache.org>.
Sorry will respond to this thread in a little bit. Processing backlog now.
On 5/30/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> Hi Enrique,
>
> another solution would be to add a flag to the OperationContext which
> is passed through the interceptors, to tell if the request is internal
> or not.
>
> Those contexts have been created for such purposes.
>
> You have a context for each operation (SearchOperationContext,
> LookupOperationContext ... in core (
> org.apache.directory.server.core.interceptor.context ) ). Even adding
> the flag to the inherited class ( AbstractOperationContext ) and
> adding a method in the interface -OperationContext - could help (
> isInternal() )
>
> Hope it helps.
>
> Emmanuel
>
> On 5/30/07, Enrique Rodriguez <en...@gmail.com> wrote:
> > On 5/24/07, Enrique Rodriguez <en...@gmail.com> wrote:
> > > Hi, Directory developers,
> > > ...
> > > Is there any way to tell already if a lookup is internal vs. external?
> > > Is the InternalAuthenticator a viable option? The implementation
> > > would be trivial (I just did the StrongAuthenticator).
> >
> > I am at a point this week where I need a solution to determining
> > whether a search or lookup is coming from internal vs. external to the
> > server. In my working copy I modified SimpleAuthenticator to support
> > subclassing. I now have an InternalAuthenticator, where the
> > authenticatorType is "internal" and the resulting LdapPrincipals are
> > of type AuthenticationLevel.INTERNAL and this works fine for me. I
> > subclassed SimpleAuthenticator so I could re-use the username/password
> > support so internal authentication would not be totally wide-open. I
> > am still binding with the admin DN.
> >
> > I need to code more on my use case, but if this works for me then I
> > would want to commit this and eventually update all the
> > protocol-providers to use "internal" authentication.
> >
> > Does this make sense?
> >
> > Enrique
> >
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: [ApacheDS] Internal vs. external lookups
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/1/07, Alex Karasulu <ak...@apache.org> wrote:
> Guys I have not abandoned this thread. Just rebuilding dev env after a
> failure. I need to think about this more and review it. Will get back to
> you. Enrique is this urgent?
Not urgent but still a relevant issue. I have 2 work-arounds so I can
continue coding this weekend. I have already written an
InternalAuthenticator and I'm also going to try Emm's suggestion to
simply put a flag in the env.
But, I expect to have my interceptor(s) working and ready to
propose/explain to you guys for inclusion in the core in a week or so
and so I expect we'll eventually need a formal solution in the core.
Enrique
Re: [ApacheDS] Internal vs. external lookups
Posted by Alex Karasulu <ak...@apache.org>.
Guys I have not abandoned this thread. Just rebuilding dev env after a
failure. I need to think about this more and review it. Will get back to
you. Enrique is this urgent?
Alex
On 5/31/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> Hi guys,
>
> I'm just wondering how it connects to http://www.ietf.org/rfc/rfc4370.txt.
>
> wdyt ?
>
> On 5/31/07, Quanah Gibson-Mount <qu...@zimbra.com> wrote:
> > --On Thursday, May 31, 2007 1:17 AM -0400 Alex Karasulu
> > <ak...@apache.org> wrote:
> >
> > >
> > >
> > >
> > > On 5/31/07, Quanah Gibson-Mount <qu...@zimbra.com> wrote:
> > >
> > > --On Wednesday, May 30, 2007 10:11 PM -0700 Enrique Rodriguez
> > > <en...@gmail.com> wrote:
> > >
> > >> Actually, I very much care whether the request is internal vs.
> > >> external and much much less "who" is attempting the authentication.
> > >> The issue with what I want to do is that certain operations must
> NEVER
> > >> be allowed to occur from outside the server. Basing this upon the
> > >> bind principal does not help since a bind principal can be
> > >> compromised. To avoid a security problem when a principal is
> > >> compromised, I must prevent certain operations from ever occuring
> from
> > >> outside the server, and thus I must know whether a request is coming
> > >> from inside vs. outside the server and not who the bind principal is.
> > >
> > > This is something that matters considerably when considering dynamic
> group
> > > expansion. I haven't followed whether or not Apache DS has
> implemented
> > > (or
> > > will implement) this, but that's certainly a place where I found that
> it
> > > is
> > > necessary to have the concept of an internal ID acting on different
> > > permissions from the external ID making a request.
> > >
> > >
> > >
> > > This is interesting can you elaborate or give an example of such a
> > > situation?
> >
> > Certainly. :)
> >
> > At Stanford, user groups were always implemented via an attribute
> > (suPrivilegeGroup). Due to data policy restrictions because of US Law
> > (FERPA, HIPAA), access to the attribute itself is highly
> restricted. The
> > attribute is multi-valued, and may contain data that is not covered by
> US
> > Law (and thus world readable). Stanford desires to use the attribute
> > values for authorization via groups. So an example entry might have
> > something like:
> >
> > suregid=1234,cn=people,dc=stanford,dc=edu
> > ....
> > suPrivilegeGroup: FERPA1
> > suPrivilegeGroup: FERPA2
> > suPrivilegeGroup: WORLD1
> > suPrivilegeGroup: WORLD2
> >
> >
> > Dynamic groups work on the concept of evaluating an LDAP URI to create
> the
> > membership list. So that might be something like (and this is off the
> top
> > of my head for that rather arcane URI syntax...)
> >
> > ldap:///cn=people,dc=stanford,dc=edu??suPrivilegeGroup=FERPA1
> >
> >
> > Now, normally, to create the population for this dynamic group, it
> requires
> > that the identity connection to the server (lets say "www") has at least
> > search ability on the suPrivilegeGroup attribute. However, if Stanford
> > grants search on that attribute to the "www" principal, any user on the
> www
> > servers can potentially use the credentials of the www server (via CGI
> > scripts or other methods) to find out what people are in particular
> groups.
> > To fix this issue, the general idea is to allow an "internal" ID to be
> > defined in the dynamic group object that is what performs the actual
> > evaluation of the LDAP URI. This way, the LDAP access to the group
> object
> > can be allowed for the "www" identity, but it itself actually has no
> > ability to search the user entries for suPrivilegeGroup values.
> >
> > There's an RFC on dynamic groups that is currently draft that
> incorporates
> > this idea, but has several serious flaws in it. A discussion about the
> > draft and its current flaws can be found at:
> >
> > <http://www.openldap.org/lists/ietf-ldapext/200702/threads.html>
> >
> > --Quanah
> >
> > --
> > Quanah Gibson-Mount
> > Principal Software Engineer
> > Zimbra, Inc
> > --------------------
> > Zimbra :: the leader in open source messaging and collaboration
> >
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: [ApacheDS] Internal vs. external lookups
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi guys,
I'm just wondering how it connects to http://www.ietf.org/rfc/rfc4370.txt.
wdyt ?
On 5/31/07, Quanah Gibson-Mount <qu...@zimbra.com> wrote:
> --On Thursday, May 31, 2007 1:17 AM -0400 Alex Karasulu
> <ak...@apache.org> wrote:
>
> >
> >
> >
> > On 5/31/07, Quanah Gibson-Mount <qu...@zimbra.com> wrote:
> >
> > --On Wednesday, May 30, 2007 10:11 PM -0700 Enrique Rodriguez
> > <en...@gmail.com> wrote:
> >
> >> Actually, I very much care whether the request is internal vs.
> >> external and much much less "who" is attempting the authentication.
> >> The issue with what I want to do is that certain operations must NEVER
> >> be allowed to occur from outside the server. Basing this upon the
> >> bind principal does not help since a bind principal can be
> >> compromised. To avoid a security problem when a principal is
> >> compromised, I must prevent certain operations from ever occuring from
> >> outside the server, and thus I must know whether a request is coming
> >> from inside vs. outside the server and not who the bind principal is.
> >
> > This is something that matters considerably when considering dynamic group
> > expansion. I haven't followed whether or not Apache DS has implemented
> > (or
> > will implement) this, but that's certainly a place where I found that it
> > is
> > necessary to have the concept of an internal ID acting on different
> > permissions from the external ID making a request.
> >
> >
> >
> > This is interesting can you elaborate or give an example of such a
> > situation?
>
> Certainly. :)
>
> At Stanford, user groups were always implemented via an attribute
> (suPrivilegeGroup). Due to data policy restrictions because of US Law
> (FERPA, HIPAA), access to the attribute itself is highly restricted. The
> attribute is multi-valued, and may contain data that is not covered by US
> Law (and thus world readable). Stanford desires to use the attribute
> values for authorization via groups. So an example entry might have
> something like:
>
> suregid=1234,cn=people,dc=stanford,dc=edu
> ....
> suPrivilegeGroup: FERPA1
> suPrivilegeGroup: FERPA2
> suPrivilegeGroup: WORLD1
> suPrivilegeGroup: WORLD2
>
>
> Dynamic groups work on the concept of evaluating an LDAP URI to create the
> membership list. So that might be something like (and this is off the top
> of my head for that rather arcane URI syntax...)
>
> ldap:///cn=people,dc=stanford,dc=edu??suPrivilegeGroup=FERPA1
>
>
> Now, normally, to create the population for this dynamic group, it requires
> that the identity connection to the server (lets say "www") has at least
> search ability on the suPrivilegeGroup attribute. However, if Stanford
> grants search on that attribute to the "www" principal, any user on the www
> servers can potentially use the credentials of the www server (via CGI
> scripts or other methods) to find out what people are in particular groups.
> To fix this issue, the general idea is to allow an "internal" ID to be
> defined in the dynamic group object that is what performs the actual
> evaluation of the LDAP URI. This way, the LDAP access to the group object
> can be allowed for the "www" identity, but it itself actually has no
> ability to search the user entries for suPrivilegeGroup values.
>
> There's an RFC on dynamic groups that is currently draft that incorporates
> this idea, but has several serious flaws in it. A discussion about the
> draft and its current flaws can be found at:
>
> <http://www.openldap.org/lists/ietf-ldapext/200702/threads.html>
>
> --Quanah
>
> --
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] Internal vs. external lookups
Posted by Quanah Gibson-Mount <qu...@zimbra.com>.
--On Thursday, May 31, 2007 1:17 AM -0400 Alex Karasulu
<ak...@apache.org> wrote:
>
>
>
> On 5/31/07, Quanah Gibson-Mount <qu...@zimbra.com> wrote:
>
> --On Wednesday, May 30, 2007 10:11 PM -0700 Enrique Rodriguez
> <en...@gmail.com> wrote:
>
>> Actually, I very much care whether the request is internal vs.
>> external and much much less "who" is attempting the authentication.
>> The issue with what I want to do is that certain operations must NEVER
>> be allowed to occur from outside the server. Basing this upon the
>> bind principal does not help since a bind principal can be
>> compromised. To avoid a security problem when a principal is
>> compromised, I must prevent certain operations from ever occuring from
>> outside the server, and thus I must know whether a request is coming
>> from inside vs. outside the server and not who the bind principal is.
>
> This is something that matters considerably when considering dynamic group
> expansion. I haven't followed whether or not Apache DS has implemented
> (or
> will implement) this, but that's certainly a place where I found that it
> is
> necessary to have the concept of an internal ID acting on different
> permissions from the external ID making a request.
>
>
>
> This is interesting can you elaborate or give an example of such a
> situation?
Certainly. :)
At Stanford, user groups were always implemented via an attribute
(suPrivilegeGroup). Due to data policy restrictions because of US Law
(FERPA, HIPAA), access to the attribute itself is highly restricted. The
attribute is multi-valued, and may contain data that is not covered by US
Law (and thus world readable). Stanford desires to use the attribute
values for authorization via groups. So an example entry might have
something like:
suregid=1234,cn=people,dc=stanford,dc=edu
....
suPrivilegeGroup: FERPA1
suPrivilegeGroup: FERPA2
suPrivilegeGroup: WORLD1
suPrivilegeGroup: WORLD2
Dynamic groups work on the concept of evaluating an LDAP URI to create the
membership list. So that might be something like (and this is off the top
of my head for that rather arcane URI syntax...)
ldap:///cn=people,dc=stanford,dc=edu??suPrivilegeGroup=FERPA1
Now, normally, to create the population for this dynamic group, it requires
that the identity connection to the server (lets say "www") has at least
search ability on the suPrivilegeGroup attribute. However, if Stanford
grants search on that attribute to the "www" principal, any user on the www
servers can potentially use the credentials of the www server (via CGI
scripts or other methods) to find out what people are in particular groups.
To fix this issue, the general idea is to allow an "internal" ID to be
defined in the dynamic group object that is what performs the actual
evaluation of the LDAP URI. This way, the LDAP access to the group object
can be allowed for the "www" identity, but it itself actually has no
ability to search the user entries for suPrivilegeGroup values.
There's an RFC on dynamic groups that is currently draft that incorporates
this idea, but has several serious flaws in it. A discussion about the
draft and its current flaws can be found at:
<http://www.openldap.org/lists/ietf-ldapext/200702/threads.html>
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Re: [ApacheDS] Internal vs. external lookups
Posted by Alex Karasulu <ak...@apache.org>.
On 5/31/07, Quanah Gibson-Mount <qu...@zimbra.com> wrote:
>
> --On Wednesday, May 30, 2007 10:11 PM -0700 Enrique Rodriguez
> <en...@gmail.com> wrote:
>
> > Actually, I very much care whether the request is internal vs.
> > external and much much less "who" is attempting the authentication.
> > The issue with what I want to do is that certain operations must NEVER
> > be allowed to occur from outside the server. Basing this upon the
> > bind principal does not help since a bind principal can be
> > compromised. To avoid a security problem when a principal is
> > compromised, I must prevent certain operations from ever occuring from
> > outside the server, and thus I must know whether a request is coming
> > from inside vs. outside the server and not who the bind principal is.
>
> This is something that matters considerably when considering dynamic group
> expansion. I haven't followed whether or not Apache DS has implemented
> (or
> will implement) this, but that's certainly a place where I found that it
> is
> necessary to have the concept of an internal ID acting on different
> permissions from the external ID making a request.
This is interesting can you elaborate or give an example of such a
situation?
Alex
Re: [ApacheDS] Internal vs. external lookups
Posted by Quanah Gibson-Mount <qu...@zimbra.com>.
--On Wednesday, May 30, 2007 10:11 PM -0700 Enrique Rodriguez
<en...@gmail.com> wrote:
> Actually, I very much care whether the request is internal vs.
> external and much much less "who" is attempting the authentication.
> The issue with what I want to do is that certain operations must NEVER
> be allowed to occur from outside the server. Basing this upon the
> bind principal does not help since a bind principal can be
> compromised. To avoid a security problem when a principal is
> compromised, I must prevent certain operations from ever occuring from
> outside the server, and thus I must know whether a request is coming
> from inside vs. outside the server and not who the bind principal is.
This is something that matters considerably when considering dynamic group
expansion. I haven't followed whether or not Apache DS has implemented (or
will implement) this, but that's certainly a place where I found that it is
necessary to have the concept of an internal ID acting on different
permissions from the external ID making a request.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Re: [ApacheDS] Internal vs. external lookups
Posted by Alex Karasulu <ak...@apache.org>.
On 5/31/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 5/30/07, Alex Karasulu <ak...@apache.org> wrote:
> > Enrique, I'm guessing you use "internal" for the value of the
> > Context.SECURITY_AUTHENTICATION [0] JNDI parameter. Is
> > this a correct presumption?
>
> Yes.
>
> > This parameter is hence used to set the authentication level right? I
> guess
> > this is attractive to do since it marks the Context for the life of the
> > Context
> > and you can differentiate it from LDAP sessions which authenticate on
> > InitialContexts using the other authentication levels. In this case
> your
> > tactic would work but it could be implemented a little better. There is
> no
> > reason why we should have to do this with the authentication level which
> > is really orthogonal to your aim of identifying "who" is attempting the
> > authentication.
>
> Actually, I very much care whether the request is internal vs.
> external and much much less "who" is attempting the authentication.
> The issue with what I want to do is that certain operations must NEVER
> be allowed to occur from outside the server. Basing this upon the
> bind principal does not help since a bind principal can be
> compromised. To avoid a security problem when a principal is
> compromised, I must prevent certain operations from ever occuring from
> outside the server, and thus I must know whether a request is coming
> from inside vs. outside the server and not who the bind principal is.
OK I see. How about preventing external binds from these special service
principals
in the LDAP provider? We can create a special blocked list or use a special
attribute
that prevents LDAP binds this way? So for example you can flag an account
as
internal and the LDAP server will not allow the bind through LDAP.
Alex
Re: [ApacheDS] Internal vs. external lookups
Posted by Enrique Rodriguez <en...@gmail.com>.
On 5/30/07, Alex Karasulu <ak...@apache.org> wrote:
> Enrique, I'm guessing you use "internal" for the value of the
> Context.SECURITY_AUTHENTICATION [0] JNDI parameter. Is
> this a correct presumption?
Yes.
> This parameter is hence used to set the authentication level right? I guess
> this is attractive to do since it marks the Context for the life of the
> Context
> and you can differentiate it from LDAP sessions which authenticate on
> InitialContexts using the other authentication levels. In this case your
> tactic would work but it could be implemented a little better. There is no
> reason why we should have to do this with the authentication level which
> is really orthogonal to your aim of identifying "who" is attempting the
> authentication.
Actually, I very much care whether the request is internal vs.
external and much much less "who" is attempting the authentication.
The issue with what I want to do is that certain operations must NEVER
be allowed to occur from outside the server. Basing this upon the
bind principal does not help since a bind principal can be
compromised. To avoid a security problem when a principal is
compromised, I must prevent certain operations from ever occuring from
outside the server, and thus I must know whether a request is coming
from inside vs. outside the server and not who the bind principal is.
> The SECURITY_PRINCIPAL environment parameter already does this so
> why not just use it. All we need to do is create some standard principals
> for these services that comes with ApacheDS out of the box, packaged into
> the DIT. We can easily promote these principals to the point of having
> administrator like powers. I added some standard groups to ADS to allow
> this. This by far is the best mechanism I can see. This property is
> specifically
> there for answering your question. Also you can extract it from the
> ServerContext.getPrincipal() method which contains the normalized DN of the
> binding principal.
I very specifically care to know when requests are being made internal
vs. external to the server, so SECURITY_PRINCIPAL is not what I want.
The fact that "internal" could be used as an authenticationLevel is a
possible bonus in ACI evaluation, but I'm sorry I brought it up since
it has obviously confused my original question about how to determine
whether a request is coming from inside vs. outside the server.
Enrique
Re: [ApacheDS] Internal vs. external lookups
Posted by Alex Karasulu <ak...@apache.org>.
Enrique, I'm guessing you use "internal" for the value of the
Context.SECURITY_AUTHENTICATION [0] JNDI parameter. Is
this a correct presumption?
This parameter is hence used to set the authentication level right? I guess
this is attractive to do since it marks the Context for the life of the
Context
and you can differentiate it from LDAP sessions which authenticate on
InitialContexts using the other authentication levels. In this case your
tactic would work but it could be implemented a little better. There is no
reason why we should have to do this with the authentication level which
is really orthogonal to your aim of identifying "who" is attempting the
authentication.
The SECURITY_PRINCIPAL environment parameter already does this so
why not just use it. All we need to do is create some standard principals
for these services that comes with ApacheDS out of the box, packaged into
the DIT. We can easily promote these principals to the point of having
administrator like powers. I added some standard groups to ADS to allow
this. This by far is the best mechanism I can see. This property is
specifically
there for answering your question. Also you can extract it from the
ServerContext.getPrincipal() method which contains the normalized DN of the
binding principal.
Alex
On 5/30/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 5/30/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> > Using a special parameter and adding to to JNDI env seems a good way
> > to do it. If this flag is set, then it's an internal call (no need to
> > expose such a parameter to external users, IMHO)
>
> My use cases don't need "internal" as a defined authenticationLevel
> for ACI, but I wonder if there isn't some value to formally
> distinguishing internal binds for purposes of access control? Nothing
> in X.500 discusses internal vs external binds?
Alex
-------
[0] -
http://java.sun.com/j2se/1.4.2/docs/api/javax/naming/Context.html#SECURITY_AUTHENTICATION
Re: [ApacheDS] Internal vs. external lookups
Posted by Enrique Rodriguez <en...@gmail.com>.
On 5/30/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> Using a special parameter and adding to to JNDI env seems a good way
> to do it. If this flag is set, then it's an internal call (no need to
> expose such a parameter to external users, IMHO)
My use cases don't need "internal" as a defined authenticationLevel
for ACI, but I wonder if there isn't some value to formally
distinguishing internal binds for purposes of access control? Nothing
in X.500 discusses internal vs external binds?
Enrique
Re: [ApacheDS] Internal vs. external lookups
Posted by Emmanuel Lecharny <el...@gmail.com>.
Using a special parameter and adding to to JNDI env seems a good way
to do it. If this flag is set, then it's an internal call (no need to
expose such a parameter to external users, IMHO)
Emmanuel
On 5/30/07, Enrique Rodriguez <en...@gmail.com> wrote:
> On 5/30/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> > ...
> > another solution would be to add a flag to the OperationContext which
> > is passed through the interceptors, to tell if the request is internal
> > or not.
> >
> > Those contexts have been created for such purposes.
>
> How would this flag get set when connecting via JNDI? Today all the
> protocol providers use JNDI with CoreContextFactory. We use
> CoreContextFactory to bind users via LDAP (external) as well as
> protocol providers (internal) so we couldn't simply have all
> CoreContextFactory initial contexts set isInternal() to "true." We
> would need to cast to an interface to setInternal(true) or we would
> need a env parameter, such as Context.SECURITY_AUTHENTICATION =
> "internal".
>
> Enrique
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] Internal vs. external lookups
Posted by Enrique Rodriguez <en...@gmail.com>.
On 5/30/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> ...
> another solution would be to add a flag to the OperationContext which
> is passed through the interceptors, to tell if the request is internal
> or not.
>
> Those contexts have been created for such purposes.
How would this flag get set when connecting via JNDI? Today all the
protocol providers use JNDI with CoreContextFactory. We use
CoreContextFactory to bind users via LDAP (external) as well as
protocol providers (internal) so we couldn't simply have all
CoreContextFactory initial contexts set isInternal() to "true." We
would need to cast to an interface to setInternal(true) or we would
need a env parameter, such as Context.SECURITY_AUTHENTICATION =
"internal".
Enrique
Re: [ApacheDS] Internal vs. external lookups
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Enrique,
another solution would be to add a flag to the OperationContext which
is passed through the interceptors, to tell if the request is internal
or not.
Those contexts have been created for such purposes.
You have a context for each operation (SearchOperationContext,
LookupOperationContext ... in core (
org.apache.directory.server.core.interceptor.context ) ). Even adding
the flag to the inherited class ( AbstractOperationContext ) and
adding a method in the interface -OperationContext - could help (
isInternal() )
Hope it helps.
Emmanuel
On 5/30/07, Enrique Rodriguez <en...@gmail.com> wrote:
> On 5/24/07, Enrique Rodriguez <en...@gmail.com> wrote:
> > Hi, Directory developers,
> > ...
> > Is there any way to tell already if a lookup is internal vs. external?
> > Is the InternalAuthenticator a viable option? The implementation
> > would be trivial (I just did the StrongAuthenticator).
>
> I am at a point this week where I need a solution to determining
> whether a search or lookup is coming from internal vs. external to the
> server. In my working copy I modified SimpleAuthenticator to support
> subclassing. I now have an InternalAuthenticator, where the
> authenticatorType is "internal" and the resulting LdapPrincipals are
> of type AuthenticationLevel.INTERNAL and this works fine for me. I
> subclassed SimpleAuthenticator so I could re-use the username/password
> support so internal authentication would not be totally wide-open. I
> am still binding with the admin DN.
>
> I need to code more on my use case, but if this works for me then I
> would want to commit this and eventually update all the
> protocol-providers to use "internal" authentication.
>
> Does this make sense?
>
> Enrique
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] Internal vs. external lookups
Posted by Enrique Rodriguez <en...@gmail.com>.
On 5/24/07, Enrique Rodriguez <en...@gmail.com> wrote:
> Hi, Directory developers,
> ...
> Is there any way to tell already if a lookup is internal vs. external?
> Is the InternalAuthenticator a viable option? The implementation
> would be trivial (I just did the StrongAuthenticator).
I am at a point this week where I need a solution to determining
whether a search or lookup is coming from internal vs. external to the
server. In my working copy I modified SimpleAuthenticator to support
subclassing. I now have an InternalAuthenticator, where the
authenticatorType is "internal" and the resulting LdapPrincipals are
of type AuthenticationLevel.INTERNAL and this works fine for me. I
subclassed SimpleAuthenticator so I could re-use the username/password
support so internal authentication would not be totally wide-open. I
am still binding with the admin DN.
I need to code more on my use case, but if this works for me then I
would want to commit this and eventually update all the
protocol-providers to use "internal" authentication.
Does this make sense?
Enrique