Framework for planning ArcGIS Enterprise Groups

[ChrisH2]

Our organisation is in it's early days of leveraging ArcGIS Enterprise and we're currently running with a quite simple approach of one user group per app. This works quite well at the moment as we have thematic apps where we may have something like Field Maps collecting data and a web map/dashboard for data access and visualisation. e.g. a "water infra" group for collecting data on fire hydrants. I do fear this approach will become unmanageable at some point and/or we'll reactively deploy new groups to suit particular use cases and create ourselves some issues that we'll have to unwind.

What we can (initially) see that we'll need is some broader groups that have access to larger thematic chunks of data (e.g. "asset management" for fire hydrants, bus stops etc...), but at this stage we've unsure of what else to consider when designing groups.

ArcGIS Sites is something we're thinking of implementing in the future, yet I don't feel our current group strategy is mature enough, plus we don't have a proper content tagging strategy.

Is anyone able to point out any resources on "things to consider" or any frameworks to help us with our group planning? I've looked through the ArcGIS resources without any luck yet

[Scott_Tansley]

I'm not sure that I can point you in the direction of additional reading, but I can talk about how most of my clients operate.

Most are using SAML2 and linking their Enterprise Portal groups with their SAML2 (AD) groups.  Apps get added to one or more groups.  They have the flexibility to create bespoke groups and add users to them.  Scenario, 10 people are in AD Group A and 5 from AD Group B.  An app is created for group A, but two people need access from Group B.  A 'bespoke group' is created in Portal and individual users added.  The app is then shared with Group A and the bespoke group.  If you later wanted to share with Groups B, then you just update the sharing on the item.

I would not follow the one app to one group, it sounds hard and inflexible.  Use existing business groups or define them.

The one thing that some clients have encountered is the 'My Organisation' level of sharing.  This represents all secured users, but sometimes my clients need to invite additional stakeholders into their portal,  e.g. contractors/consutlants.  They can see everything shared to the 'My Organisation' group.

The simple work around here is to put contextual and non-sensitive things that can be shared in that base layer of the sharing model.  Then have an additional group that you attach to an 'All staff' group from the AD.  I've seen people add "all users" but this puts the contractors in there as well if they're in that group.

Some system administrators will build groups in the AD privilege model that allows only genuine staff to be added there.  Attach this to a portal group with a name like "staff only", and then share items into that group that is available to all internal users.  This keeps stakeholders out.

As an extension of that model, I've seen people choose not to use 'My Organisation' as well.  They use the above 'staff only' model, stakeholders get a specific group related to the project they're on.  Nothing is in 'my organisation' and so they cannot see anything that is not explicitly shared with them.

One day, I'll find time to put the above into a diagram/blog, but for now that's the best I have to describe it.  I hope it helps.

[ChrisH2]

thanks for the detailed reply Scott, there's quite a bit to consider in there especially the use of "My Organisation" (or not). Good tip.

We have quite a few contractors using our apps and our conservatism here has led to the current model in order for Portal admins and the business/data owners to have some confidence that the contractors can only access apps and data that they are permitted to.

This also led us down a path where we actually have two groups per app if the data is sensitive. The first group can only collect, view and edit data that they've created - all contractors are in this group.  The second group can see all data for that app and this only consists of internal staff, and then only those that have a role with the data post data collection. Our dashboards are limited to this second group. Group./user admin obviously gets harder with this scenario

I can see that your suggested 'staff only' model may be useful for the non-sensitive data, and then perhaps augmented with project groups and or thematic groups like the "asset management" group. Lot's to consider. 

I should add that I'm on the data steward side here but have a significant desire to unlock the potential of ArcGIS Enterprise Portal, and provide my IT peers with some well thought out approaches to data collection , management and usage. Our experience with AGOL was a little wild west so I fear that the doors will shut pretty quickly if user/data management becomes too cumbersome.

My other prompt for starting this thread was to streamline the access to feature services for ArcGIS Pro and ArcMap users, and use the groups in some way to filter layers in the WAB app (nominating a group in the curated option of the Add Data widget)

[Scott_Tansley]

Wild west is a common theme for AGOL usage.  Several clients have used the same words.  As they adopt ArcGIS Enterprise, they are taking the same controlled approach.  The use of existing groups from SAML2 sources really does make a difference, but clearly, you need to know the names and contents of those groups.  Best to build a close relationship with your system administrator. 😉

There are tools out there that can help reign in the wild west, and other security tools that filter what users can see.  I believe the forum rules discourage promoting specific products.  I would recommend using some appropriate search terms in the ArcGIS Marketplace though.  I think you may quickly discover what I'm talking about.

My view on many things security is try to simplify as much as possible.  An 'internal group' sounds possible, and especially when you consider special groups, like assets, as you mentioned.

I cannot stress enough that tagging items is critical, and if you get it right, then the use of Sites can streamline the discovery of items in the portal.

Have fun, it sound like you're on the right track.