nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Federating an ArcGIS Server site with your portal

shafitrumboo

Patrick Foppe Dan Huber

In case ArcGIS Server federated with an ArcGIS Portal. I wonder how the request traverses from one point to another point and how authentication is done Given the case I have HA of ArcGIS Server and ArcGIS Portal installation in place ( with out Webadapter and using Hardware NLB)

In case we have enterprise web application
Smart phone apps that will directly hit the ArcGIS server site configured
And In General I want to know the workflow

Encontre mais publicações marcadas com

Accepted answers

PF1

Hi Shafi,

Our agency is striving to use 'web-tier' with IWA for a few reasons:

Provide a Single-Sign-On experience. Even though some of our ArcGIS Server sites are 'public', many of our users access those on hardware controlled by our organization and are trusted by the domain controllers. Users are not required to separately login while accessing protected resources, publishing services, or administering the site.
I work for a government agency and encryption is supposed to be completed with a FIPS 140-2 compliant algorithm. Now I cannot 100% say that Microsoft Negotiate (which uses Kerberos or NTLM) is FIPS 140-2 compliant, but we are using that with many of our enterprise systems and have successfully acquired an 'Authority to Operate'. I know that the Esri 'Token' based authentication is not certified as FIPS 140-2 compliant and our IT security professionals are not interested in accepting the risk a proprietary authentication scheme.
We have found some significant vulnerabilities with tokens (which I wont detail here).

We still use tokens where necessary (there have been a few Esri products that do not work well with web-tier). I would expect your use of tokens would be just fine for your efforts.

---

Federation is completed at the 'site' level. So if you are running multiple machines in a single ArcGIS Server 'site' with a 3rd party load balancer in front of those, I would expect that you will just need to federate the 'site' using the load balancer URL.

If you are isolating the arcgis servers into individual sites, then you may need to federate each site with the portal. I have not completed this yet, so you will have to go through some trail and error to find out if its possible (or reach out to Esri).

---

For the Service URL it would be the http://reverseproxy.domain.com/myorg (assuming myorg is the 'instance' like arcgis)

For the Administration URL you will need to either enable administration functionality through your LB (not recommended unless there are other protections in place), provide an 'administration' url from your LB that has some protections in place, or use the back-end servers with the 6443 port.

---

Users will need to authenticate against the portal before being allowed access to the protected services. If your services are shared with 'everyone' then they can anonymously access those from your other enterprise applications.

All comments

PF1

Hello Shafi,

I think I understand your questions. You are running a highly-available ArcGIS Server (AGS) and Portal without the use of a web-adaptor. This implies you are NOT using web-tier authentication with either product but rather the Esri proprietary token based authentication.

My understanding is that when you federate an AGS solution with a portal solution that the AGS inherits the identity store and authentication/authorization methods of the portal. This means that you can use 1 identity in portal to authenticate and subsequently be authorized access (via portal groups) to the underlying services available in the ArcGIS Server. I highly recommend you read the article Accessing REST resources from a federated server article.

Bottom Line... since the AGS relies on the portal identities, the client application (enterprise web-app, smart phone app, etc) will need to authenticate against the portal to access the ArcGIS Server services. The developer will need to acquire a portal token and use the portal token to access AGS services. Since AGS uses a portal token, I believe that AGS checks the validity of the portal token with the portal to make sure the token is valid. Because of this, its best that the AGS and Portal live 'close together' (LAN based connection rather than WAN based) for performance reasons.

---

Here is an example with our on-premise deployment. Our portal is configured with Integrated Windows Authentication (IWA) using the web-adaptor. We are leveraging our existing Active Directory (AD) identities within our portal. Assume this to be: https://myportal.domain/portal/home

We have a federated ArcGIS Server with this portal. This ArcGIS Server does not use the web-adaptor and was federated with the portal. Assume this to be: https://myags.domain:6443/arcgis

When I access my ArcGIS Server outside of the portal with the direct url: https://myags.domain:6443/arcgis/rest/services I can see services that are shared with 'Everyone' (public anonymous). If I want access to a secured resource (a service shared with only a specific group), then I need to authenticate with my portal and pass my portal token. This assumes I'm in a group that is authorized access to the secured web-service. Looking at my AGS 'Info' Page: https://myags.domain:6443/arcgis/rest/info?f=json I see the following:

