Select to view content in your preferred language

Security model approaches

1463
2
Jump to solution
01-29-2019 09:06 AM
JamesCrandall
MVP Frequent Contributor

I'm attempting to solve a design problem with one of our ESRI JavaScript (WAB) applications.

Scenario: Web application "A" (non-ESRI) is a business system that opens web application "B" (an ESRI JavaScript app) that is publicly accessible but contains a secured feature service for editing.  Users are authenticated into Web app "A" and we do not want additional challenge for credentials when application "B" is launched from a button within application "A".

So far the most logical design I've come up with is:

1. Have application "A" request a token from the AGS site that the secured feature service is published to using a service account we have designated.

2. When the user opens application "B", application "A" will include that token as a url parameter and I have some JavaScript in application "B" that can grab the token and then append it to any requests against that secured feature service.

While this will eliminate any second challenge for credentials, having the token in the url is not all that desired from our security team.

Any ideas on alternatives?


Thanks!

0 Kudos
1 Solution

Accepted Solutions
JamesCrandall
MVP Frequent Contributor

We have implemented the security model as originally proposed.  Use of cookies prompted some additional concerns and I was able to justify token as a url parameter by demonstrating that the service account associated with generating the token is only valid for that single feature service, which cannot be used on other editable feature services and comes with a 30min expiration.

1. Have application "A" request a token from the AGS site that the secured feature service is published to using a service account we have designated.

2. When the user opens application "B", application "A" will include that token as a url parameter and I have some JavaScript in application "B" that can grab the token and then append it to any requests against that secured feature service.

View solution in original post

2 Replies
JamesCrandall
MVP Frequent Contributor

One alternative to passing the token in the url that I have prototyped but would like comments on:

1. Have application "A" request a token from the AGS site that the secured feature service is published to using a service account we have designated.

2. Have application "A" save the token as a cookie in local storage on the client.

3. When the user opens application "B", that cookie is located and the token value acquired from it within application "B" startup: function(){} then append it to any requests against that secured feature service as needed.

0 Kudos
JamesCrandall
MVP Frequent Contributor

We have implemented the security model as originally proposed.  Use of cookies prompted some additional concerns and I was able to justify token as a url parameter by demonstrating that the service account associated with generating the token is only valid for that single feature service, which cannot be used on other editable feature services and comes with a 30min expiration.

1. Have application "A" request a token from the AGS site that the secured feature service is published to using a service account we have designated.

2. When the user opens application "B", application "A" will include that token as a url parameter and I have some JavaScript in application "B" that can grab the token and then append it to any requests against that secured feature service.