First off--thanks for having a look.
MY QUESTION
In a .NET web app, is using Windows Authentication for a extra-net on a WAN consisting of various users, companies, user-agents, etc a bad idea?
BACKGROUND
I am lead dev on a fast track (very fast) web application for an extra-net that will allow the client's vendors, suppliers, partners, etc to log on and push and pull certain assets such as image files, videos, flash files, etc.
PLATFORM/TECHNOLOGY
Asp.Net 4.0, C#, MVC3
PROBLEM (Maybe)
The client's IT department has requested that the app use Windows Authentication to authenticate users. One of the reasons for this (they say) is that the assets that will be pushed/pulled by users reside on a third-party server (Signiant) which already uses credentials form their active directory to authenticate users.
MY VIEW
Windows Authentication is going to cause a bunch of headaches. Viewed as a stack, this app will sit on top of the third-party server. So if we use Forms authentication, we can just populate a data table with windows credentials for each user and pass those to Signiant's servers with our requests (you have to do this anyway). If possible, we can even make an LDAP call for the creds on the fly and then pass those to Signiant's servers.
It just seems to me that simple functionality such as "lost password" would be come extremely difficult if we are doing the Windows Auth thing. But, full disclosure, I have never built an Asp.Net app using Windows Authentication so what do I know??
Thanks!
Matt
UPDATE 8/12/11
I still don't have an answer as to whether you should do this, but the client is adamant that it must be this way. The app is supposed to be turned over in a month so I will come back and let any followers of this topic know my findings.
ASP.NET has built in support for doing AD Authentication using Forms Authentication, including password recovery.
See: http://msdn.microsoft.com/en-us/library/ff650308.aspx
Related
For multiple applications, I want to build a centralized account solution. The core consists of some ASP.NET Core web applications. But I also want to include third-party applications like WordPress, GitLab, or a XAMPP/HipChat server. My goal: The user creates ONE account, which can be used in all of those applications. So an LDAP server seems the best way for this since many applications have support for this protocol. This also gives flexibility for other applications, which may be added later.
The problem here is, that the users should be able to authenticate using common social sites - Especially Facebook. It's state of the art and would increase the conversation rate, cause it's easier for the users.
Is it possible to integrate social login provider like Facebook to LDAP servers like ApacheDS?
As I see the topic, Facebook generates some kind of authentication token, which can be used from the application to verify the identity of the user. In my custom web apps, this is no problem. But for e.g. a XAMPP server, this seems not to work: LDAP requires username/password. But I don't have this, since there is only a Facebook token available. The LDAP server could store this in an attribute. However, this would require to check this token instead of a password on an LDAP bind.
On the other side, when I drop the LDAP server and use some framework like ASP.NET Core identity instead, it's not a big deal. The problem here: I'm not able to use this login for third-party applications. This would require the users to have an additional account for e.g. XAMPP, WordPress, and so on, which results in big chaos and is thereby not suitable for me.
By dropping social support, it works. This seems also not to be a good idea since those logins are state of the art and I'm targeting younger users, which expect an SSO solution with Facebook or similar providers.
Facebook (and other social login sites) use a protocol named OAuth to authenticate. Probably the easiest solution would be to implement an OAuth server yourself that uses your LDAP as backend and then add that beneath the Facebook login as the second way of login.
That will not add users logging in via Facebook to your LDAP but as you usually only get an OAuth token back for login (not necessarily a username) which needs to be verified against Facebook (or whoever provided that token) it doesn't work to use it as "password replacement".
I have a web application where forms authentication is used. The user names are the same that the ones used by the users in their computers, so they want the web app to be able to detect that user name so the app can log it the user automatically.
How can it be done? I mean, if I set the authentication mode to "Form" do I still get those credentials from IIS?
I know this can be done in several better ways than this, but I am interested in this particular way. As it is a small web app in an intranet with a few users doesn't worth it a big architectural change. If it's possible, happy days, otherwise it will have to wait.
Cheers.
That cannot be done with Forms Authentication. Without prompting the client for credentials, there is no way to retrieve that information from the client's machine.
Windows auth cannot coexists with Forms auth, but it can coexists with Anonymous auth.
More info here: Windows authentication is not challenging browsers out of the domain
Its not an original question. There is already a batch of articles describing this problem and solution for it. They all are dated back to times of .Net Framework 1.1 and IIS 6.0 and are not really helping with all the membership and role providers stuff we have nowadays. But lets get closer to the problem.
The problem is short.
You have an intranet site using Windows authentication and it works just fine. All you want is to give access to this site to users from their homes and to users who don`t have Windows based workstation.
Duplicate the whole site would be cumbersome because all the application except Login part would work well just if appropriate information would be saved in cookie on Login step.
You are welcome with any suggestions.
You don't say if internal users are authenticated or not, so, as it's an intranet I'm going to assume they are, via integrated authentication.
The simplest way would be to leave it as is, and turn on digest authentication if you are in a domain environment in addition to integrated authentication - this would prompt users not on the intranet with a username/password popup and they can login with their domain credentials.
If you don't have a domain - then how is it an intranet site? How are users authenticated? If you're in a workgroup scenario, where users have login details on their own box, and login details on the intranet server (in which case moving to AD would be better all round - no need to keep the passwords in sync, or deactivate user accounts in multiple places when people leave) then mixing Integrated authentication with Basic Authentication would do the same thing - however if you're going to use Basic Authentication then you will need to add an SSL certificate to the site to stop usernames and passswords being sniffed - Basic Authentication sends them in plain text.
Well, what you could consider is if you can use Active Directory, there is a provider to use the AD store for security, that would work for both.
HTH.
I have a fairly complex business application written in ASP.NET that is deployed on a hosted server. The site uses Forms Authentication, and there are about a dozen different roles defined. Employees and customers are both users of the application.
Now I have the requirement to develop a Windows Mobile client for the application that allows a very specialized set of tasks to be performed from a device, as opposed to a browser on a laptop. The client wants to increase productivity with this measure. Only employees will use this application.
I feel that it would make sense to re-use the security infrastructure that is already in place. The client does not need offline capability.
My thought is to deploy a set of web services to a folder of the existing site that only the new role "web service" has access to, and to use Forms Authentication (from a Windows Mobile 5/.Net 3.5 client).
I did see this question and I am aware of the limitations that Forms Authentication poses. Since security is not my primary motivator (I use SSL and can restrict access by IP address), but rather using existing user accounts and roles, my decision tree is somewhat different as well.
Can I do this, is it a good idea, and are there any code examples/references that you can point me to?
I ended up with a combination of things. First, forms authentication does not really work in this scenario, because of the redirects that you get when a users is not logged in or the credentials are incorrect.
Because I want to use the user accounts from the web app, I worked around this by just calling Membership.ValidateUser prior to processing each service call on the server.
A user is prompted for an id and password when logging on to the client. I store both values encrypted in the proxy class and pass them transparently with each call using a host header, so that the application does not have to bother with this once the user is logged in, i.e. the credentials were validated once by calling the Login() service method (which only calls Membership.ValidateUser).
I use the CryptoApi on both the server and the client side.
I understand that host headers are somewhat outdated for security applications, but since I use strong encryption AND SSL, it is perfectly adequate.
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").