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!
