I'm very new to ASP.NET and I've been struggling trying to get the username of the client sending requests to a web service script on the server side.
After searching online I found two properties that supposedly gives the server page access to the client username;
User.Identity.Name
and then I got another piece of code from an ex-senior colleague who left before figuring this problem out, his function used UserPrincipal.Current.DisplayName
and for both of these I'm getting a blank string.
I've searched for what my problem could be and I'm suspecting it's because I don't authenticate the user on the server side somehow.
I just accessed those two properties/variables directly (UserPrincipal.Current.DisplayName and User.Identity.Name)
can anyone help shed some light on this issue please? I haven't a clue what I'm doing wrong/ not doing.
Your suspicions are correct; you have to explicitly authenticate the user via a built-in .NET mechanism such as Forms Authentication or Windows Authentication for User.Identity to be populated by the framework.
You didn't specify from where the requests are coming (web, windows app, windows service, etc), but this article provides nice overview of getting Forms Authentication set up with asmx.
Related
C# ASP.NET web page that has requirement to MFA to Azure SQL Database.
I have working in development environment.
When I deploy to web server error is received of...
"Showing a modal dial box or form when the application is not running."
I understand why it doesn't work, but how do I get a redirect to work against Azure SQL Database to get a token for the SQL Connection ?
Best answer was:
Acquire AAD token using ASP.Net web forms
What am I missing to make MFA to Azure SQL work in asp.net?
result = await authContext.AcquireTokenAsync(
parameters.Resource, // "https://database.windows.net/"
_clientId,
_redirectUri,
new AD.PlatformParameters(AD.PromptBehavior.Auto),
new AD.UserIdentifier(
parameters.UserId,
AD.UserIdentifierType.RequiredDisplayableId));
Follow up, I have the basics of this worked out.
Enable HTTPS (this was an on-prem, internal use web app, was not https, it is now).
Ensure .net 4.7.2
Ensure URI()'s match azure application registration (was missing this)
The redirect and URI back are causing me to change the design and flow of the web page, but that's a side effect of the MFA requirement.
Will post some follow up code example once i have it working the way it should, but a quick test has it working, much easier in windows application as opposed to a web app.
We have an ASP.NET Core application which has the default authentication system and is hosted on Azure.
Recently, we created a new AppService and routed the users to that service while maintaining connection to the same database.
However, when users use the new server, we get continuous crashes with the following error:
The key {xxx-xxx-xxx-xxx} was not found in the key ring.
of type
System.Security.Cryptography.CryptographicException
and method
Microsoft.AspNetCore.Antiforgery.Internal.DefaultAntiforgeryTokenSerializer.Deserialize(String
serializedToken)
Our understanding is that the server is trying to decrypt the token but since it was received from a different server, our server just crashes.
We would so much appreciate if you can suggest a way to solve this issue temporarily until we change the DataProtection provider.
We want a way that wouldn't let our server crash.
Thank you so much
Update: I'm surprised now that this error happens in: POST Account/Login and POST Account/Register while these methods do not require authorization, however these methods are decorated with:
[ValidateAntiForgeryToken]
Both Get Account/Login and Post Account/Login happen on the same server.
Make sure you have machine key same across the farm. You should set it at the application level, meaning, different apps have different keys but the same app has the same key on all server of the farm.
The machine mey is responsible for encrypting some internals of selected features of the engine, including the antiforgery tokens. A different key on different servers causes the exact issue you describe.
https://blogs.msdn.microsoft.com/amb/2012/07/31/easiest-way-to-generate-machinekey/
https://msdn.microsoft.com/en-us/library/w8h3skw9(v=vs.100).aspx
In my case.
This error happened as I was using two or more instances for the identity server.
So,
Login goes fine but checking the token cause errors.
As the login was done by an instance and checking was done using other instance.
The easiest way to solve this is to make sure that your identity server or API is using only one instance.
Here's what I want to do (which I've done before but I'm clearly doing something that is not obvious to me...):
ASP .NET 3.5 Intranet Application
Want to have Windows Authentication against AD setup on the website
When the user requests the page, fetch the user's username with the following code:
System.Web.HttpContext.Current.User.Identity.Name
I have IIS 7.5 and have setup the web application, disabled anonymous access and enabled Windows Authentication.
When the page is requested, the prompt for username / password is entered.
I entered the details but the prompt keeps coming up and eventually comes back with 401.
What on earth have I missed?
It seems to be a broblem with the Authorization (dond confuse with Authentication they completely diffrent), becuse the Authentication has been passed successfully after you've written the right user name and password, please try to set the appropriate privilegs to the user you try to login with, then try again. You can do that by set ting the right roles in the Authorization tab in the Security/Application tool of ASP.NET or by defining it manually by creating the right class... You'd better also chack the IIS policy if you deal with production code on IIS. If this is not working please post the Authentication code you've written.
Figured out what was wrong. Was nothing to do with Authorization at all but I stupidly had written code a few days back throwing a 401 error when a certain condition was not met. Removing that proved that the setup done worked perfectly :)
I have an ASP.NET web service that I can access via a windows program but now I want to secure the web service. I can secure the web service using forms authentication. How do you access the secured web service from a windows forms application?
Although this is not the right approach, tt is theoretically possible to use forms authentication in the manner you describe. This could be accomplished by either:
Using a WebRequest to send your requests in raw form to the web service. This will involve inspecting the response, extracting the relevant forms-authentication fields, and sending a response back which logs the user in. This will generate a cookie which you must send along with each subsequent response to the service
Generate the FormsAuhentication authentication cookie yourself. This is complex as it involves synchronising the machine key on the calling application, and artificially manipulating the headers being sent to the machine hosting the service.
Display the forms-authentication form for the user to log in to at the beginning of a session requiring interaction with the web-service. You can then harvest the generated cookie and present it to the service in HTTP headers as in option (2).
As you can see, these methods are highly complex, and are fundamentally a hack to use forms-authentication where it was never intended.
Microsoft intended us to use either Windows authentication, or SSL certs to secure access to ASP.NET web services. See HTTP Security and ASP.NET Web Services on MSDN.
If you are able to use WCF, then a few more options present themselves, including the ability to build a custom authentication mechanism into the SOAP, with some support from WCF.
For the most part, securing web services is one of the trickiest parts of the job. Many live solutions which I have seen are compromises such as the ones above.
It seems the answer is no. Forms authentication is a cookie-based mechanism, and your WinForms app won't be able to hold and relay the cookies (without some serious workarounds, if at all).
A potential workaround that I wrote up when researching your question attempted to use a NetworkCredential object, but that didn't work. Also tried was the ClientCredentials in .NET 4.0.
var ss = new MySecureWebService.MyServiceSoapClient();
ss.ClientCredentials.UserName.UserName = "abc";
ss.ClientCredentials.UserName.Password = "123";
string asmxReturn = ss.HelloWorld(); //exception returned here
The console app was still presented with the login html page when calling the webmethod.
Other Suggestions
If you have the source to your web service, extract its logic out into an assembly of its own. Reference that assembly in your WinForms app, and it's just as if you're calling the web service.
I understand that your goal is to reuse the app that's deployed, but the next best thing would be to use the same logic/implementation via .dll reference.
This might help: http://dotnetslackers.com/articles/aspnet/Securing-ASP-Net-Web-Services-with-Forms-Authentication.aspx.
I'm looking for a way to pass some sort of credentials or Authorization token from a VB.Net Client to an ASP.Net web application that allows the Client to auto-login to our Forms-Authenticated website. If a user is logged into a local application, I want them to be able to view some web pages without having to login to the website as well. The credentials are not the same between the apps, but I would just like to pass some sort of encrypted token or key to the web page so I know they are coming from the desktop application. Is this possible without requiring a username and password login?
I also need to make sure this URL that is used cannot be simply copied and used from another location, so I'll need to include some sort of information in the encrypted value to know where it's coming from.
I know how to login the user with Forms Authentication and all that, just need to figure out the best way to secure this. Thanks!
OAuth is commonly used to allow desktop applications to access a user's private data on a web site. Since you're using .NET, I suggest you check out DotNetOpenAuth which includes sample OAuth web sites and client applications. It allows for this secure token to be passed that can tell your web site that the desktop app is the one making the requests and (usually) whose data is being accessed.
The best part about the OAuth solution is your desktop app never has to ask for the user's credentials. No credentials are in the URL. And if the desktop application is ever compromised (perhaps by the computer being stolen), the web site can kill the secure token the desktop app was using to cut off access without requiring the user to change their password.
You might want to look into issuing client-side certificates for these applications. Basically, you generate a certificate that you install with the client application and then on the server side, you check the ClientCertificate property of the HttpRequest instance exposed by the Request property on the current context.
Note that what you are doing is really a very bad idea, in that applications should never be assigned identity, only users. To that end, you should be authenticating each and every user that is using your app, not considering the application to be the identity. It's commonly considered a bad practice to do such a thing.
You can share credentials between the applications using ASP.NET Client Application Services.
Here are some resources:
Client Application Services
Client Application Services with Visual Studio 2008
Is your desktop app running on machines that are in the same domain as your web server (i.e. all in the same company)? If so, Integrated Windows Authentication is your easiest solution.
I think its best idea to use a web browser control inside the desktop application .
Then use the WebBrowser1.Document most probably
WebBrowser1.Document.Cookie
get if the user is singed in.
I also need to make sure this URL that
is used cannot be simply copied and
used from another location, so I'll
need to include some sort of
information in the encrypted value to
know where it's coming from.
If you store the encrypted value in a cookie or as a field in a form (POST request), then the credential is no longer in the URL and so it can't be easily copied (note that I said "easily").