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

[reide]

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

[bdave]

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

[reide]

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.

[goodrum]

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.

[bdave]

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.

[fenton]

+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

[schepers]

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.

[bdave]

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]

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

   - Rick -

[schepers]

From my mind filers, WFA and OnCommand authenticate against the very same AD/LDAP services.So that should not be an issue.

Or do I miss something?

[girirp]

Rick,

OnCommand and WFA users are different. RBAC capability of OnCommand user is applicable to OnCommand only and it can't be applied to WFA users.

[bdave]

girirp is correct.  The credentials used for actions taken on Unified Manager and/or controllers is defined in the Credentials section of WFA.  It's separate than the user that logged in to WFA.  Some people have gotten WFA to use Active Directory for authentication with controllers by changing the account the WFA services run under on the Windows server to a domain account authorized to take actions on the controllers.  A neat little trick that is in use with at least one customer in EMEA. 

[bdave]

One further detail I checked with development before mentioning...

One might be concerned that the method you're planning might not be secure.  For example, you create a custom cache mapping between users and filers they can choose...  One might think that's fine for the GUI, but what about Web Services?  What if a deviant user uses SOAP or REST to execute a workflow, could s/he specify a controller outside your security mapping?

I'm happy to say that if a User Input variable has been "locked" (a checkbox in the GUI), then both SOAP and REST inputs will be validated according to the SQL used to restrict the list (or if type ENUM, validated against the predefined list).  If they tried to pass in an array name and the SQL query attached to the array variable does not find a match for that array name, they would receive an error message, something like, "The value for $variable is not a part of the list allowed", (not exact verbiage).  So, there is NO BACKDOOR through WFA's web services for bypassing the lists.  Of course, the built-in portal does not even offer the other choices to the user.

All of that to say that using ${_WFAUser} to restrict access to certain objects in a Workflow is a viable and secure option.

Cheers,

Dave

[schepers]

Do you want to have a workflow to be dependent of a user ? That is bringing the configuration in the workflow.

In my mind the configuration should be done outside the workflow.

[yaronh · Accepted solution]

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

[reide]

Yaron,

This will work as an answer to the customer for now.  However, it would be a fantastic feature to be able to alter selection criteria on the input menu (or make other decisions) based on the Active Directory user ID or group without having to query a separate database.  Basically, add this to the core WFA functionality somehow.  Probably a very big request, but I think our larger customers who are likely to leverage WFA would find it highly valuable.

Thanks.

Reid

[MICHAELWW]

Reid - my ans - is yes.  If the WFA is for a Oracle Provisioning scenario-  Upon login into WFA UI as a for ex: vpoadmin he/she will only sees the WFA profile assigned.  Login as OracleAdmin and he/she can access/edit any oracle WFA assigned to OracleAdmin user.  However, the OracleAdmin can see the vpoadmin WFA but cannot edit the profiles.  Oracleadmin can only execute the profiles assigned to he/she.   

https://communities.netapp.com/videos/2518

[reide]

Michael,

I'm not sure you understood what the customer was requesting.  Its more than just WFA's RBAC functionality on what workflows they can see when they log in. The actual workflow itself needs to dynamiically adjust depending on the user who is running it. So the exact same workflow would behave differently (i.e. show different selection criterial in the user-input menu) based on which user ID was executing it.

[hland]

So basically we would need to extend the DFM cache scheme to include user and role information from DFM. That should be possible.