Hi Mark, I am sorry but I didn't understand your question.... :( Possible to provide an example scenario? Might be helpful for me...

You can perform self-service password reset on identities stored in the internal gluu LDAP. You cannot perform self-service password reset on identities that are pulled from external authentication sources, e.g. via LDAP cache refresh, at least based on my reading of the Gluu documentation. However, an external authentication source might provide its own URL for doing password recovery. For example: I might have a gluu server that gets user info from the external LDAP directories of companies A, B, C, D via cache refresh. The gluu server won't be able to update the passwords in those directories, so users in company A who attempt to use the password reset URL from the gluu server won't be able to change their password in the LDAP of company A. However, company A might have a helpdesk URL for doing password reset requests. Company B might have a similar URL for password requests, and so on. This URL may be placed in, for instance, a custom attribute in users from the respective companies. If a user from company A triggers the password reset page, it would be helpful if the password reset URL points to the password reset url in one of his attributes. So for instance, he clicks the password reset link, gluu sends him an email with instructions instructing him to go to a link. Right now, the link the user is redirected to is hardcoded as some suburl of oxtrust. Is is possible for the link to point to an attribute configured on the user? That way the user from company A gets the company A password reset form, the user from company B gets the company B password reset form, etc.

Got it. Populating such value in attribute might be little bit cumbersome for those customers who are pulling user's attribute from backend AD/LDAP. Because, IDP is always getting updated information from backend AD/LDAP through Cache Refresh. So, that organization need to publish such attribute in their backend AD/LDAP. If organization can do that, there is no problem with Gluu Server to load that attribute. Now our clients are adding their own custom password links on Web UI customization. i.e. if you go to https://idp-d.gsu.edu you will see the "I forgot" and "Don't know your....". Of if you go to "https://idp.ndi.org", you will see "Forgot your password" link.

> Populating such value in attribute might be little bit cumbersome for those customers who are pulling user's attribute from backend AD/LDAP. I'm sure there are ways around this such as using cache refresh scripts or virtual attributes on the source directories. > Now our clients are adding their own custom password links on Web UI customization. i.e. if you go to https://idp-d.gsu.edu you will see the "I forgot" and "Don't know your....". Of if you go to "https://idp.ndi.org", you will see "Forgot your password" link. My main problem with the login Web UI approach is that before the username / email is entered, Gluu doesn't know whether the user is loaded from an external LDAP or not, and so it can only give the same link to everyone that accesses the web UI. But there are cases where people from different authentication sources may need to use the same application. For example, company A has child companies B and C that have a shared userbase/ticketing system, but users from company B and C are in different LDAP directories. If a user from company B clicks the login URL link, he'll get the same web UI as a user from company C. I think maybe the correct approach is that the password reset link in the email reset template either gets the user's password reset URL or the Gluu default if none is provided.

Good idea, do you see how to fix it in the template ? [https://github.com/GluuFederation/oxTrust](https://github.com/GluuFederation/oxTrust) If not, you can make a oxTrust github issue for an enhancement? thx, Mike