Subscribe
Accepted Solution

Can WFA workflow behave differently based on user ID or group?

IHAC who is a massive global auto manufacturer. Their storage team is truly global as are their storage operators.  They've asked an excellent question that would make WFA very attractive to them:

Can a single workflow offer different user inputs (i.e. a drop-down list of storage arrays) based on the user ID or the user group they belong to?  For example:

  • If Lewis Hamilton from the EMEA user group executes the workflow, allow him to select from controllers F1-a, F1-b or F1-c to provision from.
  • If Tony Stewart from the North America user group executes the exact same workflow, allow him to select from controllers nascar-1, nascar-2, nascar-3 to provision from.

Does WFA have this capability to dynamically change selection criteria based on which user or group is executing the workflow?  If so, please explain how as I'd like to set this up in the lab to demonstrate to the customer.

Thanks!

Reid

Re: Can WFA workflow behave differently based on user ID or group?

Hi Reid,

That's a great idea, but at this time I don't think that's possible.  What is possible is to clone the same workflows and change the query for which controllers get displayed according to each group that you want, then create separate categories for these workflows with the "Use for Workflow Authorization" checkbox checked, and add the users to the appropriate category.  It achieves the same functionality with a bit more complicated setup and maintenance of the workflows.

Thanks,

Dave

Re: Can WFA workflow behave differently based on user ID or group?

Thanks Dave.  However, that scenario is exactly what the customer is trying to avoid.  They don't want to have to maintain multiple copies of the same workflow to accommodate different geographical groups. This results in higher management overhead and a greater chance of inconsistency working its way into operations. For example, someone updated an important workflow with a new step, but forgot to update the same workflow for other geographies. They may not catch that mistake for months, during which environments are becoming more and more inconsistent due to the discrepancy between workflows.

I'll have to ask the development team if this is something we could request for a future release.  I could see this being utilized by multiple customers.

Re: Can WFA workflow behave differently based on user ID or group?

Due to the nature of WFA being an automation framework, this is not possible today... natively.  Now there are several ways that you could control these types of user inputs:

  1. Create a table in a database and create this mapping.  - WFA 2.0 will give you the ability to use a playground database to add your own custom tables.  This is not very clean but would work.
  2. As Dave said, create multiple workflows and control access via catagories
  3. Use Operations Manager groups to control dropdowns and controllers based on an Operations Manager selection.
  4. Create a custom web portal to link into the customers directory services (AD,LDAP,NIS,etc).  Use the portal and a database to control user input via account authorization. (Note: I have done this at another customer and it works very well)
  5. Integrate the WFA Automation Framework with an orchestrator to provide more granularity to user access controls

I realize that these answers are probably not what you were hoping to get but honestly these are the only available options today.

Re: Can WFA workflow behave differently based on user ID or group?

Easy enough to filter based on a selection like have the user select the group or custom comment tag, but that's still leaving the choice up to the user.  Without being able to pull the user ID that logged into WFA into the SQL query for the user inputs, it's not very secure.  If we could query an environment variable or something from the SQL attached to the user inputs to determine the user ID that logged in to WFA, then access could be controlled through DFM/OC-UM groups or via custom comments on the controller objects in DFM.

Without that, we're left with the unhappy choice of what I mentioned first, or a custom portal, and both are a lot of overhead.

Re: Can WFA workflow behave differently based on user ID or group?

+1 for Reids suggestion - being able to use or reference the userid/group/email from within the workflow seems like a desirable thing to do

Re: Can WFA workflow behave differently based on user ID or group?

So here's a definitive answer and I believe you'd be happy with it:

I've encountered the need in the past and created a feature request for it.

In 2.0, if you'd go and define a user input called "$_WFAUser" you'd be able to get that value (Of the user currently logged in to WFA).

It would be a read only input (ie shown on the screen in preview) with a pre-defined tooltip.

You can use it in queries to correlate the logged in user with information from additional tables (Either native ones from the DFM cache

or with proprietary info from the user-specific playground DB).

While admittedly it can use a little more polish - I believe this is very usable and will offer a viable solution to most use cases.

Hope that would help as I think it will.

Yaron Haimsohn

WFA team

Re: Can WFA workflow behave differently based on user ID or group?

Maybe I misunderstood the question, but is it not something that needs to be covered using something Role Based Access?

Because, if an administrator has access to the wrong system, he could still (manually) execute whatever (s)he wants.

In case of a foolproof WFA environment, the workflow needs to verify upfront if the correct access is available. Alternatively the workflow needs to be provided with good error or exception handling.

Re: Can WFA workflow behave differently based on user ID or group?

Hi schepers,

Reid is describing a different use case than the RBAC provided with WFA.  You are correct that WFA would confirm access prior to workflow execution.  RBAC is done at the category level in WFA.  An operator would never be presented with a workflow they were not authorized to execute, so there's typically no need to have RBAC functionality within the workflow itself. 

And now that we have this $_WFAuser functionality, we can customize workflows according to the user name that logged in as well, so the best of both worlds now.

Cheers,

Dave

rle Former NetApp Employee

Re: Can WFA workflow behave differently based on user ID or group?

What if the user name is the same as OnCommand?  Could OnCommand's RBAC be used to control which resource pool is seen?

   - Rick -