Separate the AGOL and Hub Community login screens

[JeffShaw2]

When an organization licenses Hub Premium and gets an additional portal for issuing Hub Community accounts to external users, the Hub Community sign in options are added to the existing screen that staff see. That creates a very confusing mix of options for both sets of users, and can lead to users in both orgs trying to sign in to or create accounts that they shouldn’t or can’t use. I propose instead that when Hub Community accounts are activated by an org, and a user accesses that Org’s content, that users first be asked how they want to sign in. For example: 

That will enable the actual sign-in screen to be much simpler, and relevant. For example, only people who can actually use Facebook or Google to sign in will see those options. The same is true for Enterprise login options.

If our organization enabled Facebook and Google sign in options for Hub Community members as we would like to, the sign-in screen used for both AGOL and Community accounts would appear as shown below. Unfortunately, we have decided that we cannot enable the Facebook and Google options because of the problems it would create. Issues with the current sign-in screen include:

1. We do not allow staff to use Facebook or Google to sign in to AGOL. If they click the Facebook or Google option, it will auto-provision a Hub account, which Esri’s terms say they cannot use, resulting in extra work and cost for us.
2. Staff/contractors who find our content and want to sign in see the “No account?” text which tells them to create a Hub Community account. But Esri’s terms of use stipulate that you cannot create Community accounts for staff or contractors (other than for administrative purposes).
3. Community members see the STAFF enterprise login option even though it does not apply to them. Similarly, when we federate our Community accounts with a different provider, I am guessing that staff will unnecessarily see that option.

Another issue is that when someone creates a Hub Community account by using the email option and comes back to sign in, they have to know to choose the ArcGIS login option. But they have no idea what that is because the option they chose to create the account refers to it as a “Hub Community” account. Adding the screen proposed above would address that.

These issues are all in addition those related to Enterprise logins as addressed inImprove app sign-in experience (button naming & org-specific help)

Improve app sign-in experience (button naming & org-specific help)

Improve app sign-in experience (button naming & org-specific help)

[PamBond1]

The sign-in/sign-up experience when using Hub is less than ideal.  So much so for our organization that was are not using the "Follow" option in our Hub initiatives, we just thought it would be too confusing to everyday people.  It would be nice if the sign-in/sign-on experience was even more customizable:  add custom Welcome/Instructions text, choose which options you want to be visible for signing in (one or many), be able to customize button text, etc.  

[PeterKnoop]

Our institution would like to see Employee and Hub ArcGIS Online login experiences separated as well. 

In our case, we are hoping this can be achieved based on the URL the user is visiting. If they are going to the URL for our Employee org, then they get the login experience configured within that ArcGIS Online organization. If they are going to the URL for our Hub org, then they get the login experience configured for the Hub's ArcGIS Online organization.

For our Employee org, we want to be able to configure it to only show only SAML logins. We want to avoid having users accidentally enter their enterprise credentials into the arcgis login by mistake. And, we have no need for social logins this org, so we want to hide those as well.

For our Hub org, we want to offer all the options: SAML, arcgis, and social logins.