Select to view content in your preferred language

Client Facing Password for Shared Apps

9770
27
12-18-2015 09:46 AM
Status: Open
StephenLopez2
Deactivated User

Framing the Issue
You are working at a commercial real estate company and your market built a Shortlist Story App for McDonald’s. You want to share the App with the VP of Real Estate at McDonald’s, but there is sensitive information he wants to keep private. McDonald’s does not have an ArcGIS Online subscription so you are unable to create a create a new Group and add them to that Group.

What am I recommending?
Ideally, there would be an option to create a password for clients to access a web map or web app without the client needing an ArcGIS Online accountOn the client end, this app would look just like it does when you share publicly – no editing privileges, strictly viewing and interacting with data – but to access the map/app you must enter a password.

What is the current situation?
The current configuration requires a roundabout approach to accomplish this. The administrator must create a separate login for each client. But this causes several issues, one of them being that the client’s login allows them to access the entire organizations information, including usernames, contact information, and most problematic – other client maps/apps.

How would this benefit my company and my industry?
Having the ability to assign a password to a certain group that is client facing would be extremely valuable for ArcGIS Online users in the Commercial Real Estate sector.  It would eliminate the need to create an account for the client and provide an easier way of sharing sensitive information, which keeps things simple. In the commercial real estate industry, simple is key, especially when introducing new tools.

How would it work?

Creation
Creating the web map or web app would not change.

Sharing
A new sharing option would need to be added to the current sharing options for ArcGIS Online web maps and web apps. This new option would allow for the creator to share to a specific group or specific client, but instead of adding ArcGIS Online users to that group, the creator would simply be able to assign a password to that group.

This would also allow for several markets or users in an organization to use the same password for a client.

Client End
The client would receive a link to the web map or web app and a password from the creator. When navigating to that link, the client would be prompted to enter the password they received from the creator. Upon entering the password, the client would be able to access the web map or web app. 

The client would see exactly what the web maps and web apps look like when you use the current option of “Share with everyone” – no editing capabilities, strictly used for viewing and interacting with data. The only difference is this new shared option would require the client to enter a password to access the map/app.

Solving the Issue
Now you are able to share the Shortlist Story App with the VP of Real Estate at McDonald’s simply by sending him a link to the app and a McDonald’s specific password that grants access to the app.
 

27 Comments
PaulSolsrud

The lack of this functionality is extremely frustrating. As many have said people simply will go without instead of paying for a subscription - so why not make the data available to those who need it - it creates a hurdle for paying customers, and would likely not even touch the bottom line. Setting up AGO accounts for everyone isn't practical, and management of that wouldn't be fun. Why not charge for the option of sharing with a link, or require users to be exposed to some ESRI advertising or something. 

JeanineEGS

Great idea for small and medium business trying to engage people in decision making that is spatially aware and commercially sensitive  without them having to getting their customers to commit to a software license agreement, username, password, oragnisation managment, etc. 

We're ready to move on from the encrypted pdf. 

Show us the map already!

by Anonymous User

I'd like Viewable with the Link option, sometimes passwords are cumbersome.

But if you just need a password... why not just do what I do?  Lock the service with a token on Server. Done. When they try to open the viewer it will prompt for a login. Unlimited users. Unlimited different logins you can create. Takes only a few seconds. Been doing this for many years and it works perfectly.  

A second pattern I developed is for if you want only a subset of people to be able to Edit.  Use the Add Layer (in Custom Widgets here) and the standard Edit widget in WebApp Builder, and have a different Server token login for the editing layer(s) and when you click Add Layer it will prompt for login. The rest of the audience will be read-only for the viewer.

PaulSolsrud

Hi Kevin, 

Can you expand on "lock the service with a token on the server"? Is this using the app login with the JS API?

Thank you

by Anonymous User

Paul, by this I mean secure services.  You can simply create a username and password, and additionally create Roles that a user or users fall in to.  These services can be consumed in any of the APIs including JS API, as well as apps developed in the SDKs, ArcMap and Pro, mobile apps, and WebApp Builder viewers and StoryMaps.

https://enterprise.arcgis.com/en/server/latest/administer/linux/securing-services-with-users-and-rol...

by Anonymous User

The functionality of group based membership is already built into agol and portal.  What if you made everything in the organization only available to members of the group?  You could then give out a single username and password for that organization that the story map was created for.  Once the storymap your looking to share was placed in the group only the members of the group can view the content.  This allows you secure the rest of your organization by only sharing content with members of the specified group.  Things could be made public you wanted to be public but things you wanted to be private would of course then be password protected.  You could also customize roles in agol and portal that would allow for limited access and no editing privileges based on your needs.  

JeanineEGS

Hi Mark,

We already lock down user access to the limited contractor role and group you describe. The issue is more with ESRI’s definition of an Organization. It works fine in a public service environment with lots of licenses to allocate.

I cannot (esri legal terms and conditions)allocate a username license to anyone who does not directly work for my company.

In a business commercial environment it does not work to say the beautiful story map I made for my non-GIS client for their company board meeting annual presentation which will be viewed once or twice per year and is commercial in confidence will now need you to purchase and setup your own ESRI AGOL account with named user licenses for all your c-suite and board members, business, marketing and administration staff and manage it.so we can “collaborate “ in AGOL.

The oncost is prohibitive.

We need a lite viewer version.

The new Partner user type licenses may resolve this.

Sent from my iPhone

by Anonymous User

Jeanine I agree that would help us as well.  Along with this main topic, there is no way to collaborate between Organizations.  Users from another Org can't even edit a web map. 

allow users from two or more Orgs to edit a webmap   That limitation has impacted attempts at cross agency projects.

DevonBurton3

Mark, are you saying that we're allowed to pass out a single username & password to clients in order to view a protected / sensitive item, for the cost of a single viewer license? Because that's what it sounds like. 

ManolisNikolakakis

This is very useful in development phase where you would want to involve associates with no accounts to show first hand the progress of the work done, discuss issues, evolve an idea etc. 

Personally since there are rarely sensitive information I wouldn't mind making it public, however these unfinished web maps with under construction datasets are cluttering the living atlas catalogue, or misleading the members of my organization thinking of the published and shared to the public data as finished. Google Drive, or Youtube and I bet many others have a way to generate private links.