カスタマイズされた AGOL/Portal アプリのユーザー認証パターン

Question

クライアント向けにカスタマイズされたマッピングツールの作成を検討しています。彼らは標準の AGOL/Portal アプリを出発点として使用し、独自のカスタムウィジェットを追加してさまざまなビジネス固有の機能（他システムとの統合、カスタムマップマークアップツールなど）を実行したいと考えています。私は WAB Dev. Edition を使ってテストアプリをダウンロードし、いくつかのウィジェットをカスタマイズしてから内部テストサーバーに展開しましたが、すべて正常に動作しています。テストアプリは全員と共有されている AGOL マップを使用しているため、ローカルホストされたアプリに入る際に AGOL ログインフォームは表示されません。<\/P> <\/P> 私の質問は、このアプリのユーザーアクセスシステムの作成に関するものです。クライアントは複数の ESRI Named User アカウントを持っていますが、潜在的に 50～100 人の内部ユーザーがアプリケーションにアクセスできるようにしたいと考えています。これらのユーザーは複数のレイヤーにアクセスし、それらのレイヤーを編集できる必要があります。クライアントのローカル Portal インスタンス内でいくつかの SDE フィーチャクラスが作成されており（フェデレーションされた ArcGIS Server 経由で公開されているため、Named User アクセスがあります）、アプリ起動時にこれらのレイヤーをマップに追加する方法（Named User アカウントでレイヤーを認証する方法）はわかりましたが、これは Named User アカウントを保存し、複数ユーザーが同じ Named User アクセスポイントを使用することを許可する可能性があり（これは ESRI ライセンスに準拠していないと思われます）。<\/P> <\/P> ここでの選択肢は何でしょうか？ESRI ライセンスは、全員と共有されている共有マップに（実行時に）レイヤーを追加することを許可していますか？もしそうなら、これらのレイヤーは SDE データベースから来て ArcGIS Server 経由で公開されてもよいのでしょうか。非フェデレーションサーバーから標準 ArcGIS Server 認証が使用された場合はどうでしょうか？つまり、Named User ではない ArcGIS Server ユーザー管理ツール内でユーザーを作成する場合です。<\/P> <\/P> 基本的には Named User システムを使わずにアプリケーションへのユーザーアクセスを管理したいと考えています。技術的には可能なようですが、ライセンス上問題ないのでしょうか？<\/P> <\/P> この質問を地元サポートに問い合わせましたが、まだ明確な回答は得られていません。<\/P><\/BODY><\/HTML>

EugeneLamnek · Answer

Thanks, I will look at the video and the pdf.

In our case all users will need to edit, but some of them will only edit infrequently, so level 1 may not be suitable.

Also, another reason for us looking at other authentication methods is we want to provide integration with a non-spatial web application that operates within the clients organization. By integration, I mean things like: user clicks on a spatial feature on the map, which triggers a call to a web service that goes off and finds matching records from the non spatial application based on spatial ID of the feature and returns the matching record(s) which then gets displayed in a custom widget. The existing non-spatial app has its own system of user, roles, groups etc. so we were hoping to be able to use this for the hosted web app, rather than maintaining two systems of users (one owned by non-spatial app and the other being Named Users).

XanderBakker · Answer

Hi Eugene Lamnek ,

'You can however (as far as I now) add layers on the fly on a Web App that is published on a local web server.'

By local web server, do you mean a web server on the internet as opposed to having the app running from AGOL/Portal?

And do you mean, you can add layers that require authentication, as long as the map is not publicly shared?

It can be a web server inside your own infrastructure or in the cloud, accessible from outside your organization or only available inside your organization. If you download for instance a template application you can modify it or use for instance Web AppBuilder for ArcGIS (Developer Edition) | ArcGIS for Developers . What you cannot do is configure an application in ArcGIS Online and share it publicly and consume content that is not publicly available. If you create a webmap in ArcGIS Online and share that publicly, it cannot contain services that are only available behind your firewall. If you add those layers on the fly, the web map on ArcGIS Online will not have any layers that are not publicly available.

With your second point, I understand sharing named users is not allowed. But (my knowledge is limited on this because I haven't tested it) if you are loading layers from a non-federated ArcGIS Server, they would not need to be authenticated by the named user and so no named user sharing would take place??

That may be the case, but if you are going to implement ArcGIS Enterprise, the base deployment (Server, Portal, DataStore and WebAdaptor) will require Federation between the ArcGIS Server and Portal. I think I read this in the slide notes from the presentation on Architecting Your Deployment: See video here: ArcGIS Enterprise: Architecting Your Deployment - YouTube

I will CC Philip Heede hopefully he can clarify this for you.

There is also a great document that might be interesting to read (updated last month): https://www.esri.com/~/media/Files/Pdfs/products/arcgis-platform/architecting-the-arcgis-platform.pdf

Third point, I agree that the named user system would work well, but as the system grows, from what I understand, large costs are involved in having so many named users, many of which may only access the application very infrequently

From "architecting-the-arcgis-platform.pdf ": An ArcGIS Identity is managed as a named user credential within the platform. This credential is used to sign into any app, on any device, at any time, and to provide access to all maps, apps, data, and analysis a particular user is entitled to. As users sign into the ArcGIS platform with their named user credentials, their identity gives them access to authoritative data, GIS capabilities, shared content, apps, and their saved maps and items. The named user model allows an organization to securely and appropriately extend the reach of its geospatial capabilities to everyone who needs them.

So by implementing the named user model, you avoid developing some access to data and applications and you probably miss out on some really good stuff. There are two levels of named users. As far as I understand from your explanation, you will have many users that will simply use the application but not create any content. Those users can use a named user of level 1 which is about 1/5th of a level 2 named user.

EugeneLamnek · Answer

Thanks for your comments. Not sure what you mean by your comment:

'You can however (as far as I now) add layers on the fly on a Web App that is published on a local web server.'

By local web server, do you mean a web server on the internet as opposed to having the app running from AGOL/Portal?

And do you mean, you can add layers that require authentication, as long as the map is not publicly shared?

With your second point, I understand sharing named users is not allowed. But (my knowledge is limited on this because I haven't tested it) if you are loading layers from a non-federated ArcGIS Server, they would not need to be authenticated by the named user and so no named user sharing would take place??

Third point, I agree that the named user system would work well, but as the system grows, from what I understand, large costs are involved in having so many named users, many of which may only access the application very infrequently.