"Virtual" Worker Accounts

This is a little bit of a change of pace; but I was wondering what others are doing to manage "virtual" workers. With our investment into robotic process automation (RPA), our company is creating faux user accounts for automating computer "task work". I was wondering how others may have tackled this challenge. For example;


  • Provision them into the HR system like an actual "worker" and use IDM to synchronize them out
  • Provision directly into IDM, perhaps through a workflow
  • Create a database of virtual workers that provisions into IDM
  • Create accounts as a "Non-Human" account within AD, or LDAP directly on a per application basis


I was hoping to get a pulse on if others were experiencing challenges, or had any recommendations related to management of these types of "workers".

Thanks!
  • JWMerrow;2486312 wrote:
    This is a little bit of a change of pace; but I was wondering what others are doing to manage "virtual" workers. With our investment into robotic process automation (RPA), our company is creating faux user accounts for automating computer "task work". I was wondering how others may have tackled this challenge. For example;


    • Provision them into the HR system like an actual "worker" and use IDM to synchronize them out
    • Provision directly into IDM, perhaps through a workflow
    • Create a database of virtual workers that provisions into IDM
    • Create accounts as a "Non-Human" account within AD, or LDAP directly on a per application basis


    I was hoping to get a pulse on if others were experiencing challenges, or had any recommendations related to management of these types of "workers".

    Thanks!


    I haven't done this, but my previous interactions with various HR types makes me think that you'll not get non-people in the HR system, so I'm thinking your first option there is likely a non-starter.

    #2 and #3 are essentially the same. Somebody, somewhere, is the source of authority for these non-people. You could use a PRD to allow them to be created. Or you could roll some web application with a back end database, and get them from that (JDBC). Or, I suppose, your custom web application could supply the details via SOAP or REST, either to a driver, or to a PRD. In the end, it's all the same thing, just the implimentation details change a bit.

    #4, maybe. I'd need a better understanding of what these accounts are for, what they need, and whether it makes sense to provision them centrally from a vault, or not.
  • JWMerrow;2486312 wrote:
    This is a little bit of a change of pace; but I was wondering what others are doing to manage "virtual" workers. With our investment into robotic process automation (RPA), our company is creating faux user accounts for automating computer "task work". I was wondering how others may have tackled this challenge. For example;


    • Provision them into the HR system like an actual "worker" and use IDM to synchronize them out
    • Provision directly into IDM, perhaps through a workflow
    • Create a database of virtual workers that provisions into IDM
    • Create accounts as a "Non-Human" account within AD, or LDAP directly on a per application basis


    I was hoping to get a pulse on if others were experiencing challenges, or had any recommendations related to management of these types of "workers".

    Thanks!


    It is looks, that RPA is a new common trend (like virtualization or cloud).
    We had a similar discussions couple of months ago.

    From the beginning, the project decided to make the shortcut (create accounts as a "Non-Human" account within AD, or LDAP directly on a per application basis).
    After a month of use this "manual shortcut", they started to recognize a number of related to manual process issues and finally want to formalize the process and start robots onboarding from HR.
    "New" direction: HR will create a "special" contractor record for every robot. These records have special contractor types. Rest of the processes still unchanged.
  • I would also go with option 2 or 3 depending on who will create the accounts.
    I also strongly recommend that also these accounts have a "manager" I find too many non human accounts that nobody seems to own or claim ownership for and yet no one wants to remove them because it is scary to be the one who breaks the system.

    Good luck
  • On 8/28/2018 7:44 AM, joakim ganse wrote:
    >
    > I would also go with option 2 or 3 depending on who will create the
    > accounts.
    > I also strongly recommend that also these accounts have a "manager" I
    > find too many non human accounts that nobody seems to own or claim
    > ownership for and yet no one wants to remove them because it is scary to
    > be the one who breaks the system.


    Does a singular manager help, or would an Org Role or Group be better so
    'ownership' can be passed around?

    Of course your root problem is that no one takes ownership, so expecting
    them to pass the buck may be too much to ask.


  • I also strongly recommend that also these accounts have a "manager" I find too many non human accounts that nobody seems to own or claim ownership for and yet no one wants to remove them because it is scary to be the one who breaks the system.

    This is main reason, why these "virtual workers" (robots) life cycle suppose to start in HR (or closest to HR system) and follow all "standard" identity life cycle steps.
    For identity behavior is almost no differences between human (working for wages) workers and virtual workers.
  • A lot of good information and feedback all around. Thank you dgersic, al_b, geoff, and joakim!

    In alignment with expectations; the HR route is challenging since we would be entering non-human "workers" into the system. However, inherently the HR solution seems to address a lot of the concerns around ownership (i.e. the "manager" of the worker). I think this may be the route we will go down since ownership and re-certification of these IDs is important to our organization.


    #2 and #3 are essentially the same. Somebody, somewhere, is the source of authority for these non-people. You could use a PRD to allow them to be created. Or you could roll some web application with a back end database, and get them from that (JDBC). Or, I suppose, your custom web application could supply the details via SOAP or REST, either to a driver, or to a PRD. In the end, it's all the same thing, just the implimentation details change a bit.

    #4, maybe. I'd need a better understanding of what these accounts are for, what they need, and whether it makes sense to provision them centrally from a vault, or not.


    I think there may be some confusion on my initial post; I will try to break them down a little better. :)

    #2 - I was thinking of a UserApp Workflow where colleagues could "request" or "terminate" a non-human account

    #3 - In this case, the RPA team would keep a database of their "non-human" workers and an IDM JDBC driver would (de)provision them based upon the DB view/table

    #4 - If a human worker account was provisioned by IDM into eDirectory LDAP, Active Directory, etc.; this would be each account provisioned independently in those systems instead of managed within IDM (i.e. "don't manage the accounts")


    Thanks,
    -JW
  • Geoffrey Carman wrote:

    > Does a singular manager help, or would an Org Role or Group be better so
    > 'ownership' can be passed around?
    >
    > Of course your root problem is that no one takes ownership, so expecting them
    > to pass the buck may be too much to ask.


    You might want to link those accounts to a department or costcenter instead (or
    additionally). There's always an owner/manager for these and whoever owns the
    costcenter or manages the department also has final responsibility for the
    account.

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)