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 <[EMAIL PROTECTED]> wrote:
On 5/30/07, Emmanuel Lecharny <[EMAIL PROTECTED]> 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
