A customer of us has adjusted their security on the webservices.
We normally called an ASMX webservice with no authentication. Now they have put a certificate on the HTTPS and added a Windows user for us to authenticate.
Regardless of what properties I'm setting and how I'm always getting:
"The HTTP request is unauthorized with client authentication scheme 'Anonymous'. The authentication header received from the server was 'Negotiate,NTLM,Basic realm="www.domain.com"'."
If I input the link inside a browser, then the browser asks for the username and password and I'm able to see the WSDL.
But if I remove the ?WSDL then it indicates that I'm not authorized.
Did somebody encountered such behavior and knows how to make sure the service is properly setup?
I have tried a number of possible combinations with adjusting the Transport/Message credentials to other values but it doesn't matter, it still gives me that error.
Related
I have an on-premise hosted WCF service with REST endpoint which is configured for Anonymous authentication only in IIS. I installed and configured Azure App proxy connector on the server. I am able to contact the service fine with Pass-through authentication, but struggling to authenticate from a console app when Azure AD is chosen as security mechanism. I know I could have pass-through in Azure and turn on for example windows authentication in IIS, but this is unfortunately not an option in this case.
Using a browser, I am able to access the application fine, don't even need to enter credentials, our on-premise AD is connected and synchronized with Azure AD.
I followed this walk-through despite it is not regarding application proxy, and reusing parts of code I am able to get the Access Token for my application, but when I run the http request with Authorization header I don't get the result of service operation.
Using Fiddler I can note the following:
I get http 302 (Found). I can see my Authorization header in request, and in response I get a cookie AzureAppProxyAnalyticCookie
That is followed with http 200 to login.microsoftonline.com
Example I provided link for above works fine so it is clear that I am doing something wrong. Why is Authorization header not accepted and why am I being redirected to logon page?
Thanks in advance
This is working for another service, have no idea what was wrong with the first one, but suspecting something with DNS on local server. Won't be spending more time on this, point is that I shouldn't have experienced the redirect at all, although browser handled it and managed to get me authenticated.
I have been looking at using Open ID Connect as a third party authentication provider for a Web API application. The flow is as follows:
Users log in through UIWebView with iPhone application to the provider URL from https://daehwa.azurewebsites.net/api/Account/ExternalLogins?returnUrl=%2F&generateState=true
This redirects to my third party site which supports Open ID Connect authentication.
User logs in through this site and redirects back to my site with a token in the fragment of the URL in the form of #id_token=xxxxx
Looking at the following SO article: asp.net web api 2: how to login with external authentication services?
I then should be able to call /api/Account/UserInfo however this always returns 401 Unauthorized. Setting the Authorization: Bearer token doesn't seem to help either and always return unauthorized even when trying to call /api/Account/RegisterExternal.
Just to give you some more information about what I am trying to do I would like to either create an account or at least make subsequent OAuth calls to retrieve their email address and their display name ideally avoiding requesting this information from the user again. However for now I just want the authentication to actually work!
I would really appreciate any help anyone can provide. I'm new to third party auth and I feel as though I am missing something key. I think that my return url is the issue and my server needs to process this token and issue me with another one but not too sure.
Thanks,
Gerard
Is there a way to configure IIS or mark up my code so that the client (any major modern browser) will always include Kerberos information in the response without having to make any modifications to the client itself?
In this specific server method, I'm using ASP.NET impersonation with delegation enabled in AD and it would seem that from firefox and a few other clients, Kerberos data is not being passed from the client to the server.
My application only has Windows Authentication enabled, but how can I force the requests to pass Kerberos information along?
If it helps, I'm using jquery's ajax to GET or POST my requests to the server.
As long as your server is returning "WWW-Authenticate" headers that indicate it accepts Kerberos authentication ("Negotiate"), the client should automatically supply the necessary credentials. Make sure that Negotiate is listed as a possible provider for Windows Authentication in the Authentication configuration of your application. You'll probably want to disable NTLM in that list.
You can tell if the client is sending Kerberos tickets if you look at the HTTP headers. It should have something like "Authorization: Negotiate YIIN..."; the first few base64 characters of the payload let you distinguish between Kerberos and NTLM.
I am not sure if this is possible, but I am running into an issue where a Web Service call is giving me back a 401 Unauthorized. I have looked at the Fiddler logs and confirmed this, but I am passing in the correct credentials through my app. Is there anyway to get credentials that are being passed to the service by looking at the Fiddler Headers or Auth tabs?
If you click the AUTH tab in Fiddler, it will show you the information about the authentication challenge response.
Note, however, that NTLM and Negotiate don't send the raw password over the network.
Is the target site HTTPS? If so, is Extended Protection enabled?
I created a web service that I want to make more secure by using forms authentication. I added the following code:
[WebMethod(Description = "Login function returns true for success and false for fail.", EnableSession = true)]
public bool Login(string Username, string Password)
{
return User.Validate(Username, Password);
}
My User.Validate function does all the authentication and works fine but I am not sure if it is secure passing the username and password to the web service. Is this any less secure than when a username and password field are submitted through a normal web form without SSL?
Is this any less secure than when a username and password field are submitted through a normal web form without SSL?
That's damnation with faint praise. Submitting a password without SSL really isn't secure.
Anyway, it seems like it might be a good idea to start with the basics. Does that article answer what I think is your actual question ("How should I do this correctly?")?
Your web method is no less secure than a normal web form without SSL. Both are basic POST entries (you could make them GETs, but POST is most likely) that send their payload contents (Username, Password) in clear text.
Just a comment: not certain about your strategy of making your web service more secure by adding an authentication method that returns a simple boolean. Most authentication schemes will require the use of a session or authentication token that must be carried around by the client. In a web browser, this is automatic through cookies and such; it requires active management for most clients consuming a web service.
Depends who you need to trust. Client, Transport and/or Server.
Client needs to know the password to enter, so not a real problem.
Transport can (and should) be encrypted using HTTPS - HTTP is not any good.
Server - do you trust the people running the server? Will users use the same passord on the server as in thier company (giving server owner possible password to try to attack you company account)?
A good sanity check for security of the server is if you are offering a change password page or not. Any web-site that allows the user to change the password, will send the password over the line and it will be available in clear text on the server (can be encrypted on the way). This could be avoided, but I have yet to find a site that does it.
Cheers,
Well, passing password is not secure if SSL is not used. Also, if the service is exposing multiple methods then user has to enter the username and password for every method call or the calling application has to persist this information in some place and might lead to other vulnerabilities.
To avoid all these problems and one of the right way to secure a service is to use something similar to the OAuth protocol. This protocol exchanges the username password for request token and then exchanges this request token for access token. Subsequent calls to the webservice will use the access token and not the username password.