<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Is it getting the password from the ldapsearch'd returned attributes
    and storing that or is it keeping the password that the user
    provides at login and storing that?<br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 10/3/19 9:38 AM, Guillaume Rousse
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:653b0cd0-fe85-45cf-7a4d-ac9f6d974e43@renater.fr">Hello
      list.
      <br>
      <br>
      While debugging an authentication issue this morning, I discovered
      that our IdP actually stores a full copy of each user LDAP
      account, including password hashes, as a JSON string, in its
      database.
      <br>
      <br>
      It seems to be caused by the combination of database storage for
      IdP sessions, and an udefined value for the
      idp.authn.LDAP.returnAttributes property.
      <br>
      <br>
      Our current configuration uses the default ldap.properties file
      content:
      <br>
      ## Return attributes during authentication
      <br>
      idp.authn.LDAP.returnAttributes =
      <br>
      <br>
      AFAIK, this results in a property with an undefined value.
      <br>
      <br>
      The ldap-authn-config.xml configuration file, the only place where
      this property is used, also has default content:
      <br>
      <bean id="shibboleth.authn.LDAP.returnAttributes"
      parent="shibboleth.CommaDelimStringArray">
      <br>
          <constructor-arg type="java.lang.String"
      value="%{idp.authn.LDAP.returnAttributes:1.1}" />
      <br>
       </bean>
      <br>
      <br>
      According to my understanding of (Spring|Velocity|whatever
      templating system used) syntax, this should result in a default
      value of "1.1" for the value attribute, as the
      idp.authn.LDAP.returnAttribute property is undefined. And
      according to the documentation
(<a class="moz-txt-link-freetext" href="https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration">https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration</a>),
      it should result in no attribute fetching at all.
      <br>
      <br>
      However, all attributes are currently being retrieved. Which is
      both fragile (the authentication issue was caused by an JPEG image
      stored in an LDAP attribute, triggering a 'maximum request size
      exceded' error) and undesirable, as it exposes sensible
      informations.
      <br>
      <br>
      I'm obviously missing something here, but I can't find what
      exactly :/
      <br>
      <br>
      Regards.
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
D o n a l d   L o h r
 I n f o r m a t i o n   S y s t e m s
 J a m e s   M a d i s o n   U n i v e r s i t y
 5 4 0 . 5 6 8 . 3 7 3 0

 DOS:  Bad command or file name
 bash: command not found
</pre>
  </body>
</html>