how to add secure service to portal and save credentials through REST API

[ChenLiang]

I am using Portal REST API to add a bunch of secure map services to Portal (10.4.1). Right after those services added, their portal links works fine. After a while, clicking the same link would get an error page saying something like portal can't work on this content item (502 Bad Gateway). When I manually enter the credential on the Edit page, the same link would work again. And then the error occurred again. 

My guess is Portal doesn't seem able to save the specified credential with the new items so the link failed when a token expires. In the REST API reference, there is no specific parameter to get Portal to save or not to save credential. 

Help appreciated! 

[JonathanQuinn]

Do you get the option to save the credentials with the item?  It should be a radio button:

[ChenLiang]

I am asking how to do with REST API not on the Web UI. 

[JeffSmith]

When adding the item through the Portal Rest api, are you including the 'serviceUsername' and 'servicePassword' parameters?  These are only available for map, feature, and image services, but that is what Portal uses to generate a new token for the services as needed.

If those parameters are already being included, I'd make sure Portal is able to successfully reach the token url for those services.  The easiest way to check this to try to add one of the secured services through the Portal web application.  If you login to Portal, go to My Content, and attempt to add the secured service url as an item, does it allow you to save the credentials?  If not, it indicates Portal cannot reach the token url to generate a token.  This is commonly caused by Portal not trusting the SSL certificate used on the ArcGIS Server.  A copy of the CA certificate would need to be imported into Portal in order for it to trust the SSL certificate.  More info on this can be found here.

[ChenLiang]

Jeff,

yes, my script includes the 'serviceUsername' and 'servicePassword' parameters with the credential supplied by the service provider. 

I also manually added one of the secure map services on web UI as a test. The login was prompted and the map service added successfully. The portal item link did take me the external map service. However, next morning or later that afternoon when I clicked on either of map services (manually added or with my script), the error page appeared (<portal host name> currently unable to handle this request. HTTP ERROR 502). The map service is directly accessible with the supplied credential. Even with the credential saved, for some reason the Portal fails to obtain a new token. 

If I opened the Edit page on ANY of the portal items and entered the username and password and save it, then ALL portal item links (to the secure map services) would work right away. But the error appears again after a while. I haven't figured out exactly when the portal item link stops working. My guess is it goes bad as the token expires. 

[JeffSmith]

When you added the service through the web UI, did you see the radio buttons to store the credentials (like you see in the snapshot that Jonathan Quinn included) or did it just display the username and password text boxes?  That would tell us a lot.  If you just see the username and password text boxes, it means Portal is unable to access the token url directly which makes it impossible to generate a new token as needed.

Another manual way to check this is through this url:

https://yourportal.domain.com/arcgis/sharing/checkUrl.jsp?url=https://securedservice.domain.com/arcg...

You would need to adjust this so the 'yourportal.domain.com' matches your Portal url and the 'securedservice.domain.com' matches the url for the secured service.  If this returns a status code of 200, everything is good and Portal can successfully reach the url.  If it returns anything else, Portal can't reach it and that is why you are getting the 502 error.  

Does the secured service reside on your network or is it accessible externally?

[ChenLiang]

• Yes I did see the radio buttons to store the credentials on the web UI. 
• The checkUrl returns 200. There is one thing I am a little confused with. Why is "secured" false even when both our portal and the external service on HTTPS. 

{   "secured": false,   "httpStatusCode": 200,   "httpStatusMessage": "HTTP/1.1 200 OK",   "httpResponse": "",   "url": "https://geodata-services.drillinginfo.com/arcgis/rest/services/" }

• The secured service resides out of our corp network. completely external.

[JeffSmith]

The 'secured' parameter is not detecting HTTPS security.  It is returning 'secured' false because it does not require credentials to access the REST page.  If you were to put the entire secured service url for the checkUrl.jsp, it would return 'secured' true because you need credentials.

I'm not certain now why your portal is having trouble generating a new token for that secured service as needed.  The 'httpStatusCode' of 200 indicates there are not any network connectivity issues.  At this point I'd recommend setting your portal log level to debug and waiting until you get the 502 bad gateway error again to see if portal logs any other messages that might help indicate why it is failing.

If that still doesn't reveal much, it would be best to contact our Technical Support team and have them take a closer look.  

[ChenLiang]

Found the errors in Portal log about the certificate of the external map service. Its certificate is valid on web browser. The only thing I noticed is a wildcard for their domain. Is that the cause? 

Invalid SSL certificate found. PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

[JeffSmith]

No, the wildcard certificate shouldn't cause any problems.  Based on your earlier post, the secured service is coming from https://geodata-services.drillinginfo.com/arcgis/rest/services/, correct?  If so, I took a closer look at the SSL certificate used by geodata-services.drillinginfo.com and I think the issue you are seeing is because Portal does not trust the intermediate root certificate they are using.  This would be the "DigiCert SHA2 Secure Server CA" certificate.  If you import this intermediate certificate into Portal through portaladmin/security/sslCertificates and restart your Portal service, I think that would solve the problem.