I know that I can pass basic Authentication credentials via the URL like this:
http://User1:Password#localhost:1234/test
which should put the User1:Password into the Authorization header of the Request.
But when I try and read the Authorization header it is nothing. I'm doing this in vb.net (when I add the "Basic User1:Password" to my Authentication Header, I can see it coming through in my code).
I'm using HTTP not HTTPS for my testing and I've tried doing this just with a Browser request (IE11) and via ta HTTPWebRequest in vb.net and get the same issue. I had read that most browsers don't allow adding the Basic Authentication to the URL.
Is there something I'm missing here?
Related
Having application with SAML authentication along with Azure AD as IDP. When I hit Login SSO button the following happens:
Hits SAML Redirect URL (/Saml/SAMLLoginRedirect)
Redirects automatically to Ping Federator. Redirected URL is received with the response header of the first request. URL consist some SAMLRequest Token and RelayState value. Final response has Submit Form along with new SAMLRequest token and RelayState.
Hitting IDP (login.microsoftonline.com//saml2 with the SAMLRequest and RelayState from the final response not works as expected.
I have resolved this issue in jmeter. I have just enabled Follow Redirect so jmeter provides the response and cookie. I am extracting the Header value of first the request from URL. It is just because Jmeter has the feature of accumulating redirect sample into the original request.
So I am again hitting Ping Federator with the Token and RelayState received using URL extractor along with final response Cookie.
Further I am able to complete the IDP process successfully.
I am not able to achieve the same using RestAssured. When I disable redirect I am able to get the url from header. Processing the URL from the header value throws 500 error code though I have added the cookie information.
If I enabled redirect I am getting 200 response code along with expected response body and cookie.
But I am unable to proceed to the Ping Federator with the token and relay state received from the response. So I have to hit again the Ping Federator with the previous SAML Token again as I did with jMeter to achieve the proper response.
Problem: Unable to get the header value if I enable the redirect and further processing fails. If I disable the redirect then I am not getting Cookie and expected response when processing the URL from header value. Here all are GET request until the IDP (login.microsoftonline.com)
JMeter's HTTP Cookie Manager automatically extracts cookies from the Set-Cookie response header and sends them with the next request via Cookie request header if domain and path match and the cookie isn't expired.
RestAssured doesn't do this automatically so you will need to extract the cookies from the response and add them to the next request manually.
References:
REST Assured Tutorial 49 – How To Retrieve Single and MultiValue Headers From Response Using Rest Assured
Headers, Cookies and Parameters with REST-assured
Going forward you can just use a sniffer tool like Fiddler or Wireshark to compare requests coming from JMeter and RestAssured, given you send the same request (apart from dynamic parameteres which need to be correlated) you will get the same response
I have created an app (backend and frontend) that is mainly used on a Windows intranet. I'm using Kerberos authentication to do SSO so that anyone logged in to Windows domain is automatically authenticated to the server. To do this I set up Kerberos SPN for server and configured browsers etc and is all working fine in the normal scenario. My problem is that I need to continue if the user is not authenticated (ie connects from outside the Windows domain or does not have their browser configured correctly).
In summary there are two scenarios:
if authenticated OK continue with authorization granted for their ID [currently works]
if not authenticated continue with no (public) authorization [does not work]
In the first case the HTTP requests/responses are:
a. frontend: initial HTTP request
b. backend: no auth found so return 401 unauthorized with WWW-Authenticate:Negotiate header
c. frontend: re-sends request with Authorization header -> decoded to get the login ID
In the 2nd case:
a. frontend: initial HTTP request
b. backend: no auth found so return 401 with WWW-Authenticate:Negotiate (and error text in the body)
c. frontend: browser stops (displaying the body of the response as text to the user)
This is the crux of the problem I need to somehow avoid the browser just completely bombing (as at step c above).
Solutions I have tried:
display a message to the user about how to adjust browser settings to allow SSO to work in the body of the 401 response message. This is pretty ugly looking and does not work for connections from outisde the domain
Tried a 301 redirect in stead of 401 unauthorized response, but the browser does not like this.
Tried a redirect using javascript in the 401 response body, but it is not executed.
Have the backend send 401 but with WWW-Authenticate:Negotiate,Basic. But this display an unneeded login/password dialog and still fails if they don't login.
What I really need is an None option, ie: WWW-Authenticate:Negotiate,None then continue with no auth if the subsequent frontend request indicate "None" was used.
Of course, there isn't a "None" option. :(
It seems that this should be a fairly typical scenario but I have been researching this to no avail for 3 days now. Any advice would be greatly appreciated.
If the browser is connecting from outside the intranet then just continue. That is do not send the 401 response at all (no auth). You should be able to tell from the IP address where they connect from.
Another option is to redirect using JS in a page in the 401 body. As mentioned above I think you need to include Content-type: text/html or Content-type: text/javascript.
I've been doing some HTTP methods and header research recently if we should use GET with basic authorization instead of POST when submitting?
HTTP Methods
The GET method requests a representation of the specified resource. Requests using GET should only retrieve data.
The POST method submits an entity to the specified resource, often causing a change in state or side effects on the server.
As we see here, the POST method normally changes the state of the server. If sending out JWTs/HTTP cookies, we are not modifying the state of the server. Nor are we creating a new resource in the server.
I understand that we should not not send the username and password as a GET parameter but should we use the authorization header instead?
Basic authentication
For "Basic" authentication the credentials are constructed by first combining the username and the password with a colon (aladdin:opensesame), and then by encoding the resulting string in base64 (YWxhZGRpbjpvcGVuc2VzYW1l).
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
The only advantage I see to using POST over GET is that we need no extra code in the HTML/JS on the client side to send headers via the fetch API. To send headers, we would need an onsubmit and then check if status code is 200. If 200, we will need to redirect to the page after the login screen. Then again, if using the fetch API, this means the server does not need to send a new HTML page to the client all the time either.
Should we use GET with basic auth or POST when logging in since we don't create a resource/modify the server state?
Would this change if say we enable 2FA since we would need to generate a code for that user?
Doing basic authentication in the browser and using GET is not that recommended.
To do your own login form it is better to always do it using HTTPS and POST. Do post the username/password in the body of the request and secure it with proper CSRF protection.
If you want to level up, you can always look at the OpenIDConnect approach, but that is more advanced depending on your needs.
Also, a good approach is to explore how existing site implement a login form and look at the HTTP(s) traffic in a tool like Fiddler.
I am trying to setup basic auth on my mvc.net web application. I configured my controller using this example: asp mvc 3 ActionFilter for basic authentication
I set a breakpoint where it checks for the Authorization Header, however the header is not present in the HttpRequest. I am accessing the site like this:
http://user1:pass1#localhost/{AppName}/Client/Authorize
If I remove the [BasicAuthorization] attribute from my controller, I am able to access the page.
I am debugging this using IIS 7.0 on a Windows 7 machine.
I think it might have something to do with default authorization settings in IIS. When I throw a HttpUnauthorizedResult() exception, a username/password box pops up in Chrome... I'm not sure how to tell IIS to use my custom code to authenticate the user.
This application won't be accessible by a human user, so the username/password needs to be passed in in the URL like shown above.
I had also found this post: No browser is sending Authorization info in header. I tried sending the request twice after IIS sends the UnauthorizedRequest to the browser, but that's when the username/password dialog pops up. I'm also not sure how to test using that Curl command... Is that through CMD?
I found this post here: SimpleMembership in MVC4 app + WebApi using basic HTTP auth
I was able to refer to the test page used on this tutorial: http://kevin-junghans.blogspot.ca/2013/02/mixing-forms-authentication-basic.html to setup a simple testing page to test that basic authentication was working properly.
I'm not entirely sure on the reason, but I believe that the browser doesn't automatically add an authentication header to the HttpRequest when you try sending the credentials like so:
http://user1:pass1#localhost/{AppName}/Client/Authorize
It must have something to do with the browser requiring a 401 response from the server first before sending the authentication header. I just couldn't figure out how to do it. If anyone knows how to configure IIS/browser properly so you can easily test basic authentication using the above URL format, please let me know.
normally browser stores and adds authentication header automaticly after successfull authentication.
I have a XMLHttpRequest and added the authentication header for basic auth. No problem at all.
Then I try to send a second request to the same url that is basic http protected without adding manually the http request header to this request. Poorly it seems that the browser is not storing the authentication provided in request 1. My goal is to add the authentication handler transparently to every request that follows the first one (like a native browser do).
Any idea? Thanks.
Browser only storing authetication requested from user. So, if you send 1st request w/o authentication fields, browser will prompt user for auth this time, remember credentials and use it for next requests transparently.