What are the authentication options for having a ASP.NET web application communicating with a WCF service?
The scenario:
User enters their username and password in an ASP.NET form.
ASP.NET needs to pass this to WCF to authenticate the user.
If authenticated, the user can perform actions on the website. Each action would require sending data to different WCF operations. WCF needs to know who the user is on each call.
The easiest solution would be to store the username/password in the ASP.NET session state. However, this is insecure because the password is stored in memory on the server.
I would rather not use a certificate to authenticate the ASP.NET "client" to the service because there's a possibility that this WCF could be consumed by another client in addition to ASP.NET.
The best suggestion I've seen so far is to use Windows Identity Foundation (WIF). It appears that this requires an STS. According to MSDN, Microsoft does not seem to recommend setting up an STS through Visual Studio. There's no guarantee that an STS would be available in the deployment environment as some environments may use Active Directory and other environments may have a custom user store. Is it possible to setup a custom STS to authenticate against a custom user store? I'm having trouble finding documentation on doing this.
Are there any other options besides using WIF? What about a custom WCF authentication service that returns a token that can be used for authenticating against a primary WCF service?
The standard way of doing this is by using WIF with Microsoft's STS viz. Active Directory Federation Services v2.0 (ADFS).
There are a number of custom STS available e.g. Identity Server. This use a SQL DB as an attribute store. It's open source so could be adapted to whatever you require.
You can create your own custom attribute store: AD FS 2.0 Attribute Store Overview.
TechNet WIF / WCF: WIF and WCF.
Related
I'm developing a Blazor (ASP.NET Core hosted) project and hosted on IIS.
Back the day when I use ASP.NET core 2.2 with razor page, it can use windows authentication.
However with dotnet core 3.0, only Blazor server-side project template has windows authentication option to choose.
But what about the Blazor (ASP.NET Core hosted) project template? From my understanding, it's just like Blazor client-side + dotnet core MVC backend.
I don't understand why there's no "windows authentication" option for it.
In Blazor WebAssembly apps, user authentication and authorization must be handled by the back end web Api, because all client-side code can be modified by users.
Your ASP.NET Core Api can use the Windows authentication and keep track of the authentication state in a cookie. In Blazor WebAssembly you can implement an AuthenticationStateProvider which calls your web Api to get details about the authentication state of the user.
Then you can use the AuthorizeView component to show or hide content depending on the users log on state.
A clear description you can find in Blazor Prepare for Authorization
Source code example in https://github.com/Forestbrook/BlazorAuthorizationExample.
There are 2 problems to solve.
For the webassembly, use the solution with the AuthenticationStateProvider to get the user authenticated and do a call to the api (enable windows authentication and disable anonymous login) that returns the windows username and the authorization roles, if you use them for authorization. Load the roles into client side identity as claims and the webassembly is set up for authentication & authorization.
Because all code is run in the webassembly, you should also protect the serverside api controller actions with authorization attributes, except for the call that identifies the user to the wasm.
Enable authentication and authorization on the server api and use the IClaimsTransformation to modify claims for the authenticated user.
When configured correctly, you can use authorization attributes on the controllers too, securing the api.
You can implement StateContainers on both sides to cache user information so you don't have to read the database for the same info on every action. I use a singleton for that, with a retention time of 5 minutes. You may then update the timestamp on every cache read so you effectively call the database only once.
I think it will including this feature in later version according to asp.net core github
This is a multistep process, the basic outline is as follows. Best guide I have found is from Chrissanity.
On the server get the current Windows User and store it in a cookie using Blazored.LocalStorage nuget package.
Read that cookie in on the client in ApiAuthenticationStateProvider.cs
In a .razor file use [CascadingParameter] private Task<AuthenticationState>
authenticationStateTask { get; set; } to read the value into your component.
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 been assigned to find a way of implementing SSO in our products. We have several Winform applications and one asp.net 4.0 web app (not MVC).
All the products are built using .Net 4.0, the web app is ASP.NET 4.0.
Some of the Winforms are commmunicating with our API via web services (asmx) and some uses our API directly. The web app is using the same API as well. We offer a set of web services (asmx) that uses the same API to external clients.
Currently we have our own authentication implementation (user, password, roles) in our systems and we would like to replace that with SSO. Or can these two authentication regimes co-exist somehow? The Winforms are used in intranets and the web app is used both in intranets and we also hosts the web apps for clients (accesible from the Internet).
The users are created in our system, but at the same time we import users from Active Directory using our own tool. Active Directory is really the primary user source.
I have read about Windows Identity Foundation and I wonder if I can use that to implement SSO. But what I don't understand is how to use WIF in the winform applications when they use the API directly.
What I would like to achieve is to remove all user administration from our system and use Active Directory as the user source. I guess that means using ADFS 2.0 to create claims, etc.
I can use .Net Framework 4.5 in this implementation (I know that WIF is now a first class citizen in .Net Framework 4.5).
Do you have any advices how to do this? Is WIF the best alternative to achieve SSO across winforms applications and web apps?
There is a way to get the WIF authentication cookie from within the WinForms application.
To do it, you just host the WebBrowser control and point it to the login page of your web application. Assuming the web application is federated with the ADFS2, the web browser control will automatically follow the flow - it will redirect to ADFS and stop there to show the prompt for user credentials (ADFS2 in Forms Authentication mode) or just authenticate using NTLM/Kerberos (ADFS2 in Windows authentication mode). Then the web browser will redirect back to your application.
This is where you hook your code. You just add a handler to the web browser's navigation event and you check when it comes back to your application AFTER ADFS2.0 authenticates the user. You can then call the InternetGetCookie method in the WinForms app to get all the authentication cookies issued by your application and you can close the window which hosts the web browser.
At this point, you have all authentication cookies issued by WIF (the SessionAuthenticationModule) for your application. You can now call your application web services and inject cookies into http calls. The web server will correctly recognize users as authenticated which means that all you have to do is to add proper authorization to your web services (the PrincipalPermission on your web methods should do).
An alternative approach would be to expose WCF services from your web application and guard them with WS-Federation active authentication. The downside of this approach is (in my opinion) that if your identity provider (ADFS) is further federated with yet another identity provider which DOES NOT necessarily implement WS-Trust/WS-Federation then the active authentication will probably fail (because the other identity provider does not implement it) while the passive scenario will still work (a bunch of redirects will sooner ot later end with a page which requires user to provide the credentials but the flow of authentication protocols between consecutive identity providers does not matter).
i'd like to recieve comments on the way i'm trying to build an asp.net web application which uses a WCF service that is hosted in another asp.net application. Both applications will live on the same machine, but the app with the WCF service will not be accessible from the outside. there will be two web servers sharing the load behind a load balancer.
The app pool of both applications will use the same local user account (web server is not part of a domain) and so i was thinking to use WsHttpBinding with windows security for communication between client and internal wcf service.
The fron-end asp.net app uses forms authentication through a custom membership/role provider to athenticate and authorize users. The user database is in a sql server database.
i need to somehow pass to the wcf service the user details (username + roles) so that in the wcf it will be possible to validate and authorize according to the roles of who is logged in the front-end. I read i need to use "support tokens", but i haven't figured out how to use this.
I read also something about claims and WIF, which seems interesting but have no idea how i could use these in my scenario.
is there anyone who can give me recommendations about the architecture and maybe also show me how to pass the username to the wcf service and also show me if possible to use claims based authorization?
First of all, if both servers are behind the corporate firewall on a corporate LAN, I would strongly suggest using netTcpBinding instead of any http based binding. NetTcpBinding is much faster due to encoding the message in a binary format.
As for username / password: your ASP.NET front-end server could set the client credentials for the user calling for the WCF service - after all, the ASP.NET servers do have access to the ASP.NET membership database, don't they?
Or if you cannot pass on the user's credentials, you could pass on some headers to your WCF service that would describe the user - actually, you probably only ever need the user's unique ID - since the WCF service could fish out the rest of the info from the ASP.NET user database again, if really needed.
As for claims - I don't think they'd be a good idea here - you don't really have to deal with a multitude of different authorization schemes, and you're not using any federation (e.g. allowing users from a different company or domain to use your services) - so those obvious benefits probably won't really be applicable to your case.
My scenario is this - I have two ASP.net websites. Both sites run on the same machine and I have implemented single sign on relatively simply using the default asp.net membership provider (Forms based authentication).
I have a new WCF service on one site, which will be called from the other site. A user will be logged into the site, but the call to the service will be made from the codebehind following a postback.
Can somebody point me in the right direction so that I can pass through the Forms based credentials of the logged in user to the WCF service on the other site? Presently it's passing the NETWORKSERVICE windows credentials.
Check out the WCF Security Guidance on CodePlex, and most notably:
How To – Use Username Authentication with the SQL Server Membership Provider and Message Security in WCF from Windows Forms
It shows quite nicely, step by step, what config you need on the server to make your WCF service use message security with user authentication against an ASP.NET membership store.
Also check out the article Fundamentals of WCF Security - page 3 shows the options about authentication and authorization - quite informative as well!
Hope this helps!
Sounds like you're after Impersonation, which would allow you to pass on the original caller's identity to the second service call.
See the CodePlex Link - Impersonation in WCF