We are using Identity Server 3 in our tool that has the following structure. One (AngularJs) Spa with 10 Web APIs . We use the WindowsAuthWebHost mini project to do the windows handshake to get the windows(domain) identity of the user, based on which we build a complex(with custom claims) token that it's used by the client Web APIs. All the 10 Web APIs have anonymous authentication set in the IIS. And it works smoothly.
Now, we are trying to expose this tool outside the company network and a perquisite is to have windows authentication on all the Web APIs in the IIS. If we set this time of authentication, now all the calls are unauthorized.
Do you know if there is a way to keep the same flow, but also validated the windows authentication?
Windows authentication will not work outside of the network. The user needs to have a valid user account in your domain (username/password), or even a local account on your IIS server.
Note that NTLM doesn't work through some proxy servers, so this is one reason that Windows AuthN isn't used so much on the public internet.
To achieve your requirement you could use the form authentication with active directory.you may need to enable both form and anonymous authentication. then create deny authorization rule for anonymous users and allow rule for all users.
How To: Use Forms Authentication with Active Directory in ASP.NET 2.0
Related
I have this legacy intranet app using an AngularJS SPA consuming an an ASP.NET Web API (on .NET 4.6.1) and I can't manage to get the user authenticated on the domain inside the API, when calls are made by AngularJs.
Inside the API I have situations where I need to get the domain authenticated user. I have tried several combinations inside IIS to set both the AngularJS app and the API with Windows authentication, Impersonation, Authorization Rules. I've read several questions in Stackoverflow and other forums and also searched through several articles but I can't manage to find a solution, I'm feeling helpless in this one.
When I make a direct call to the API using a tool like Postman or through Swagger, System.Web.HttpContext.Current.Request.LogonUserIdentity.Name shows the correct authenticated user.
When I make the very same call to the API but through the client, like loading a page that requests data from the API, the user shown in LogonUserIdentity, is the one set on the app pool.
The authentication between the client and the API uses bearer token.
Here's my current scenario:
IIS:
Windows authentication enabled for both the client and the API, Impersonation enabled for both the client and the API
Authorization rules for ASP.NET and IIS set with allow all users for both Client and API
Session state in-proc, using cookies and with UseHostingIdentity set to false on both Client and API
Both the client and the API are using the same AppPool, with integrated Pipeline, .NET CLR v4.0,
If there's more info to supply please let me know, I'll update the question with the required info.
All,
I am using the ASP.Net MVC 4 application.
I have enabled Windows Authentication.
Till now it is working fine.
Now I enhanced the application to connect to TFS via its API.
For this, I need to use the windows authentication credentials.
I have tried using
ICredentialsProvider credential = new UICredentialsProvider();
TfsTeamProjectCollection teamProjectCollection = new TfsTeamProjectCollection(collectionUri, credential);
This works great in the development environment. But when I host the application in IIS 8.5, it is not working at all under "Application Pool Identity" and "Network Service" account.
I tried with Local System and specific user in identity of application pool, it is working.
But I need this to work based on the windows credential (Active directory).
Can anyone suggest a solution?
You can deploy your web application on the TFS App Tier and configuring its app pool to run as the same identity as the TFS web services, and enable ASP.NET impersonation. Check this case: ASP.NET MVC3 Windows Authentication Pass Through to TFS
You are likely hitting a Kerberos double hope issue.
You have two options to resolve it:
Host your mvc web app on the same server as tfs
Configure Active Directory to allow your servers identity to delegate the logged in user credentials to another service.
#1 is easy but #2 will require a bunch of work for your Active Directory domain administrators.
https://support.microsoft.com/en-us/kb/810572
You will need:
At least one Service Principal Name (SPN) configured for your server's account (either a dedicated domain\svc_myaccout or the domain\servername$ account for Network Service).
The account you use needs to be enabled to allow delegation in AD
The server that hosts your application needs to be enabled for delegation
This is not 101 and in my experience, having done this a bunch in enterprise and small business, that most Domain Administrators don't know how Kerberos delegation works, or how to configure it.
You will need to learn how and make explicit requests that they can action. Like "run 'setspn myapp.mydomain.com domain\myserviceaccount'".
I have three asp.net applications. Only one of them has a forms authentication login. I redirect anonymous users to that one login page for all three applications to login. Once they log in, they automatically redirected back to the application and page they were attempting to access.
I enabled this functionality by setting the same MachineKey in all three applications.
Is there a way to do this for ADFS 3.0 WIF authentication as well? It doesn't seem to work the same in my testing. When I log into the application that is wired up to ADFS, I still can't access the other two.
WIF and ADFS don't work the same way as traditional forms authentication. These technologies rely on issuing access tokens, and require that dependent applications (also known as Relying Parties, or RPs) configure a trust relationship with the token provider (AKA Identity Provider, or IP). You can't share the cookie with MachineKey between apps that have not directly authenticated with an IP, and to be quite honest you don't want to.
The typical web scenario (also known as Passive Federation) is to have a separate application that functions as a Security Token Service (STS). This application houses the Login.aspx page and is protected with Forms or Windows Authentication like you would find in a classic ASP.NET scenario. When you attempt to access a web application that requires authentication, it needs to be set up to redirect you to the STS website, rather than handling it by itself. Once you log into the central STS, it will issue you a token that you then provide to applications to gain access. If you use WIF properly, this is all handled behind the scenes and is just a matter of configuration.
Each of your three web applications should be configured with a trust relationship to your IP. You said that you have a web application wired up to ADFS already, if that's via the proper trust relationship, then you should simply have to replicate that set up to your other 2 applications.
I need clarification how to apply domain login in my asp.net application.
So I have following architecture: Three machines: at one is working asp.net application, another one is database server, and from last machine I am accessing application.
My application should work like this: I am accessing application from last machine it takes my domain name check if it exists in the user table and it should authenticate me.
But it works only when application is running at one machine and I am accessing application from the same one. It is connected with that impersonation in web.config file give me access only to local resources.
I find some articles at MSDN but they are too complex to apply and understand:
Explained: Windows Authentication in ASP.NET 2.0
How To: Use Protocol Transition and Constrained Delegation in
ASP.NET 2.0
How To: Create a Service Account for an ASP.NET 2.0 Application
Building Secure ASP.NET Applications: Authentication, Authorization,
and Secure Communication
From these articles I know that solution should use kerberos, delegation and impersonation. But I have no idea how to apply it.
What I have to do to implement domain login in my application? Do you have a nice tutorial how to do it? Do I have to modify only my application code or configuration of server (second machine)?
Update 1
I logged some information:
On my machine:
System.Security.Principal.WindowsIdentity.GetCurrent().Name
Returns: [myDomainName][myUserName]
System.Security.Principal.WindowsIdentity.GetCurrent().AuthenticationType
Returns: Kerberos
On three machines architecture:
System.Security.Principal.WindowsIdentity.GetCurrent().Name
Returns: [IIS APPPOOL][ApplicationName]
System.Security.Principal.WindowsIdentity.GetCurrent().AuthenticationType
Returns: Negotiate
You need to set up ASP.Net to use Windows Authentiation and impersonation (it sounds like you've done this). Then, you need to set up the web server for kerberos delegation and make sure you have the proper spn's configured for IIS and the application server.
It's working in the 2 machine case because there's no delegation involved there. It's the second authentication hop that requires kerberos.
We have an ASP.NET web application that we offer as a Service (it's hosted and it's accessible on the Web). We use Forms Authentication and our users have to enter a username/password to connect to our application. Some of our customers ask that we support single sign-on by authenticating users with their own Active Directory.
Our application has a different URL for each customer
www.ourapp.com/client1/
www.ourapp.com/client2/
www.ourapp.com/client3/
and each URL has its own web.config file (where asp.net settings can be specified and can vary for each customer).
What do I have to change in my ASP.NET application to support that?
What do I have to change on my Windows server configuration?
What will the customer have to do on his side to enable that?
Regards,
Check How To: Use Forms Authentication with Active Directory in ASP.NET 2.0 In short, you configure an ActiveDirectoryMembershipProvider to verify each username/password with the customer's AD. The customer must create an AD account for you that is allowed to perform the verification - which may be a problem with some customers. What's more, your code will handle the actual username/password used by users in their internal network, which can be an even bigger problem with customers.
A more secure solution is to use federation (using ADFS) or Claims Authentication using Windows Identity Foundation. In this case you "only" have to set trust relations between your domain and theirs.