I'm trying to get a SAML token from an ADFS instance. I followed the example found here (http://blogs.msdn.com/b/willpe/archive/2010/10/25/windows-authentication-adfs-and-the-access-control-service.aspx) to configure everything. The ADFS instance is configured by a different party, but setup as found in the article.
At first sight, it all seems to be working ok. But when I go into code and run a sample which should get me a token, I receive a (411) Length Required) response from the server. It doesn't matter much if I switch endpoints, errors stays the same. Seems like the response isn't even getting to the endpoint at all.
The Length Required error seems to have something to do with a missing Content-Length: 0 header line. I checked with Fiddler; it's not there. But the call is generated from within the .NET framework, so there really isn't that much I can do about that.
Any idea why the server might throw this error? Should I try to change the request, or disable the check on the server side? Or an option I haven't thought of perhaps?
Related
I'm trying to implement Negotiate (at least the Kerberos part) in a small web server. I've figured out how to get a client to send me a Kerberos Negotiate Authorization header. I've figured out how to decode that data (ASN.1). I cannot figure out how to turn this into a WindowsIdentity. I can get a general idea of how I might from KerberosReceiverSecurityToken, but I can't find anything like a NegotiateReceiverSecurityToken. I've been digging through lots of DLLs and I can't for the life of me figure out where IIS/.NET processes the Negotiate header.
I presume (if I had my own SspiWrapper) that I would do something with SspiWrapper.AcquireDefaultCredential("Negotiate", CredentialUse.Inbound) to acquire an SSPI context with which I could call AcceptSecurityContext/Negotiate and then use QuerySecurityContextToken to get the token with which I could create a WindowsIdentity.
But KerberosReceiverSecurityToken makes that look like an immensely complicated process. And without any idea of how to do that or what part of the Authorization header payload to put into it, I could probably beat my head against it for a month without getting anywhere.
(Before you ask or answer, I have absolutely no interest in using the built in Negotiate logic. If I could find it, I would learn from it, but I've been trying to get that to work for FAR to long. And I'm done with that.)
Parse the incoming response token
Call Secur32.AcquireCredentialsHandle to get a handle
Call Secur32.AcceptSecurityContext passing the handle and the token
Call Secur32.QuerySecurityContextToken passing the security context
Construct a new WindowsIdentity(hToken) using the output form step 4
If you have any questions about any of these steps, I can elaborate and/or provide some sample code.
I have a WCF REST service hosted in SharePoint that uses SSOM. The client web application sends AJAX requests containing the REQUESTDIGEST in a X-RequestDigest header. I am using the typical SPWeb.ValidateFormDigest() for my POST requests to prevent CSRF vulnerabilities. Works great.
Here's the weird part. Our client uses HP Fortify, and it is reporting that our GET requests are vulnerable to CSRF attacks. My GET requests are indempotent so this seems silly, but I must be compliant.
To get around it, I want to use ValidateFormDigest() in my WCF method for the GET request the same way I do for POST, but it throws this exception:
"Updates are currently disallowed on GET requests. To allow updates on a GET, set the 'AllowUnsafeUpdates' property on SPWeb."
I tried setting AllowUnsafeUpdates, but that just makes the request succeed without validating the digest!
Is there a way to have SPWeb validate the digest within a GET request?
HP Fortify gives recommendations, not edicts. If you think - and can prove - that the warning is spurious, then justifying the pattern should be treated as being compliant. Code analysis tools are not perfect.
I'm using Google Apis, instead of Google Sign In, to connect to Google on my app because I'm developping with Xamarin.
This is the library I'm using : https://github.com/xamarin/google-apis
When I'm logging in, i get this error :
Authentication Error
Unexpected character '<'. At line 1, column 0.
Maybe it's because my AccessTokenUrl is not good, but I've tried many things. I know for a fact that my ClientId, my RedirectUrl and my Secret are okay.
When logging in, Google asks correctly for the good permissions that I want, but after I accept, this is when I receive the error.
I've tried finding the request to see if there was the '<' in it but had no luck accessing it.
Is there a good way to connect to Google with Xamarin using this library or I'm just doing something bad?
Should I just do it nativaly on iOS and Android?
Thanks
I just encountered a similar problem using Xamarin.Auth to hit a custom OAuth service (i.e. not Google). In my case, the accessTokenUrl pointed to an action on a controller that was entirely protected by the [Authorize] attribute. Naturally, the user was required to login before hitting the /oauth/authorize endpoint using a web browser, but the request to /oauth/token to exchange the resulting authorization code for an access token was not inside the same web browser/session. It was trying to get back token data in JSON format but was being redirected to an HTML login screen. Once I changed the token endpoint for anonymous access, things started working (Note: A valid authorization code cannot be obtained without authenticating).
General Recommendations
The error message strongly suggests that the response coming back is HTML (or at least some form of XML). This could be an authentication redirect as it was in my scenario, or possibly some sort of error page. I would first start by setting up a proxy. I used Charles Proxy to uncover some interesting information. You will need to configure SSL on the proxy to see anything except high level information. This will show the exact requests coming out of your app to the OAuth application.
Another technique I used was simulating the requests that the OAuth2Authenticator would be making in a web browser and/or Postman. The first request would be to authorize:
https://your.domain.here/oauth/authorize?client_id=<some_client_id>&redirect_uri=https%3A%2F%2Fyour.domain.here%2F&response_type=code&scope=<some_scope>&state=<some_state>
That endpoint should be protected, so you will likely be redirected to something like this:
https://your.domain.here/Account/Login?returnurl=%2Foauth%2Fauthorize%3Fclient_id%3D<some_client_id>%26redirect_uri%3Dhttp%253A%252F%252Fyour.domain.here%252F%26response_type%3Dcode%26scope%3D<some_scope>%26state%3D<some_state>
After authenticating, the authorize endpoint should redirect to your redirect URI with the authorization code and state included as query string parameters. You will use the code in the next step.
Lastly, using a fresh web browser (i.e. new session), you should hit the token endpoint with your new authorization code and other client information.
https://your.domain.here/oauth/token?client_id=<some_client_id>&client_secret=<some_secret>&grant_type=<your_grant_type>&code=<your_authorization_code>&redirect_uri=https%3A%2F%2Fyour.domain.here%2F
If the response is not JSON data, it should give you an indication about what is failing with Xamarin.
Got the same error.
Solved by using https://accounts.google.com/o/oauth2/token as AccessTokenUrl
I'm getting the error "HTTP Error 414. The request URL is too long." From the following article, I understand that this is due to a very long query string:
http://www.mytecbits.com/microsoft/iis/query-string-too-long
In web.config, I have maxQueryStringLength="2097151". Is this the maximum value?
In order to solve this problem, should I set maxUrl in web.config? If so, what's the maximum value supported?
What should I do to fix this error?
This error is actually thrown from http.sys, not from IIS. The error gets thrown before the request is passed along to IIS in the request-handling pipeline.
To verify this, you can check the Server header value in the HTTP response headers, as per https://stackoverflow.com/a/32022511/12484.
To get https.sys to accept longer request URLs without throwing the HTTP 414 error, in the Windows Registry on the server PC, at Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters, create a DWORD-type value with name MaxFieldLength and value sufficiently large, e.g. 65535.
Reference: Http.sys registry settings for Windows
If you decide to make this change, then obviously it’ll need to be made in all environments (including all production server(s)) -- not just on your local dev PC.
Also, whatever script and/or documentation your team uses to set up new server instances will need to be updated to include this registry setting, so that your team doesn’t forget to apply this setting 18 months from now when setting up a new production server.
Finally, be aware making this change could have adverse security consequences for all applications running on your server, as a large HTTP request submitted by an attacker won’t be rejected early in the pipeline as it would normally.
As an alternative to making this change to bypass the http.sys security, consider changing the request to accept HTTP POST instead of HTTP GET, and put the parameters into the POST request body instead of into a long URL. For more discussion on this, see question Design RESTful GET API with a long list of query parameters.
As described in this answer -> What is the maximum length of a URL in different browsers?
The allowed length of a url depends on a combination of browser and server. Hence it's hard to say exactly how long the url can be. The answer recommends to stay below 2000 char in the url. I do not know why your querystring is so long. Can you shorten it? It's hard to give you any recommendations without knowing more about the solution and your query string.
Generally, Url has its own limits in length and if you set this value you may solve the problem for a while, but bear in mind that for a long url situations, best practice is working with forms. To be specific, it is better to use POST actions instead of Get.
just to complement, if you try with massive parameters, using Request ajax and receive de 414 ERROR. change the dataType property to JSON then submit as POST type.
this resolved my problem.
a few days ago I start to use a SOAP service for Joomla and VirtueMart connected by a client in C#.
I tried out about a fistful functions and it works fine.
Only one function I've trouble with when I try to use it I get an error.
The developer send me a request that work for him (with my server) but I see only few differents that are not important as I think ...
Maybe somebody can help and show me impoartant differents of the requests that may be a reason for trouble?
This is the working request done with Felx (as URL as I can't insert XML:
Working Request
And this is my request that return a server fault:
Not working Request
Has somebody any idea please?
Fiddler also return an violation but I think that does not matter in this case:
Content-Length mismatch: Response Header indicated 8.958 bytes, but server send 8.959 bytes.
Also a hint how to debug may be useful.