Setting approvers to authenticate themselves by password before approving a request-FIM 2010 R2 RRS feed

  • Question

  • Hello,

    Is it possible to have an approver in FIM 2010 R2 authenticate themselves before approving a request? Just to be sure that it is the right person approving a request and not anyone else. Like we have with password registration where the account name is recognized and the user is required to enter their password for validation before registration actually takes place.


    Monday, September 8, 2014 12:56 PM

All replies

  • Hello Josephine,

    When a user logins to the FIM Portal, the user is already authenticated. I am not able to get what is the add on need for authentication before approval.

    Manuj Khurana

    • Proposed as answer by Manuj Khurana Tuesday, September 9, 2014 2:55 PM
    Monday, September 8, 2014 1:49 PM
  • The only way to achieve it is to create custom activity that would take place before approval.

    As Manuj has already pointed - user is authenticated once he logs in to the portal, so I would rather think of ony other Authentication option, not the user Password itself.

    But if you want to stick to the password, you may change apporval workflow to activities like:

    • get password from suitable field
    • try to invoke any command using this user domain, account name and password (it could be even "cls" command) - you can use PowerShell Activity to do this, but users would have to be able to run powershell at this machine
    • If invokation is failed, don't let user to approve it
    • If invokation succedded, he is "good to go"

    Above is just an example how to test if user's password is ok or not.

    But, again - as Manuj pointed - believe your users - if someone is logged in to portal, let him do things.

    If you found my post helpful, please give it a Helpful vote. If it answered your question, remember to mark it as an Answer.

    Monday, September 8, 2014 2:31 PM
  • You are all right in pointing out that when someone is logged in to the portal, they are already authentic. However, there are occasions when someone leaves their machines and someone can take advantage of the situation to get an approval on something they would otherwise not be permitted.

    Yes, the option of one locking the computer is there but the thought of someone else having that chance is to be eliminated. Its for this reason that a second authentication is required before requests are approved.

    I have not worked with customized activity before especially workflows. Recommendations on how to achieve that would be appreciated please.

    Wednesday, September 10, 2014 2:44 AM
  • I would rather change user's behaviour (for example enforce workstation lock after some inactive time through GPO) than doubling login effort for users. Unlocked station is providing more possibilities for 'attacker' than only access to approval process - for example access to documents and mailbox.

    But I would not mess up with approval workflow itself.

    Obviously you can remove FIM Portal from trusted sites so user would be asked for credentials each time he tries to access new session of FIM Portal. It leaves the possibility that if user has FIM Portal page opened and step out of his desk, the session is still opened and 'attacker' can approve some requests.

    But still - I would rather change users behaviour than changing FIM Portal.

    If you found my post helpful, please give it a Helpful vote. If it answered your question, remember to mark it as an Answer.

    Wednesday, September 10, 2014 8:38 AM
  • Only way to achieve what you are asking in FIM workflows is to use authentication activity as part of your workflow. Authentication activity example is Q&A gate used for self-service password reset portal. 

    Unfortunately writing custom authentication activity is not supported in current version of FIM, which doesn't mean it is not possible.  

    Tomek Onyszko, memberOf Predica FIM Team (, IdAM knowledge provider @

    Thursday, September 11, 2014 10:37 PM
  • Thanks Tomek.

    The registration kind of authentication was the idea. However it is proving to be a challenge, though I have not given up on trying. I appreciate your input.

    Friday, September 12, 2014 3:00 AM
  • Thanks Dominik.

    Do you have any recommendations on how one can use powershell activities to achieve similar situations? I want to learn and try. I greatly appreciate your assistance.

    Friday, September 12, 2014 3:03 AM