Anonymous access

2479
8
03-21-2017 11:42 AM
KevinSayer
New Contributor III

Can somebody please explain the relationship (or lack of one) between anonymous access on the portal Web Application and anonymous access to portal items through the SDK?

If I disable anonymous access on our private portal instance then via the web browser, I always get redirected to the login page and cannot access anything without logging on first.  That is obviously expected behaviour.

With the same setting (anonymous access disabled), when using the SDK I seem to be able to retrieve any portal item that is marked as public, without providing any credentials.  The PortalInfo.Access property returns the expected values i.e Private when anonymous access is disabled and Public when anonymous access is enabled, but this doesn't seem to have any bearing on whether I can retrieve portal items or not.

The Portal is configured to use the internal identity store with ArcGISToken based authentication and there are definitely no credentials added to the AuthenticationManager or supplied when creating the portal instance.  My assumption is that this makes me an anonymous SDK user and therefore I shouldn't have access to any content.

I'm using ArcGIS Portal 10.4.1 and the new Quartz SDK.  I've tested against Portal 10.3.1 too and get the same behaviour there.  Am I misunderstanging something or is there a bug in the SDK?  If it's a bug, does anyone know if it's fixed in Portal 10.5?

0 Kudos
8 Replies
JenniferNery
Esri Regular Contributor

When you have a portal with anonymous access disabled, to create that portal, be able to search items, and create portal item with it, etc. using ArcGIS Runtime for .NET, you'd have to pass credential parameter. Otherwise, you only get portal info.

