Can different auth methods result in different access levels? - rest

I'm troubleshooting legacy REST application used by my company (the person responsible for it's implementation is no longer with the firm, and sourcecode is being looked for) and encountered a weird issue, namely providing no auth-data results in 401 (as it should), sending username+password or token results in 403, yet opening url in chrome on my laptop (where I'm logged in to central system) gets the response I expected (file gets downloaded).
Note that all services are supposed to be linked with central AUTHserver for convinience, so my current hypothesis is that different access rights are given depending on auth method used. Is that possible? Is it proper?
I'm not sure how any of this is relevant but:
providing no auth method returns response indicating auth-method as 'negotiate'
providing one of 'standard' auth methods returns 403
using a library that supposedly implements 'negotiate' method to Python's requests (requests-negotiate) returns errors
using PowerShell $client = System.Net.WebClient; $client.Credentials = Get-Credential; client.DownloadFile(url, path) works as intended (file get's downloaded)
I want to be able to download these files from remote server (running linux, so no PowerShell) and not having to download them to my local machine and upload them to my remote workspace.
Any help/suggestions are greatly appreciated.

Apparently the service uses Windows "integrated authentication", ie. NTLM or Kerberos.
It's not straightforward to get that working on Linux, but not impossible either. You will have to join the client to the domain and get a Kerberos ticket to authenticate, which is somewhat off-topic here. Look at SPNEGO on Linux, and this question for example has some hints.

Related

Generate simple successful HTTP Negotiate/NTLM process in C#/Powershell/Python/High-Level Lang

I've looked over the SSPI documentation, however can find relatively little in the way of sample or working code that implements the library interfaces required in C++.
My goal: There have been numerous situations where NTLM authentication has failed. I would like to be able to isolate the SSPI negotiation process as a stand-alone script to verify how the browser should behave.
As far as I can understand, I should be able to generate a simple Negotiation process with Windows Auth endpoint HTTP server X which succeeds regardless of whether Kerberos or NTLM functions.
Is this a question of trial and error with very old MSFT documentation, or is there some simple port of the SSPI API that I'm missing? I'd prefer to avoid C++ if possible.
Edit: So far, I've found this: https://github.com/antiduh/nsspi
. Might be my best bet unless there's something else out there. Some of the Moz devs refer to sample code that no longer exists: https://bugzilla.mozilla.org/show_bug.cgi?id=159015

Connecting to Snowflake from Python using SSO and browser based sign-in

I'm trying to connect to Snowflake using SSO. I am running the following script (from here):
import snowflake.connector
ctx = snowflake.connector.connect(
user='<username>',
account='<accountname>',
authenticator='externalbrowser'
)
cs = ctx.cursor()
try:
cs.execute("SELECT current_version()")
one = cs.fetchone()
print(one[0])
finally:
cs.close()
The only change I have made is passing the authenticator='externalbrowser' argument (see this) to the connect method instead of password. (user and account cannot be left blank so I'm just putting in dummy strings).
After running the script it displays the following message but a browser tab never appears:
Initiating login request with your identity provider. A browser window should have opened for you to complete the login. If you can't see it, check existing browser windows, or your OS settings. Press CTRL+C to abort and try again...
Not sure if this is relevant, but if I leave it for a few minutes, the script ends with the following error:
snowflake.connector.network.RetryRequest: HTTP 403: Forbidden
I have seen similar questions, but not an answer that would resolve the issue yet.
That <username> likely should be an email address. See https://community.snowflake.com or https://docs.snowflake.com/en/user-guide/admin-security-fed-auth-use.html#setting-up-browser-based-sso
With browser-based SSO, the Snowflake-provided client (for example, the Snowflake JDBC driver) needs to be able to open the user’s web browser. For this reason, the Snowflake-provided client and the client application that uses it need to be installed on the user’s machine. Browser-based SSO does not work if the Snowflake-provided client is used by code that runs on a server.
I assume you have provided the correct user name and password. Now if you are still getting this error, make sure you access the snowflake account using the default browser (which the python program is accessing) and keep your SSO session active.
Now run your python program and it must work.
there is nothing much required and your code parameters looks good
authenticator='externalbrowser'

IdentityServer4 & Windows Authentication

I've been chasing this problem around for a while now and I can't get to the bottom of it. I've read the other solutions on here (https://identityserver4.readthedocs.io and https://github.com/IdentityServer/IdentityServer4.Quickstart.UI) and it's still not working, so I've tried to reduce this down to the absolute basics. This is not the actual problem I am facing, but produces the very same outcome. i.e. I can't get Windows Authentication to work.
I clone https://github.com/IdentityServer/IdentityServer4.Samples
I amend Quickstarts/7_JavaScriptClient/src/QuickstartIdentityServer/Quickstart/Account/AccountController.cs so that WindowsAuthenticationEnabled is true
I then goto http://localhost:5000/account/login and attempt to use the Windows external provider and I get 401.
The only difference with this simple sample here, and what I see on my actual system is that I'm getting challenged for credentials on my real site.
Debugging the code I never see if(HttpContext.User is WindowsPrincipal) succeeding, because it's always a ClaimsPrincipal.
Can someone explain to me what I'm doing wrong?
Do you have windows authentication enabled on your IIS site? This needs to be enabled for your WindowsPrincipal to be assigned. Note that windows authentication only works when running behind IIS or IIS Express.

Why are my REST methods not even reachable from Postman after moving the app with the REST methods to another machine?

With my app running locally (in Visual Studio), I can hit a REST method within it from Postman using either of these URLs:
http://shannon2.nrbq.ad:21609/api/inventory/sendXML/duckbill/platypus/poisonToe.xml
http://localhost:21609/api/inventory/sendXML/duckbill/platypus/poisonToe.xml
So localhost and the machine name both work.
But since I wasn't able to reach the method when calling it from a handheld device connected to my PC, I thought moving the server (REST) app to another machine on the network would clear up that problem.
However, not only can I not reach the REST method from the handheld, I can't even reach it from Postman! I get a "Could not get any response" response in Postman using any of the following URLs; I've tried, I think, every possible permutation:
https://martienda.nrbq.ad/api/inventory/sendXML/duckbill/platypus/test.xml
https://martienda.nrbq.ad:21609/api/inventory/sendXML/duckbill/platypus/test.xml
https://martienda.nrbq.ad/ccr.api/api/inventory/sendXML/duckbill/platypus/test.xml
https://martienda.nrbq.ad:21609/ccr.api/api/inventory/sendXML/duckbill/platypus/test.xml
https://199.96.39.231/api/inventory/sendXML/duckbill/platypus/test.xml
https:/199.96.39.231:21609/api/inventory/sendXML/duckbill/platypus/test.xml
https://199.96.39.231/ccr.api/api/inventory/sendXML/duckbill/platypus/test.xml
https:/199.96.39.231:21609/ccr.api/api/inventory/sendXML/duckbill/platypus/test.xml
...and none of them work (they all respond with the utterly demoralizing "Could not get any response"). What gives? What takes? Why all the hissing snakes? (apologies to Wm. Blake)
Note: If I use "http" instead of "https", I get a "404 - File not Found" error when using the IP Address (but still get "Could not get any response" when using the machine name).
Note: the REST app I can hit when the REST app is run locally is in CCR.API.Controllers and is decorated thus:
[Route("api/inventory/sendxml/{userId}/{pwd}/{filename}")]
Why has the server gone on strike?
Looking at URLs it seems you are hosting your application in either Visual Studio development web server or IIS express. (not necessarily true though). If its either dev server or IIS express then
With VS Dev server you will not be able to access urls/app from other machine but where it is hosted. See this link
If you are using IIS Express then you need to enable remote access. See this link
If you are hosting it in IIS then check firewall settings.

PHP Slow to process soap request via browser but fine on the command line

I am trying to connect to an external SOAP service using PHP and have written a small php test script that just connects to the service and performs a simple request to check everything is working.
This all works correctly but when I run via a browser request, it is very slow taking somewhere in the region of 40s to establish the initial connection. When I do the same request using the exact same script on the command line, it goes through straight away.
Does anyone have any ideas as to why this might be?
Cheers
PHP caches the wsdl in /tmp. If you run from the command line first, the cache file will be owned by whatever user you're running the script as, and apache won't be able to read the cache. The wsdl will have to be downloaded and parsed every time which will be slow.
Check the permissions of /tmp/wsdl*.
Maybe external SOAP service trying to check your IP, and your server has ICMP allowed, when your local network - not.
Anyway, this question might be answered more clearly by administrator of external SOAP service :)
Is there a difference between the php.inis that are being used?
On a standard ubuntu server installation:
diff /etc/php5/apache2/php.ini /etc/php5/cli/php.ini
//edit:
Another difference might be in the include paths. Had this trouble myself on a local test server, it didn't actually use the soap class that was included (it didn't include anything, because the search paths weren't valid), but it included the built-in soap_client class.