Portal and Event Editor: Users and the AnonymousWebUser

[JamesDower]

Hello!  We've trying to set up a Roads and Highways install with an event editor secured by Portal, using the built in user store.  We've been able to log in to the event editor through using Portal successfully, but are only able to view the map if there are no restrictions placed on the map service in Server Manager.  After doing this, all edits/locks go to AnonymousWebUser.  According to the documentation, resolving this would involve restricting the access to the map service, but the Server Manager users and Portal users are different groups, and brings back the messages about not having access to the map service after logging in through Portal.  It feels like we're missing something relatively basic, but can't find it in the documentation. Any suggestions or further areas to explore would be greatly appreciated.

[NathanEasley]

Hi James,

Is there a reason you can't share the service with everyone in the organization?  This would allow the service to not be public (and eliminate the anonymous web user issue), but still ensure users in all groups in your organization can access it.

Nathan

Esri Roads and Highways team

[JamesDower]

Hey Nathan, 

Thanks for the feedback, we've tried sharing it with everyone that has accounts to our server, as well as the "anyone who is logged in", but there seems to be something we're missing in terms of connecting the user access and the access to the service.  Is there anything more detailed in the sharing, or does it require a federated server?  It doesn't appear that way in the documentation.  Our requirements were to be able to limit access to the event editor (we assumed Portal would be the built in method for that), and to enable editing history and different logins/roles for the edits.  From reading through the documentation that seemed to imply once the event editor was in place we would need to secure that using Portal or LDAP, and then flow from there.. Bit of a less common implementation I guess.

[NathanEasley]

Hi James,

Yes you need to federate your server with portal in order to deploy correctly.  See this topic for more information Configuring security in the Event Editor—Event Editor for Roads and Highways | ArcGIS Enterprise.

Nathan

Esri Roads and Highways team

[JamesDower]

Hi again, 

I think this part: "If you would like to use a secured map service, you must register the Event Editor web app with Portal for ArcGIS to federate your ArcGIS Server site with Portal to support single sign-in." was the part that we hadn't really connected the significance of.  The process of registering the app was one we went through, but missed that the server must be federated to do the single sign-in as part of granting the access to the service.  It does make sense in hindsight, butwe hadn't taken it as a "must do" from the documentation we had read that the single sign in was required.  That's what we were trying to determine, if there was a way to connect those pieces without federation, but it does look to be the way to go!  We'll give it a go.  Thanks for the suggestions, I'll write again with results. 

[JamesDower]

Bringing this one back to update: with a few changes (modifying default.aspx to use TLS 1.2) and some work we've got the federated server working with security handled by portal for the Event Editor.  I guess the next question that you may have some familiarity with is determining user roles/permissions within Event Editor itself.  Am I right in reading the documentation (particularly around the event editor security model: The Event Editor security model—Event Editor for Roads and Highways | ArcGIS Enterprise ) that the way to separate different levels of access to different types of features is not through the users, but rather through the applications/services themselves?  In that anything selectable in a published and shared service through Event Editor will be changeable by those with access?  Is there are a way to publish the service for viewing, but not editing?  Just curious, trying to get a better handle on the granular level of permission.  

[AmitHazra]

Hello James

A common pattern among our enterprise-scale Event Editor deployments is to create business-unit and task specific configurations for editing events. In a practical sense, this means that for each configuration of Event Editor you'll publish one LRS-enabled service with only the event layers required by the end users' maintenance needs and then should they wish to have additional LRS event layers or other reference data layers (e.g. polygon boundaries etc) in their configuration you'll simply publish those layers as map services without LRS capability enabled.

From your Portal you'll then manage access to those web layers through group sharing at the service, webmap, and app item level. Each Event Editor configuration will have a default webmap with the one LRS-enabled service and then you can also add in any number of reference map layers so long as they are not LRS-enabled.

Hope that helps. If you have any other implementation questions please do not hesitate to ask.

Amit@esri