Dirk:
There is the case of using the JavaScript APIs to hook to AGOL services which I believe also flows to Portal.
For example, we have a Javascript API based Mapzilla that uses AGOL's routing service.
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...)
Implementing Application Authentication | ArcGIS for Developers
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.
Cheers!