try
{
    var credential = await AuthenticationManager.Current.GenerateCredentialAsync(new Uri("<your portal uri>/sharing/rest"), "<your portal username>", "<your portal password>");
    var portal = await ArcGISPortal.CreateAsync(new Uri("<your portal uri>"), credential);
    var items = await portal.FindItemsAsync(new PortalQueryParameters("access:private"));
    var portalItem = await PortalItem.CreateAsync(portal, "<your portal item id>");
}
catch(Exception ex)
{
    MessageBox.Show(ex.Message);
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

When you have a portal with anonymous access enabled, you don't need to pass credential when you create that portal but will only have access to public portal items. If you try to create portal item with private access, you should be prompted with a challenge for your portal username and password.

AuthenticationManager.Current.ChallengeHandler = new ChallengeHandler(async (info) =>
{
    var credential = await AuthenticationManager.Current.GenerateCredentialAsync(info.ServiceUri, "<your portal username>", "<your portal password>");
    return credential;
});

How are you creating the portal and getting the portal item? I can't seem to reproduce getting portal items from a portal with disabled anonymous access if I don't provide credential.

0 Kudos
KevinSayer
New Contributor III

Hi Jennifer,

Thanks for the quick response.

I'm definitely still seeing the reported behaviour so here is the code I'm using with commented results per line:

It's probably worth reiterating that we're using the Portal's built in Identity store and ArcGISToken based authentication.  As such, the web Adaptor deployed in IIS has anonymous access enabled as we're not using web tier authentication, but the portal has it disabled.

private static readonly Uri PortalUri_104 = new Uri("http://<ServerName>/arcgis/sharing/rest");

public async Task ConnectAsync()
{
    try
    {
        AuthenticationManager.Current.ChallengeHandler = new ChallengeHandler(async (info) =>
        {
            var credential = await AuthenticationManager.Current.GenerateCredentialAsync(info.ServiceUri, Username_104, Password_104);
            return credential;
        });

        // Portal created with no credentials passed
        var portal = await ArcGISPortal.CreateAsync(PortalUri_104);

        // The following line outputs Private when anonymous access is disabled and Public when it's enabled
        Debug.WriteLine("Current Portal Access: " + portal.PortalInfo.Access);

        // For test purposes, I've put a single, public Webmap in the public group being used 
        // as basemaps and that's returned here despite anonymous access being disabled.
        var basemaps = await portal.GetBasemapsAsync();

        foreach (var basemap in basemaps)
        {
            // Name is output ok here
            Debug.WriteLine(basemap.Item.Title);
        }

        // This returns no results as expected
        var resultSet = await portal.FindItemsAsync(new PortalQueryParameters("access:private"));                

        // This is a public item and it's returned ok despite anonymous access being disabled
        var publicPortalItem = await PortalItem.CreateAsync(portal, "fb68410db0eb411f82989f611f53d7cd");

        // This is a private item and as expected the request invokes the challenge handler
        var privatePortalItem = await PortalItem.CreateAsync(portal, "883f296272ff4891b22126b078ca0091");                

        // The following line outputs null
        Debug.WriteLine("Current portal credential: " + (portal.Credential == null ? "null"  : mPortal.Credential.ToString()));

        // The following line outputs null
        Debug.WriteLine("Current portal user: " + (portal.User == null ? "null" : mPortal.User.ToString()));
    }
    catch (Exception ex)
    {
        Debug.WriteLine(ex);
    }
            
}
0 Kudos
JenniferNery
Esri Regular Contributor

Hi Kevin,

Sorry for the delay. Public items and groups are expected to be returned according to ArcGIS REST API - Portal (see 'access' and 'canSearchPublic'). There may be other security settings you can configure in your portal to get your desired create/search capability, which ArcGIS Portal team or support might answer best.

I did some testing with our own portal (disabled anonymous access [access:false], disabled service directory [canSearchPublic:false]) using ArcGIS Runtime SDK for .NET code below. The result I got were as follows. Sharing both code and web request in case you want to plug in your own portal info.

AuthenticationManager.Current.ChallengeHandler = new ChallengeHandler(async (info) =>
{
    var credential = await AuthenticationManager.Current.GenerateCredentialAsync(info.ServiceUri, username, password);
    return credential;
});‍‍‍‍‍‍‍‍‍‍
var portal = await ArcGISPortal.CreateAsync(new Uri(portalUrl));
var privatePortalItem = await PortalItem.CreateAsync(portal, privateItem);
var publicPortalItem = await PortalItem.CreateAsync(portal, publicItem);
var privateFindResult = await portal.FindItemsAsync(new PortalQueryParameters($"id:{privateItem}"));
var publicFindResult = await portal.FindItemsAsync(new PortalQueryParameters($"id:{publicItem}"));‍‍‍‍‍‍‍‍‍‍
OperationDisabled Anonymous AccessWeb request
Create portalNo challengehttp://<portalurl>/sharing/rest/portals/self?f=json
Create private portal itemHas challenge, creates itemhttp://<portalurl>/sharing/rest/content/items/<privateitem>?f=json
Create public portal itemNo challenge, creates itemhttp://<portalurl>/sharing/rest/content/items/<publicitem>?f=json
Find private portal itemNo challenge, returns emptyhttp://<portalurl>//sharing/rest/search?q=id%<privateitem>&start=1&num=10&f=json
Find public portal itemNo challenge, returns item

http://<portalurl>//sharing/rest/search?q=id%<publicitem>&start=1&num=10&f=json

I wish I could help more but this seems to be a question better answered by ArcGIS Portal team since runtime API can only raise a challenge if server responded with authentication error. Apparently, public portal items can be created and searched regardless of disabling anonymous access on portal.

0 Kudos
KevinSayer
New Contributor III

Hi Jennifer,

Thanks again for your reply.  You seem to be confirming the behaviour I found which to my mind can only be a bug somewhere in the Esri technology stack.

Disabling anonymous access should mean that only logged in users gets to see any content and all other requests are denied.  The portal Web App deals with it correctly but for some reason the ArcGIS runtime SDK for .net doesn't.

The problem may well be in the Portal's REST API or whatever access point the runtime SDK uses that the Web App presumably circumvents.  Unfortunately I don't have time to try out other APIs and pinpoint the problem for you.

I have to say, this seems like quite a serious security flaw to me so I've linked this to the, "Portal For ArcGIS" community now to see whether somebody there has any insight or can raise a bug.

0 Kudos
dotMorten_esri
Esri Frequent Contributor

> Thanks again for your reply. You seem to be confirming the behaviour I found which to my mind can only be a bug somewhere in the Esri technology stack.

No this is not a bug, but by design. The Anonymous access Boolean really only applies to the _website_, It probably shouldn't even have been part of the SDK, since it's not that useful.

There's really two main properties here in your portal configuration that matters:
1. Can users of the portal share items publicly outside the organization.

2. Can users outside the organization perform searches against the org's public maps

Here's the scenario: "City of Foo has a portal that their employees can sign into and use. Citizens aren't able to access this portal. However any employee can create a map, share it publicly, then for instance embed it in their public-facing website for citizens to look at". This means if you already know the Map ID, you can get access o the webmap. If you don't want your employees to do this, disable "CanSharePublic".

The other part "CanSearchPublic" merely sets whether the search endpoint that can search for maps is available for anonymous users. This is really the one custom apps should look at, and not the anonymous access property talked about at first. Without it, it's near-impossible to make a usable portal app without signing in first, unless you ask users to enter map ids directly.

If you can search public, and you use the endpoint anonymously, only publicly shared maps are returned. If you sign in, more maps might be available to that user.

0 Kudos
KevinSayer
New Contributor III

Thanks to Morten and Jonathan for your explanations, at least I know there's nothing wrong with my deployments now.  You both seem to be saying that this is by design but it seems a bit odd to me that you would overload the behaviour of such a well known concept, particularly when it's security related.

If a web application has anonymous access disabled, or you've checked a setting that implies it should be at least, then it's entirely reasonable to expect to have to log in to do anything at all.  That's how the website behaves and I believe it's how most people (including Jennifer it seems) would expect the API to behave.

@Morten  I appreciate your explanation of the CanSearchPublic and CanSharePublic properties, but like you say, these are closely related but not totally relevant to the main point.  Jennifer introduced these into the conversation to try and explain things after realizing she was getting the same unexpected behaviour as me.

@Jonathan I agree that you could acheive the same effect by only sharing items with the organization.  That's a less convenient workaround however and presumably means there would be no need to disable anonymous access at all.

I personally think that when anonymous access is disabled, a more standardized and intuitive approach would be to just not allow a portal instance to be created without supplying credentials.

0 Kudos
dotMorten_esri
Esri Frequent Contributor

I'm not saying that the naming can't be a little confusing, but there are very good reasoning behind the capabilities. At this point it might be better to take this discussion up with the portal team, as this isn't really an ArcGIS Runtime question.

0 Kudos
JonathanQuinn
Esri Frequent Contributor

I think that anonymous access to the portal means the portal website, but you can still share items publicly which is unrelated to the anonymous access setting.  If you don't want people to access the portal or items without a login, set anonymous access to disabled and only share items with the organization.

0 Kudos