On Wed, Apr 27, 2011 at 10:03 PM, Douglas Hubler <[email protected]> wrote:
> On Wed, Apr 27, 2011 at 1:56 PM, Mircea Carasel <[email protected]> wrote: > > For ldap authentication, in sipXconfig side we are computing a digest > > encoded value being given the SHARED_SECRET (you can find it in > > domain_config.xml) because the web layer expects a UserDetailsImpl > instance, > > and for LDAP authenticator we are using the SHARED_SECRET instead of the > > ldap password (ldap password is verified only in LDAP layer) > > I don't understand this statement. Shouldn't this read: > When ldap authentication is enabled, the PIN is useless and is not > used for anything. > This is correct Just trying to explain what happens on the back scenes: <bean id="ldapAuthProvider" class="org.sipfoundry.sipxconfig.security.ConfigurableLdapAuthenticationProvider"> <property name="userDetailsService" ref="sharedSecretUserDetailsService" /> <property name="ldapManager" ref="ldapManager"/> </bean> ref=sharedSecretUserDetailsService - that creates: SharedSecretUserDetailsImpl /** Return the MD5-encoded SHARED-SECRET as password */ @Override public String getPassword() { String sharedSecret = m_domainManager.getSharedSecret(); return Md5Encoder.digestPassword(getUsername(), m_domainManager.getAuthorizationRealm(), sharedSecret); } The PIN is not used for anything in LDAP authentication. ONLY for SUPERADMIN we are always falling back to PIN authentication, no matter what authentication scheme is set Mircea > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