{
  currentVersion: 10.22,
  fullVersion: "10.2.2",
  soapUrl: "https://myags.domain:6443/arcgis/services",
  secureSoapUrl: null,
  owningSystemUrl: "https://myportal.domain/portal",
  authInfo: 
  {
  isTokenBasedSecurity: true,
  tokenServicesUrl: "https://myportal.domain/portal/sharing/generateToken"
  }
}

That just told me that I need to acquire a token from the tokenServicesUrl (which is the portal) to access secured resources. Per the documentation (see the 'accessing REST resources...' link above), I need to acquire a token with a 'Webapp URL' being the URL of the ArcGIS Server: https://myags.domain:6443/arcgis/rest

I can acquire a token with the methods above, and use the token to access protected resources in my arcgis server.

---

I would think a best practice of accessing services outside of the portal would be to do something like:

Query the ArcGIS Server 'info' page to identify the authInfo (authentication information).
Use the tokenServicesUrl to acquire a token for the end user. You will most likely need to prompt for a username/password. Make sure to set the 'WebApp URL' appropriately.
Use the token generated in step 2 for requests to the ArcGIS server, passing the parameter token with the value being the generated token. Make sure to protect this token as it represents an identity and if compromised could be used with malicious intent.
Monitor requests with the token. If the token expires (or is somehow invalidated at some point) either prompt for credentials again and acquire a new token, or securely retain the original credentials and generate a new token.

---

Bonus points (extra credit): If the HTTP Request to the AGS 'info' page fails with an HTTP status code 401 (unauthorized) and there is a www-authenticate header present, then use the www-authenticate header value to determine what sort of 'web-tier' authentication method is supported. I often times do this as we are striving to go web-tier anywhere available. Per the doc, this may not be necessary in your scenario:

If the server you want to federate uses web-tier authentication, you'll need to disable web-tier authentication (basic or digest) and enable anonymous access on the ArcGIS Web Adaptor configured with your site before federating it with the portal. Although it may sound counterintuitive, this is necessary so your site is free to federate with the portal and read the portal's users and roles. If your ArcGIS Server site is not already using web-tier authentication, no action is required on your part. You can continue with the steps below.

But would provide a code-base that would work for services federated with a portal, and services not federated with a portal. I ended up with the following pseudo-code in for a few 'tools' that I built:

Execute HTTP Request to AGS 'info' Page
if HTTP Response Status == 401 (unauthorized)
    if 'www-authenticate' in HTTP response headers
        
        #inspection options in order of preference
        if 'Negotiate' in www-authenticate header
            try 
                set kerberos authentication method
                retry request.  If success retain kerberos setting and continue processing
            except
                set NTLM authentication method
                retry request.  If success retain NTLM setting and continue processing
        
        if 'NTLM' in www-authenticate header
            set NTLM authentication method (Single-Sign on supported OR prompt credentials?)
            retry request.  If success retain NTLM setting and continue processing
        
        if 'digest' in www-authenticate header
            set HTTP Digest authentication method (prompt credentials?)
            retry request.  If success retain digest settings and continue
        
        if 'basic' in www-authenticate header
            set http basic authentication method  (prompt credentials?)
            try request again
        
        #how to handle SAML?
        
        #how to handle PKI?
        
        #others?  OATH?  OATH2?  Forms based?


if authInfo.isTokenBasedSecurity key of the HTTP Response DATA == True
    
    #this could be a portal, or it could be an ArcGIS Server token.  Handle both if different 
    Execute HTTP Request to the authInfo.tokenServicesUrl  (prompt credentials first)?
    Grab token from HTTP Response and use for future requests
    continue processing

But have yet to work out SAML, PKI, OAUTH, OAUTH2 and other authentication methods since we have not yet implemented those. Best of luck!

shafitrumboo

Hi Patrick,

Patrick Foppe

I appreciate your detailed answer.

