Please advise on the following case if possible:
We're using IGL 7.2, and we have a need to allow service desk to reset password for partner's accounts, as they (partners) don't have access to IGL - they can only use those specific accounts. We've discovered that Default External Password Reset form works just fine as it allows us to set password for selected account, but now we're struggling with assigning this form to request button / dropdown menu - this form just don't appear in the list. We've tried to create new form based on default one but that also didn't appear available for selection. It looks like there's some limitation blocking from assigning worms to buttons if these contain "External Password Reset" attribute.
Does anyone know if there's a workaround for it?
- Access & Change Requests
- Community Thread
- external password reset
- Forum Thread
- Identity G&L
- Identity Governance & Lifecycle
- igl 7.2
- password reset form
- request buttons
- requests form
- RSA Identity
- RSA Identity G&L
- RSA Identity Governance & Lifecycle
- RSA Identity Governance and Lifecycle
- RSA IGL
Adding the complete steps followed to approach this use case by using a password reset form type:
- Add the "Reset Password" IG&L AppRole to user(s) whom are going to run this form.
- Since you already had created a copy of your default external password reset form, go to that copy form first > Edit it > uncheck the External Password Reset checkbox.
- Put your condition in the “Changes Apply To” section of the form.
- Press Ok to save the form as a non-external password reset form.
- Head to the request buttons > create your button > choose "Go to a reset password form" action > choose that form stated in step 1 (the copy of the default external password reset form) > configure its place and availability and save.
- Head back to the form specified in step 1 and re-check the External Password Reset
or if your ask is explicitly about the "external" password reset form rather than the password reset form, give the Default Reset Password Form a trial run and let me know where are the blockers with this one.
That's exactly what i was trying to do - but External pass reset form is not available for selection. The reason why we would need specifically that form - is because it allows to set password - the other one will trigger pass change but will set randomly generated one, and as partners dont have access to IGL - they won't be able to retrieve it.
so are partners going to reset their own account passwords (self-service) or would they be able to reset other's accounts as well? As if it is set to run in self-service, the logged in user can specify the password going to get reset to instead of an auto generated one.
** I'm logged in as Kathy
Ahmet, the idea is to delegate password reset to service desk - which is why we and to link this form to dedicated request button with limited visibility and with some more restrictions.
Ahh sorry, I missed that.
Here is a workaround you can try:
1. Since you already had created a copy of your default external password reset form, go to that copy form first > Edit it > uncheck the External Password Reset checkbox and press Ok.
2. Head to the request buttons > create your button > choose "Go to a reset password form" action > choose that form stated in step 1 (the copy of the default external password reset form) > configure its place and availability and save.
3. Head back to the form specified in step 1 and re-check the External Password Reset checkbox again.
4. Head to the button place and click it with an authorized user. Should give you what you've expected here.
Thanks for suggestion - that actually worked)
Though now it appears that i cant set proper restrictions - i can restrict access to request button, but then i'd need to allow them to reset passwords to people in specific department - but it looks like it only allows to select user that is logged in. Is it something that can also be tweaked? For other request forms i can explicitly specify to whom it can be applied based on attributes, buts its not the case for password reset forms.
So there is no "Changes Apply to" configuration within external password reset forms.
What can be done is:
1. Have a sticky filter on the user selection table that says department =xyz if there is only one department in scope (can be removed by form runners) because if you add extra conditions, they are "ANDED" and not "OR'ED".
2. Filter out the accounts appearing in the accounts table, linking the accounts back to users that have the specific department(s) values you wish to have in scope for password reset, using a filter query, therefore form runners cannot proceed with users of other departments where no accounts are appearing in the account table (since picking at least one account is required as the account form field has the "Required" checkbox checked). Another thing that can be done with this filter query is to check the "Hide Table if Empty" checkbox on the account table field and have a conditional text field appear that states "User picked is not from department xyz" when the target user doesn't have the department attribute value set to xyz. Some conditional innovation with fields can be introduced in the form to guide the partners on how to re-run the form as well based on the users they picked from the previous page.
I hope that helps.
One thing else that could be applicable here that should've been mentioned even before is that you can ditch the whole password reset type of form and create a global one with control over availability and changes applying to configs. The fields would be fairly the same as the external password reset form where it would have a user account table and a password field.
A custom fulfillment workflow will be needed here and would then be linked to our global form here from the general form config settings. The fulfillment workflow would be mainly consisting of either:
a REST node to utilize the createChangeRequest webservice call to reset the password after getting the metadata needed for the payload from the form attribute/parameter values present as public workflow variables that can be utilized(account value and password attributes put inside the payload of the rest node)
a provisioning command node (or more than 1 if you want to introduce conditions/decisions to head to which provisioning command node based on which directory the account is collected in) that would be set to reset the password of the account, having the reset password capability parameters for the provisioning command node to be mapped to form parameter/attribute values present as public workflow variables that can be utilized to feed the provisioning command nodeinput parameters.
I hope that helps as well.