Super Contributor.. Brett Simpson_1 Super Contributor..
Super Contributor..
1240 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?

Labels (1)
0 Likes
1 Solution

Accepted Solutions
Micro Focus Expert
Micro Focus Expert

Re: System Account Alias? Managing Flow configuration between Dev and Prod

Jump to solution

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

13 Replies
Established Member.. TerrySummers
Established Member..

Re: System Account Alias? Managing Flow configuration between Dev and Prod

Jump to solution

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

Micro Focus Expert
Micro Focus Expert

Re: System Account Alias? Managing Flow configuration between Dev and Prod

Jump to solution

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

Super Contributor.. Brett Simpson_1 Super Contributor..
Super Contributor..

Re: System Account Alias? Managing Flow configuration between Dev and Prod

Jump to solution

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
michalhugim Absent Member.
Absent Member.

Re: System Account Alias? Managing Flow configuration between Dev and Prod

Jump to solution

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
reisen Absent Member.
Absent Member.

Re: System Account Alias? Managing Flow configuration between Dev and Prod

Jump to solution

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
Super Contributor.. Brett Simpson_1 Super Contributor..
Super Contributor..

Re: System Account Alias? Managing Flow configuration between Dev and Prod

Jump to solution

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
michalhugim Absent Member.
Absent Member.

Re: System Account Alias? Managing Flow configuration between Dev and Prod

Jump to solution

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
Super Contributor.. Brett Simpson_1 Super Contributor..
Super Contributor..

Re: System Account Alias? Managing Flow configuration between Dev and Prod

Jump to solution

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
reisen Absent Member.
Absent Member.

Re: System Account Alias? Managing Flow configuration between Dev and Prod

Jump to solution

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
Super Contributor.. Brett Simpson_1 Super Contributor..
Super Contributor..

Re: System Account Alias? Managing Flow configuration between Dev and Prod

Jump to solution

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
Micro Focus Expert
Micro Focus Expert

Re: System Account Alias? Managing Flow configuration between Dev and Prod

Jump to solution

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
Super Contributor.. Brett Simpson_1 Super Contributor..
Super Contributor..

Re: System Account Alias? Managing Flow configuration between Dev and Prod

Jump to solution

Hi Vlad,

Yes, the authorisation model for OO assumes that OO admins are the only ones overriding CI values. 

However, in our environment, the lay of the land is like this...

Multiple Operational teams will develop their own flows and content packs to automate their internal processes, and provide hooks into their environments for higher level end to end business processes to tie all the operational teams together.

These content packs per team will contain CI's (including System accounts) that only that team should be able to configure and override.

Why this way? Well the operational teams are the Subject matter experts for their areas, and are best placed to know what, how , when to automate.

i'm curious how other enterprises use OO. Do you have one OO team, responsbile for creating all the OO content packs, and managing OO configuration? then just give operational teams user access to view and run the flows? How do you deal with your Unix teams when you need to get them to give you the root passwords on their servers in order to automate tasks on their gear? Same for Windows admins?

regards

0 Likes
Bridges Respected Contributor.
Respected Contributor.

Re: System Account Alias? Managing Flow configuration between Dev and Prod

Jump to solution

We have one team responsible for the OO environment and content.  Flow are initiate via a trigger (HPSM service request, incident, etc) or via a web service call.  Access to specific server are via service accounts with the proper permissions (AD rights, sudo, etc) or via HPSA.  In general, user are kept off the central site.

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.