Highlighted
Super Contributor.. Super Contributor..
Super Contributor..
1392 views

System Account Alias? Managing Flow configuration between Dev and Prod

Jump to solution

Hi,

i'm looking for tips on how people manage developing their flows using System Accounts. We have a dev and prod OO implementation. Obviously we develop our flows in our Dev environment, talking to other dev applications. As such, the System Accounts we have in OO Dev, are different to the user credential required to run the sam flows against production applications.

 

So my question, how do you develop your flows in dev, to use System accounts configured in OO Dev, against dev applciations, and migrate the final Content Pack to production, when the production OO requires a different System account?

e.g. Let say i've written a flow to export OO's audit data before we run HP Purge audit data flow. To do this, i've configured a System Account in OO Dev with the OO DB username and password. This is used by my flow to access the db and export the data. I package this flow and System Account into a Content PAck, and when happy with its functionality, migrate it to OO production... but oops, the OO prod DB username and password is different!

Am i missing something?

0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

Hi,

A possible solution for you would be having central overrides for the system accounts on production (or on dev, whatever seems more convenient to you).  Basically for any configuration item central supports 2 distinct values: the deployed value (ie the value entered from studio during authoring) and  an actual value which can be set up either in central or during flow runtime. If the actual value is blank flows will always use the deployed value, however if the actual value is not blank that is the value that will always be used. The override value (actual value) will not be reset once a new version of the content pack will be deployed, therefore once set it will remain like that until changing/ removing it. 

Now as i said you can use these override values either in dev environment create flows with SA from prod environment and override them in dev central with the values from dev environment, or use them in prod environment where you continue authoring flows as usual and only override the system accounts on the prod central with the details from prod environment.

Hope this helps,

Vlad

View solution in original post

13 Replies
Highlighted
Established Member..
Established Member..

We work exactly the way you describe.
What we do in production (or any environment like system Test/UAT) is as a part of the change control to migrate we have a step of correcting the password for the system account in HPOO.
So it is the same username right through the environments and when we migrate we ensure to set the right password.
The other method we use is AD accounts (So the system account username would be AD\testuser) so no matter which environment, if they all talk to the same AD the password is the same, but that won't help for local machine or app speciic passwords. 

Cheers
Terry

Highlighted
Micro Focus Expert
Micro Focus Expert

Hi,

A possible solution for you would be having central overrides for the system accounts on production (or on dev, whatever seems more convenient to you).  Basically for any configuration item central supports 2 distinct values: the deployed value (ie the value entered from studio during authoring) and  an actual value which can be set up either in central or during flow runtime. If the actual value is blank flows will always use the deployed value, however if the actual value is not blank that is the value that will always be used. The override value (actual value) will not be reset once a new version of the content pack will be deployed, therefore once set it will remain like that until changing/ removing it. 

Now as i said you can use these override values either in dev environment create flows with SA from prod environment and override them in dev central with the values from dev environment, or use them in prod environment where you continue authoring flows as usual and only override the system accounts on the prod central with the details from prod environment.

Hope this helps,

Vlad

View solution in original post

Highlighted
Super Contributor.. Super Contributor..
Super Contributor..

Thank you gentleman. 

Terry's process was what i thought i might have to use. However i like Vlad's approach, as it seems a little more elegant. I'll check the options within our Dev environment, and then post back some kudos etc.

 

cheers

0 Likes
Highlighted
Absent Member.
Absent Member.

Hi Brett,

You got good answers. Just to stenghten a bit what Vlad described - your use-case is actually exactly what we had in mind when we built the option to set System-Account credentials in Central. Understanding that while the account function is the same (e.g. DBA), the actual credentials are different among different OO envs (as you said - dev\prod). So this is exactly what you should do in Central - configure the System Accounts values.

(see attached screenshot from OO Central).

Regards,

Michal. 
HPE OO R&D.

 

 

0 Likes
Highlighted
Absent Member.
Absent Member.

Hi,

Adding to the above, there's actually another good reason to use Central overrides for SA passwords: security.  Setting passwords in Studio means they are included in the content pack data, which is less secure than using overrides, so it is not recommended.

Regards,
Rotem