1. Do you think it's better to use GIS tier authentication here actually I don't want to add other component i,e web adapter without any substantial advantage. What are the advantages of using Integrated Windows Authentication (IWA) using the web-adaptor

I want to know about integration of HA ArcGIS server federated with HA Portal for server.

Please i'm using this approach

HA Arcgis server setup

Multiple machine deployment with third party load balancer—Installation Guides | ArcGIS for Server

HA ArcGIS Portal

Configuring a highly available portal—Portal for ArcGIS | ArcGIS for Server

The URL used by external users when accessing the ArcGIS Server site http://reverseproxy.domain.com/myorg.

I want also requests from ArcGIS Server are sent to the portal in a highly available fashion. ( We will be having two traffic one from users and other internal between ArcGIS server and Portal for ArcGIS)

Now please suggest please note we have enterprise custom application

- While Federating which URL should we use after “Click Add Server button” needs below information

Services URL:

Administration URL:

-All communications between Portal and ArcGIS server will be through Load balancer

-Do we need all enterprise users to login first into the portal then they can access the custom application

If needed I can send you my design diagram also privately

PF1

Hi Shafi,

Our agency is striving to use 'web-tier' with IWA for a few reasons:

Provide a Single-Sign-On experience. Even though some of our ArcGIS Server sites are 'public', many of our users access those on hardware controlled by our organization and are trusted by the domain controllers. Users are not required to separately login while accessing protected resources, publishing services, or administering the site.
I work for a government agency and encryption is supposed to be completed with a FIPS 140-2 compliant algorithm. Now I cannot 100% say that Microsoft Negotiate (which uses Kerberos or NTLM) is FIPS 140-2 compliant, but we are using that with many of our enterprise systems and have successfully acquired an 'Authority to Operate'. I know that the Esri 'Token' based authentication is not certified as FIPS 140-2 compliant and our IT security professionals are not interested in accepting the risk a proprietary authentication scheme.
We have found some significant vulnerabilities with tokens (which I wont detail here).

We still use tokens where necessary (there have been a few Esri products that do not work well with web-tier). I would expect your use of tokens would be just fine for your efforts.

---

For the Service URL it would be the http://reverseproxy.domain.com/myorg (assuming myorg is the 'instance' like arcgis)

---

PF1

Updating an old thread...

we did finally work out python authentication access to agol/portal that is federated to our corporate saml service... the Code repo is on github in case anyone is interested to leverage or reusing for their business needs

GitHub - DOI-BLM/requests-arcgis-auth: Authentication handler for using Esri ArcGIS for Server and Portal (ArcGIS Online…

ThomasColson

Hi Patrick, if I'm reading your examples in the REPO correctly, this module will allow one to implement Requests libraries against an AGOL REST service by inheriting the authentication provided by "My smart card is in the keyboard"? I'm breaking this down to the 3rd grade reading level, your code is....stunning......

PF1

Hi Thomas,

Close... but it does not actually interact with the smart-card plugged in the host machine. Instead, it will inherit the logged in user of the machine.

our SAML service is setup to allow Microsoft Integrated Windows Authentication (IWA) which uses the Microsoft Negotiate security provider. The negotiate security provider implements Kerberos and/or NTLM authentication. For the python authentication handlers... it was coded to use Kerberos. If the user account, machine, and server are all 'trusted' in the back-end domain then we can achieve single-sign-on.

Our users are required to login to their machines with their smart-card credentials... so we are able to inherit the logged in user identity with this approach. Unfortunately this is not going to work when our users are not connected to our internal network (SSO is only available when coming from an internal IP address), but can be leveraged outside of the Esri desktop products.

so my attempt at a 3rd grade statement on how it works:

The SAML service knows who you are because you have a trusted account and are on a trusted machine.

I did implement the auth handler so that a developer could theoretically provide their own authentication handler to deal with the SAML service based in their unique organizational implementation, however it defaults to Kerberos with OPTIONAL mutual authentication (a developer would pass in an authentication handler to the optional 'saml_auth' instance constructor parameter).

Clear as mud?

Thanks for the kudos, this was a fun one to write because we have struggled with this for a few years now.

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.