Yes, a named user account is designed and meant to be assigned to a real, live person in your organization. Regarding your specific need, please contact your local Esri account manager/Distributor to discuss the requirement in more detail.
Hope this helps,
Thank you for the reply, Derek. we do intend to contact our account manager.
For the sake of disclosure and clarity, I’d like to add some backstory to my question.
For starters, all our published GIS content is secure - this is our prime directive. We get do decide how to secure it and we have chosen ADFS.
Before Portal for ArcGIS (PFA), ArcGIS Server (AGS) instances were licensed per-core. Our license level allowed unlimited users to consume our GIS content and for us to publish as many GIS services as our hardware could handle. The problem was that it was only GIS services that were published - this pattern forced us to write complex APIs to consume the ArcGIS services and serve them as web applications with rich functionality. Our end users enjoyed secure GIS content, a rich user experience, and our organization was not constrained by fixed number of users. Additionally, our offerings included some significant GIS automation - the sorts of things we used to do with ArcPy and an AGE or AGD license we could instead do with the ArcGIS Rest API, our licensed AGS instance, and scheduled tasks.
Along came ArcGIS Online (AGOL) and PFA and with it came the concept of a web map - i.e., a collection of GIS services (maps, mostly) with rich function functionality embedded in the map that could be consumed by a much simpler API. Because it is easier to design and configure web maps, it’s possible to publish more of them more efficiently. And because the ArcGIS Rest API is still available, our GIS automation doesn’t have to change.
Unless we’re constrained by a fixed number of named users who are real, live persons in our organization…
The bottom line for us is PFA has the potential to make us more efficient at doing awesome ArcGIS things. However, the named-user pattern is potentially a deal-breaker. Our end users don’t care about the portal, they only want the secured web map content presented in our APIs. We have to weight that against the efficiencies that web maps give us.
At the end of the day, our organization has only a few true “named users” (i.e., “content publishers) who really need everything PFA has to offer. We also have a robot who only needs the AGS Rest API. And several hundred “unnamed users” who only consume web map content served into our applications and nothing more regarding the PFA.
It seems to me that the PFA governance pattern does not support our organizational profile. We recognize that our organization is a statistical outlier, yet at the same time I can’t believe that we are the only organization that is struggling with what PFA means to them.
Great question! The robot is owned by our organization. It does administration tasks, it does publishing tasks, it does user tasks. We could call him "Tyler Durden", but at the end of the day he's just a scheduled task...
To do that involves getting a token, etc... (the naming of the link below is slightly misleading, it discusses how to get tokens to AGOL services, etc...)
I seem to recall that this is based more on a registered application and a client id than an actual named user. And it is consuming a service rather than a web app but it's a similar concept. In essence, we have coded a robot to interact with AGOL's routing service.
I am confused a bit by one of your statements:
"We also have a robot who only needs the AGS Rest API. And several hundred “unnamed users” who only consume web map content served into our applications and nothing more regarding the PFA."
Do you mean that your robot and unnamed users are consuming content through your own custom written applications? i.e. basically via the REST endpoints? If so, isn't that just normal AGS consumption? I believe that a federated to Portal AGS's REST endpoints are still available to us via the normal REST mechanisms. (I sure hope I'm not wrong about that.)
But if the AGS data is being consumed via applications that are being created under Portal with the new smart maps and web apps, etc... then these are utilizing a lot more of Portal's functionality than just the REST endpoints, right?
You're taking advantage of the "...simpler API. ...easier to design and configure web maps ....publish more of them more efficiently"
I'm thinking from what you wrote that you are taking advantage of the Portal's ability to easily create smaller, lighter, more directed applications. And that indicates to me the need for named user accounts to access those web apps.
BTW - I like your description (below) of Portal, AGOL, etc.. Although I would say that the concept of a web map has been around for a very long time. For example: IMS or custom written JS web apps, etc...
Stealing from your well written words: What we are being given now is the rich functionality and much simpler API with which we can publish web maps and web apps much faster and more efficiently.
"Along came ArcGIS Online (AGOL) and PFA and with it came the concept of a web map - i.e., a collection of GIS services (maps, mostly) with rich function functionality embedded in the map that could be consumed by a much simpler API. Because it is easier to design and configure web maps, it’s possible to publish more of them more efficiently. And because the ArcGIS Rest API is still available, our GIS automation doesn’t have to change."
I think these are somewhat the days of unchartered waters. But it's my understanding (or maybe it's more a belief) that if I automate functionality, say via Python scripts utilizing arcpy and ArcREST, then I'm in essence only extending myself. The named user that I'm going to utilize in my scripts is going to be my Portal/AGOL admin account. Or perhaps as Tim suggests, we'll set aside a named user account, similar to how we might setup a domain level service account in our AD shop.
I'll be working with our Esri account/tech rep next week on just this sort of thing. As others have said, I suspect there may be individual differences across accounts as to how some things are setup and allowed, etc... e.g. We're under an ELA with certain licensing perhaps being unique to us. If I learn anything generic to Esri, I'll post it up.
One thing that I've learned about these new days is that Esri is open to feedback. It's a learning process right now, not only for us but also for them. More and more unique situations are going to be coming up and the more we can appraise Esri of how their licensing does or does not fit our needs and how we would like (or need) to see things changed then the more likely we are to end up with a mature product that benefits all parties.
Oops, "owns" is the wrong word in this context. The organization owns your position. When you win the lottery, the organization gets to load someone else into your position. So, maybe more along the lines of "who stewards the robot?" or from Paul's example, "of which ArcGIS Online for Organizations named user is the robot an extension?" Typically, IT scripts, apps, tools, processes, products, etc. have a "go-to" person (loosely described as an "owner"), and if you're lucky to be scaled, some backup people. This person could be proposed to Esri as having the named user account in Portal and/or AGO when discussing terms of service.
(shakes head) licensing... certainly keeps you busy.