I'm reading about how wonderful Integrated Windows Authentication is, but there is only a few comments about how it's only good for intranets. So just to be clear, is it safe to say that this technology is not realistic for internet applications? I'm developing a desktop application that connects with SQL Server and I just can't imagine telling all my customers to configure a windows account on their home PCs according to my specifications. Am I missing somethimg because that seems quite unrealistic.
(of course, where the DBA has a close relationship with the users on an intranet, it's a different story.)
I would have to say yes, Windows Authentication is best left to intranet applications - it's ideal for any authenticated communication that needs to take place on the same network.
It sounds like you want to allow the desktop app (running on your client's machine) to directly talk with your SQL Server? I would strongly recommend against allowing direct public access, especially if you cannot lock the port down to a list of known IP addresses. Instead, consider putting WCF Web Services between the database and the desktop client.
Related
We have an application which is hosted on the on-premises Windows server (IIS) server
now I created a windows server on azure and building a web app for it.where the application needs to authenticate the user by windows server (DC) using kerbrose protocol but I couldn't find any documentation regarding this from Microsoft's side
Is the above query possible to be implemented in the azure web app?
No, it's not possible. Windows Authentication is something for on-premise deployments. For Azure Web Sites Azure Active Directory is clearly the best option. Sync from AD to Azure Active Directory is also quite easy to setup.
If you still want to absolutely use Windows Auth and host your website on Azure, you can create Windows VM and host your website there. You then need to join the VM to your AD. To this, both VMs must be in the same network. So if your VM is on-premise you will need to create an site-to-site VPN.
For more information, follow this SO which also discussed about this.
If your intention is to join the VM hosting the website to a domain then as others have mentioned, this isn't possible.
However, doing Kerberos authentication itself within an Azure website isn't particularly difficult, but it does require manual implementation. Windows natively handles all of this for you on domain joined machines and and IIS exposes that functionality. Since you can't domain join you have to manually do all that heavy lifting and request and validate the tickets yourself.
This involves creating a service account in Active Directory and keeping the account password in sync. Once you have that you need to indicate to the browser that it needs to negotiate auth, which is done with the WWW-Authenticate: negotiate header on a 401 response. The client, if configured to send tickets, will send a ticket in the Authorization: Negotiate YII... request header on a subsequent response. At this point you need to shove that negotiate header and that original service account password into something that can validate Kerberos tickets. Windows SSPI will do this for you, but it's a pain. I built a library that'll do this for you: Kerberos.NET. YMMV with what works best for you.
All of that said, it may be more beneficial to switch over to a more modern authentication mechanism like OAuth/OpenIDConnect/SAML.
There are several ways depending on if you have to allow access to users who are associated with a on-premise Active Directory or not.
You should have a look at this service: https://learn.microsoft.com/en-us/azure/active-directory-domain-services/
It will offer an Active Directory within Azure where you can domain join your VM to and then using Kerberos as authentication protocol (should work the same way like on prem).
The other option would be to create a new Active Directory within your Virtual Network (via 1 or 2 small Windows Server VMs where you create the AD).
The good thing if you are using Active Directory Domain Services would be that you could extend it to your on-prem Active Directory by synchronizing or federating your on-prem AD.
There are more informations regarding these scenarios here:
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-hybrid-identity
For a Azure App Service - Web App you would connect it to your Azure Active Directory (AAD) and use the hybrid identity model to allow users who originate from an on-prem AD access to it:
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad
Hope this helps a bit, it is a rather complicated topic you are digging into.
I'm totally new to PWA (rather I'm still considering adopting PWA or go Electron).
Looking at the concept and guides of the app on the web, it seems that the capability of it is to this extent, thus;
Access web APIs securely and easily
Yes, as it is the alternative implementation of web apps.
Access local storage of the PC for the app
Yes, through HTML5 web storage.
Access any local files in the PC
No?
Communicate with another desktop app through TCP connection
Yes? By posting/getting some query to localhost for example?
Obtain system info like PC status or installation path of another desktop app
No?
How many of my understandings are correct? Is there another capability or limitation to be specially noted?
Good morning,
I have found that many of my customers have MS Access already installed on their PCs. Although Access is very limited as a data store, I have found that it is great for deploying low-cost front-ends for entry level customers.
I want to start renting a VPS, so I can host customer databases using Microsoft SQL Server 2008, which they can access using a locally stored Access front-end. I do have a few questions though:
In order to access the remotely hosted databases, and use the security features, would the VPS need to be set up as a domain controller, using AD DS? If I am hosting multiple customer databases, this is not an option.
What I envisage is being able to set up a simple MS Access front end, to access a MS SQL Server database on my VPS. For security, I would want the database to use the Windows account on the client machine to authenticate, and also to provide basic data change tracking.
Is this possible? Or, will I need to set up a server for each client and have it configured as a domain controller, etc?
You can have many databases on the same server, so for each client you d not need to setup a separate domain controller. Only the connection strings will be different.
You can use SSL for establishing connection with the remote server to make the process more secure. You can also make a few web services to play with the data (CRUD operations), this would also make things more manageable.
take care :)
Is there a way to limit the login to a web application based on client machine name or id. The requirement is a certain userid login should be done only from pre-determined or preset systems.
Hope this covers the queries mentioned.
I am not sure if IP address of the machine can be used as much effective as the machine name or macid may server the purpose.
Client OS can be windows or mac. Its a public facing site but a certain group of users should login from certain machines only.
The site is php, mysql and hosted on apache and linux.
Generally speaking, a web browser will only send basic HTTP headers along for the ride, in addition to a known IP address.
Assuming you even could get this information from the client system via javascript, it would not be trustable, (eg, a client could fake it).
Perhaps you can expand your question a bit?
A bit of a generic question but let's say you have a desktop app that allows a user to connect to a central server and provides functionality like:
Login
Ability to auto-download profile data on login
Download and uploading save files through the app
A web-server (JSP/ASP.NET/PHP/etc) would do lots of work for you especially on the request-serving and threading front, but it seems a bit of a cheat for a desktop app to use HTTP requests like this.
All thoughts welcome. Maybe this should be community wiki?
If you want to leave things open for other possibilities in the future, go with a web server. That way, if you decide to write a web-based version of your desktop app (or an iPhone/Pre/Android application), you don't have to rewrite your socket server. Almost everything can speak HTTP these days.