I am creating a .NET 4.5 WCF web service for deployment on Windows Server 2008 running IIS 7.0. I want my web service to identify the users who access the service by authenticating a Kerberos token string that is passed through the web service. I can't use Integrated Windows Authentication (some of my clients are using Linux machines) so, I must pass the token string. Does anyone know how I can do the following:
Generate a Kerberos token string in C# .NET 4.5 based a users current identity.
Validate a Kerberos token string in C# .NET 4.5 and get the associate username.
Thanks!
You could maybe expose the service with two bindings, one for Windows-users with Windows-authentication and one for others using user name authentication. Is it an intranet or internet scanario? How are the Linux users identified?
Related
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
A bit of introduction from my end about the Application:
We are having ASP.NET web application with SQL server membership provider for user authentcation. In addition to this our application supports SSO from client's application(for ex: siteminder).
One of our client is changing their SSO infrastructure from siteminder to Azure(Active Directory Federation service) as I am pretty new to Azure ADFS so I am not aware of what all things are required and the procedure to connect to our ASP.NET web Application. Though I have certain queries too:
will there be any infrastructure change from our end? means do we need ADFS server at our end to communicate to the client's ADFS server OR is it possible that we connect directly to client's ADFS server from our ASP.NET web application?
will there be any software upgradation required? currently we are using Visual Studio 2013(update 2), .NET Framework 4.5
Note: Application needs form authentication for internal users
There is no such thing as Azure ADFS.
There is Azure AD and ADFS. They are completely different products.
ADFS only authenticates against AD. It cannot authenticate against a SQL server membership provider. If you need this, use identityserver to authenticate against the DB and federate this with ADFS.
You can either federate your ADFS with theirs or connect your application to their ADFS. Both are valid.
To do this, your application needs to support WS-Federation (WIF), SAML 2.0 or OpenID Connect (ADFS 4.0).
Development Environment: Windows 7 Enterprise with
.NET 4.0 with Visual Studio 2010
Production Environment: Windows 2008 Server with IIS 7.0
I'm trying to figure out the best way to authenticate and authorize against a WCF service running on a separate machine in a separate security zone from the ASP .NET web application.
Users log in with a username and password against credentials we have stored in a database. We did not implement Membership Provider, but when the user's credentials pass mustard, we manually create a Forms Auth ticket with the user id.
I did roll my own Role Provider that implements RoleProvider. As a result, we have "standard" ASP .NET roles along with a forms auth ticket working on our ASP .NET web application.
What I need to do is somehow pass these credentials along to the WCF service that's sitting on another machine. Originally, I thought I might use the Windows Identity Foundation and create a custom Security Token Service (STS). Basically, if the user authenticates, then create a token and add in the claims based authorization along with user identity into the token and pass that along to the WCF service.
We are currently using a .NET Remoting service (.NET 1.1 timeframe) that does not authenticate or authorize at all.
That seems like it might be a bit of overkill as there might be a way to simply pass along the information I currently have with the user as when you create the Forms Auth ticket, I know the current IPrinciple is set with the IIdentity set with a "name" property set to the user id on the Thread.CurrentIdentity.
I'm pretty sure IsInRole("WhateverRole") would work correctly at this point too, but all of this is on the Web application side. Nothing gets passed to the .NET Remoting service.
Looking at these two classes:
AuthenticationService Class
ServiceAuthorization Class
I don't think they are what I want. Likewise, I've read through Michele Bustamante's Learning WCF, but I don't really see this particular scenario covered. When I read about Windows Authentication, I keep thinking that needs to be tied into some internal NTLM or Kerberos associated with the internal Windows security situation. None of our users are internal users. They're strictly external.
Now, I know that if the user gets a Forms Auth ticket, they essentially get a valid IPrinciple and the roles should be set, right?
If so, is there a way to pass this along to a WCF service setting on another machine? If I set the WCF clientCredentialType to windows and set the serviceAuthorization principlePermissionMode to "UseAspNetRoles", will these be passed along in the security context from the web application to the WCF service when I make the service call?
Nothing I can find is clear on how this might happen. Thanks.
I think what you want is this:
http://thoughtorientedarchitecture.blogspot.com/2009/10/flowing-aspnet-forms-authentication.html
This isn't super secure, since you're effectively creating your own man-in-the-middle attack, but it's probably secure enough for most needs.
Essentially this boils down to this:
Configure both servers with the same MachineKey
Grab the FormsAuthentication cookie from the user request
Attach the cookie to the outgoing WCF service call
???
Profit
I've got an ASP.NET (.NET 4.0) application that uses Windows Forms Authentication. This authenticates against Active Directory and works just fine.
This web app calls an ASP.NET Web Service(.NET 4.0) on the same server. Both the app and the service are running on IIS 6.
The web service calls a SQL Server 2005 database in the same domain using "Integrated Security=SSPI" as part of the connection string.
I want the web service and the database connection to use the credentials of the logged in user of the web app.
I've tried dozens of combination of settings from dozens of web sites, but nothing has worked. I'm on my second day and haven't gotten anywhere.
Is this even possible?
In my latest attempt, I added this code in the web app before calling the web service:
svc.Credentials = System.Net.CredentialCache.DefaultCredentials;
But inside the service, User.Identity.Name returns the value of the user who started the web server.
What you're trying to do is called "delegation". It means that the end-user is authenticated with the web server, and then the web server tries to use those credentials to gain access to the SQL Server. But the SQL Sever does not trust the web server, it only trusts the domain controller. So the request fails.
Besides not working, delegation has another disadvantage. Because each user would use different credentials, SQL connections would no longer be pooled. Each credential would have its own pool. That would be a major resource hog even at low user counts.
For more information, check out this MSDN article.
TL;DR: Give up on delegation and move to SQL auth.
I was wondering when using Windows Authentication mode in a connection string from a web application. Application itself is using Windows Authentication for authorization. Which account will be used to login to SQL Server.
Is't the web application pool account?
User account who logged in to web application using windows auth?
Any other account?
Application is running under Win Ser 2008 64 bit and IIS 7. Application pool account is Network Service.
It depends on how you configure it. From http://msdn.microsoft.com/en-us/library/ms998292.aspx and http://msdn.microsoft.com/en-us/library/bsz5788z.aspx ...
ASP.NET applications do not impersonate by default. As a result, when they use Windows authentication to connect to SQL Server, they use the Web application's process identity. With this approach, your front-end Web application authenticates and authorizes its users and then uses a trusted identity to access the database. The database trusts the application's identity and trusts the application to properly authenticate and authorize callers. This approach is referred to as the trusted subsystem model.
The alternative model referred to as the impersonation/delegation model uses the original caller's Windows identity to access the database. This approach requires that your ASP.NET application is configured to use impersonation. See the section "Impersonation / Delegation vs. Trusted Subsystem" in this document.
So depending on how you have configured it, it could use either the app pool account (not when not using impersonation) or the account of the logged-in user that is using the web application (when using impersonation).
See http://msdn.microsoft.com/en-us/library/134ec8tc.aspx for impersonation information.
It's the application pool user who connects to the database, if you specified Integrated Security in your connection string.
The problem that i was having was that my application pool account in SQL Server needed to be set to the db_owner role before it worked. I spent a long time trying to figure this out.
I was using Windows Authentication, Windows 7 home premium, and IIS all on the same computer. I'm posting this in case someone else run into a similar problem. The book i used did not say to use db_owner but the reader and writer accounts instead.