0 Likes
Highlighted
Super Contributor.. Super Contributor..
Super Contributor..

Hi All,

Thank you for your feedback. The SA override does seem to address my needs regarding the actual passwords and username scenario between Dev and Prod. However, it seems the security model for managing these overrides is a little too high level. e.g. it seems you can only assign permissions within central to "View Configuration Items" or "Manage Configuraiton Items".. you cannot assign permissions at the CI folder level... whereas you can for example assign permissions at the folder level of flows, or on individual flows.

So in our Enterprise, we have many operational teams. Each team control their Operating System and application root/admin accounts and read only accounts. They are VERY possessive about who knows these root account passwords. They will not accept other teams being able to modify their System Accounts either. So the best option i can see, is only allowing my team (OO admins) the ability to modify CI overrides, and hope they will accept a process of them having to come to one of my teams desk, and enter in the SA password overrides in production?

 

is anyone aware of any ER requests to improve the granularity of OO authorisation models to include Config Items?

 

regards

0 Likes
Highlighted
Absent Member.
Absent Member.

Actually for System Accounts, the permissions ARE configurable in the folder / system-account level.

See the "Permissions" panel in the screenshot I attached in my previous post (on the right bottom).

You can configure which Role can view and run which System Account / folder.

0 Likes
Highlighted
Super Contributor.. Super Contributor..
Super Contributor..

Hi,

you seemed to have missed my point. View and run is not in question. Setting the override values are. From my testing, this is controlled via the role permissions, either "View Configuration Items" or "Manage Configuration items"? and NOt the "View and Run" permission? Please correct me if wrong.

0 Likes
Highlighted
Absent Member.
Absent Member.

Hi,

To modify a system account, you need to have both permissions (the global one, and the per-item "View and Run").

So to achieve what you want, you can create different roles for the different SA managers, each having the "View and Run" permission only for the specific account(s) they need to manage (in addition to the global "Manage Configuration items").

Regards,
Rotem

0 Likes
Highlighted
Super Contributor.. Super Contributor..
Super Contributor..

Hi,

Thats not going to work either, as once you've granted the "Manage Config Items", none of the other config items type have security permissions, so they can then edit other teams System Properties, Group Alias etc. which only OO Admins should be able to edit...

So as i said, the permission model on Config items is not granular enough..

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Hi,

Let's brake down the permission and entitlement levels a bit further and see if we understand the needs and usecases so we are talking about the same scenarios.

For all configuration items there are 2 permissions that are at the root of the system: view and manage configuration items (from now on reffered to as VCI and MCI respectively). Now with VCI the user can see and utilize the CI, however cannot change their values, while with MCI the user can also modify their values (ie create overrides for them). 

Starting with 10.20 for system accounts (SA) which contain more sensitive data entitlements have been added to them similar to the entitlements available in the flow library, as well as the ability to have CI ordered into folders.  The entitlements for SA  can be set on SA level, folder level or on all SA (similar to flows). Granted the entitlement system on the SA is simplified compared to flows (you can either see the system account and use it or not), however on top of the permission system this works very well to add another layer of security for SA,. In practical terms if a role is granted the "view and run" entitlement over a SA or SA folder the users from that role will be able to see the SA and their overrides, otherwise they won't be able to see or use them (even if by some mistake during authoring a flow they have access to uses one of those system accounts). This in turn means that the oo admins get the full access rights (MCI+ view and run)  for all SA folders, while the various teams will only get VCI and "view and run" on specific folders. 

Now for the rest of the CI which are not as sensitive as SA while it is true that everyone can see them, if the have at least VCI, the same mechanism will work: oo admins receive MCI so they can add overrides if needed, while the regular team members only get VCI. The users with VCI will still be able to see and use (if needed) the CI, however they will not be able to edit them. 

In case a member of a team needs to be both in the team and oo admin pool of users that can also be solved by adding both roles to the user. If the user is an LDAP user, then in order to achieve this the focus is shifted from the roles and OO users to the LDAP user groups of which that user is a member of. 

If you want to have the same entitlement system from SA extended to the rest of the CI, open an enhancement ticket with support and see where things go from there.

Regards,

Vlad

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.