We Keep Coding

How can I protect WCF service from unauthorized access?

EDIT:
Please note two things: application will be publicly available and users won't need to have any accounts. You can also suggest other solution than WCF, if it's better.
I'm developing an application in C# which could install other applications easily. The list of programs supported by this application will be stored on a database on a public server. Only my application should be able to access this database. Everyone can install this application, and users do not need to have any accounts.
Now, I'm wondering how should the communication between app and server look like. I'm thinking of developing a WCF service, but everyone can connect easily to this service (only my program should access this service).
Is there any way to protect WCF service from unauthorized access? Or maybe do you have any better idea how should the communication between this app and server look like?
Thanks in advance for any help!

You can check below links for help in this topic
https://msdn.microsoft.com/en-us/library/ms731925.aspx
https://msdn.microsoft.com/en-us/library/aa702565.aspx
You can configure your bindings to perform username and password based Authentication where you validated if the username and password are valid then only you can grant access to the service.

NET has built in features for ensuring that the code calling yours is authorized to do so. For example, take a look at this snippet of code:
[PrincipalPermission(SecurityAction.Demand, Role = "MyLocalSecurityGroup"]
public SearchResults Find(string contractNumber)
{
// ...
}
Notice the [PrinciplePermission] attribute. This attribute tells .NET that only principals who are members of the "MyLocalSecurityGroup" role are allowed to run this method (where a principal is a user/service account, and a role is a locally defined security group on the server). In other words, in order to run this method, the caller must be running under an account that is a member of the local security group specified.
For more details of how to create the group click here: https://msdn.microsoft.com/en-us/library/ms731200(v=vs.110).aspx

WCF, active directory authentication|authorization and user profiles in sql combination

I'm developing a WCF service that will host business logic of the application. The application is mostly for intranet, but can be accessed from internet. We have an active directory domain up and running, so I plan to authenticate and authorize users according to their username and groups they are in. This service will be used mostly be an ASP.NET MVC site
So, first question is how to authenticate and authorize users based on their AD profile?
Secondly, I need to store additional info about each user. The problem is that I can't modify AD scheme. The number of added fields is about 10 or so.
Can I somehow use SQL server for profile storage? Of course I can, but how to tie this with AD auth?

You can use WIF for this.
You would configure your WCF service for WIF in the normal way and then use a custom ClaimsAuthenticationManager class deriving from the base ClaimsAuthenticationManager and overriding its Authenticate method. This is a normal extensibility point of WIF. WIF will
get hold of the security token from the incoming request and add claims for each of the relevant AD properties. In your override of the Authenticate method, you will add new claims to represent your extra properties.
The basic use of WIF for WCF services is described here:
http://msdn.microsoft.com/en-us/library/ee748476.aspx
To see how to use ClaimsAuthenticationManager, start here:
http://msdn.microsoft.com/en-us/library/ee748211.aspx

Well, I think you have a couple of choices here, but you will have to carefully consider the implementation.
The primary issue with using active directory authentication is that by default a user's credentials can only be passed successfully between two machines. In the case of a web application, this means that the user's credentials can travel between the end user's machine and the web server, but no further.
However, this behavior can be changed through the use of Kerberos authentication, which essentially allows an authentication ticket to be passed among all of the trusted machines in the chain (i.e. from the web server to the application server to the database, for example). Successfully configuring Kerberos can be extremely challenging, especially if you have had no prior experience with it.
I think your best bet is to configure your web site to accept only Windows Authentication. This means that IIS will perform the validation of the user against active directory. In your ASP.Net application you can pickup the domain name of the authorized user from Request.ServerVariables("logon_user").
At this point, you can log the user on with FormsAuthentication, for example, without requiring them to login again.
You could then either implement the SQL Server Membership Provider or create your own interface to your database for further user validation and extra information storage. We have used both mechanisms, but I prefer the self-built one due to the additional control it provides and, in this case, you won't need a lot of the functionality (password reset, recovery, etc) that the membership provider offers.

Windows authentication hybrid

I am using windows authentication for an intranet MVC application. I want to add additional logic to the authentication process. In other words as well as existing in AD, the user must also exist in a custom database before they are authenticated.
They should also be to log out of the MVC app, and login again with the same AD identification, but with a different department selected.
I'm not sure of the best way of approaching this, as switching on windows authentication prevents any custom membership provider from being run.

I think You would have to use domain mechanisms, and check if a user is in a Role.
Scott Gu's description:
http://weblogs.asp.net/scottgu/archive/2006/07/12/Recipe_3A00_-Enabling-Windows-Authentication-within-an-Intranet-ASP.NET-Web-application.aspx
MSDN description:
http://msdn.microsoft.com/en-us/library/ff647405.aspx
... this is actually easier than making SQL account permissions in a Domain

if you are using then IE will send through those credentials to IIS. To reduce a dependency and AD being accessible and quick enough you can pull AD information into some tables local to your app, then use those tables. Constantly broadcasting to AD may cause you some app slowness. Once you have a list of AdUsers and Groups then are in, in some local db tables, then when a web site mvc user they can presented with a list of choices of ad groups they belong to. When they have chosen one of the AD Groups they belong to, set the group in the cookie and/or session state.
An issue with this is that your AD db tables will need to pulled from ad and updated every so often.
Just one of doing it ...

Restricting Users from different Web Applications

okay I have a web application that manages the logins for different client web applications, stored inside the root folder. Each client web application has its own login controlled by C# Roles class, where by they are routed to their site.
http://msdn.microsoft.com/en-us/library/system.web.security.roles.aspx
Now while logging in and using the site works perfectly, the problem is if a user enters the url for one of the other client sites, it allows them access to it.
Is it possible to restrict this access?

Your roles should be attached to a specific application. This can either be done with separate databases for each application, by adding and filtering based on the associated application within your role manager, or using application specific roles for each application (I'd avoid this, but it should work). If you have the role "user" that is used by multiple applications without any filtering, then the individual application won't know whether it's a user for their app or not, and thus by default allow any "user" to access any application that allows users.

What's the difference: Windows Authentication, Passport Authentication and Form Authentication?

Just going to start making a web application and was wondering which was better, or at least what are the main differences between them (as it probably matters what I am using them for)?
Windows Authentication
Passport Authentication
Form Authentication

I would say it greatly depends on what your web app will be doing, as each one has its place. Here is some brief details about each one.
Windows authentication enables you to identify users without creating a custom page.
Credentials are stored in the Web server s local user database or an Active Directory domain. Once identified you can use the user s credentials to gain access to resources that are protected by Windows authorization.
Forms authentication enables you to identify users with a custom database such as an ASP.NET membership database. Alternatively you can implement your own custom database. Once authenticated
you can reference the roles the user is in to restrict access to portions of your Web site.
Passport authentication relies on a centralized service provided by Microsoft. Passport authentication identifies a user with using his or her e-mail address and a password and a single Passport account can be used with many different Web sites.
Passport authentication is primarily used for public Web sites with thousands of users.
Anonymous authentication does not require the user to provide credentials.
http://msdn.microsoft.com/en-us/library/eeyk640h.aspx - ASP.NET Authentication further details on forms and window authentication
Edit
Rushyo link is better: http://msdn.microsoft.com/en-us/library/ee817643.aspx

Situation as when you can use what :
Windows Authentication : As you will be using the login & password used in a domain... If you use windows authentication, your webapp will (generally) have to be deployed in a network server and all your users should (generally) have a login created for them in the domain. Though cross domain operations are possible, primarily you wont be able to use it in non-domain based environment like public websites. It will be tough if you want to include some users who are outside your domain.
Forms Authentication : Here you are deciding to act independently. You will assign each user a separate userId and password and will manage them yourself. The overhead here is you should provide and restrict the ways users are created and removed. Here you are not restricted to any domain. For any user to gain access to your webapp should get registered with your webapp. This is similar to any mail sites you see on internet.
Passport Authentication : You are depending on MS to validate your users. This will give you a global status to your application, but if you are going to deploy it only to a small group of users, you will be forcing them to create a passport account (if they don't have) so that they can access your application.
To make it more clear.. Whichever method you follow You can still restrict who can access your webapp, and can also define your own roles for each users.

This should cover everything you're looking for (and more):
http://msdn.microsoft.com/en-us/library/ee817643.aspx
[Snap - I was totally going to use that exact same quote as well ;)]

Windows Authentication : As you will be using the login & password used in a domain... If you use windows authentication, your webapp will (generally) have to be deployed in a network server and all your users should (generally) have a login created for them in the domain. Though cross domain operations are possible, primarily you wont be able to use it in non-domain based environment like public websites. It will be tough if you want to include some users who are outside your domain.
Forms Authentication : Here you are deciding to act independently. You will assign each user a separate userId and password and will manage them yourself. The overhead here is you should provide and restrict the ways users are created and removed. Here you are not restricted to any domain. For any user to gain access to your webapp should get registered with your webapp. This is similar to any mail sites you see on internet.
Passport Authentication : You are depending on MS to validate your users. This will give you a global status to your application, but if you are going to deploy it only to a small group of users, you will be forcing them to create a passport account (if they don't have) so that they can access your application.
To make it more clear.. Whichever method you follow You can still restrict who can access your webapp, and can also define your own roles for each users.