Getting 302 and 401 when using API

The API runs on a different port (17778) than the website (usually 80 or 443) and handles authentication differently. It looks like you are using the correct API port in Postman/Insomnia but (incorrectly) the website port number in your ITAM tool.

Hi tdanner...

I'm literally using the same url that I've tested in Postman/Insomnia... Thus same port number

You can see from the response headers that it's redirecting you to the Login.aspx page with a ReturnUrl.  It looks like the authentication approach you're using isn't working.  See https://github.com/solarwinds/OrionSDK/wiki/Connecting-to-SWIS and https://github.com/solarwinds/OrionSDK/wiki/REST for more details.

Yup, indeed it has something to do with the authentication but only with the port 17778 string... 

As I mentioned above, I'm using basic authorization. Funny thing is that when I use other string such as query get

(

GET <ourwebsitename>:17778/.../Query

)

or query post 

) 

POST <ourwebsitename>:17778/.../Query

)

it doesn't go either ... But when I've tested the normal url localhost/orion/login.aspx? with the basic authorization, it completes successfully; 200 OK

So somewhere somehow the authentication doesn't reach successfully , as tdanner mentioned "80 and 443 handles authentication differently"

The URL is using TLS, and I have to assume that the certificate bound to port 17778 does not have 'localhost' listed as a SAN (subject alternate name). Unless you're already ignoring certificate validation errors in your connection setting, this could be the problem. I've also had issues in the past with accessing secure IIS sites via the 'localhost' name. The 302 redirect may be a result of localhost being redirected to your Orion URL, or as Dan pointed out, may be related to the way it handles logins on other ports.

Either way, try changing the URL to be the FQDN of your Orion server.

Hi .. .sry the url that i'm using is :17778 , I've changed that in the post to prevent confusion 

We are using a valid certificate and it is configured in our loadbalancer with the 443 and the 17778 port... if we either test in example the server (public) IP or FQDN, we will get a java.net.unknownhostexception error or javax.net.ssl.SSLPeerUniverifiedException error, seeing that it is only allowed for a specific name the . We also allowed the inbound IP address in our firewall for that to work... so the only thing that is stopping this is the orion redirection 302 

So you're getting errors, even when using the FQDN instead of 'localhost'? 

(Sidebar: the site itself, on ports 80 and 443, would use either forms-based authentication, integrated Windows authentication, or SAML SSO depending on your configuration. You're using bearer authentication for the API in your screenshot. This would not go through any of the "normal" logon process on ports 80/443, and would not go through logon.aspx.)

The javax.net.ssl.sslpeerunverifiedexception error tells you that something went wrong with the SSL handshake process, but doesn't say what. To get more detailed information, you need to enable the SSL handshake debug by adding theJava VM parameter "-Djavax.net.debug=ssl:handshake".

It could be that your "client" machine that is making the request is using a different version of TLS than what your Orion server offers. The best approach here would be to make sure that both machines have TLS 1.2 enabled for client and server protocols.

Since you're getting an SSL error from Java, you will also want to make sure that the identify of the certificate authority that issued your Orion certificate is included in the system's Java keystore. You might find this keystore in the path 'C:\Program Files (x86)\Java\jre1.8.0_291\lib\security' or elsewhere, depending on where Java is installed on your API client machine. Doing this may require some reading and an extra cup of coffee, but if I recall correctly, the process  involves running a command that looks basically like this, but using your own values: keytool -import -trustcacerts -alias root -file Thawte.crt -keystore keystore.jks.