My scenario is a 3-Tier app where the data tier is a SQL Server database, the middle tier is a WCF application hosted in a Windows Service and finally the presentation is an Asp.Net MVC application.
As usual, the middle tier is the one that performs all of the business logic. Access database, define business rules.. etc.
Okay, so far so good! BUT now here's question: How do you handle security in such a scenario? I mean, the user has to log in on the ASP.NET application, but I want to authenticate it not only in ASP but in the WCF middle tier as well, since a WCF service is supposed to be accessed by more apps.
I want the user to log in on the Asp.Net application and let WCF know the credentials as well. Is there some kind of session in WCF in which to specify a logged in user?
How do pros handle security in this case? I know you can secure the WCF services with message security, but how do Asp.Net and WCF sync on a single logged user? I want to secure WCF operations depending on the user for authorization means.
I would suggest looking into using an approach like HMAC (Hash Message Authentication Code) for your security, or a similar token-based approach. The idea would be to sign your requests to your WCF layer which can be used to authenticate the request and identify the user making the request.
The essential elements would be a token and a shared secret of some sort used for signing each request. The token would allow you to identify the user on the WCF end, and lookup the shared secret to verify the request. You can also added timestamps / nonces to prevent replay attacks and such.
I've used this approach for some REST services built on WCF - with the added benefit that clients do not need to store usernames and passwords, just the security tokens used for communication. In your case you'll need to sort out how to exchange the tokens between the ASP.NET layer and the WCF layer, but it would provide you a unified authentication method for any consumer of your WCF services.
Have look here for UserName Password authentication.
ASP.NET Web Site + Windows Forms App + WCF Service: Client Credentials //for insights
Related
I am working on application whose details are as follows:
Its 3 tier architecture. Web Tier (ASP.Net MVC) -- Service Tier (ASP.Net WebApi 2) -- Database Tier(MS SQL 2014).
Application will also have native mobile apps as clients which will consume Service tier.
Service Tier (Web API) uses individual username/password in conjunction with OAuth for authentication and authorization.
User details are stored using ASP. Net Identity system. ASP. Net Identity database tables are in same database as that of application database.
There will be no direct calls from clients i.e. web or mobile apps to database and every request has to go via service layer.
Users of web client and mobile apps will be authenticated against asp.net identity database which is part of application database.
I have partially implemented above architecture however facing one challenge i.e. once user is authenticated, OAuth token will be issued from service layer which will be valid for one day. But how and where should I securely store this token in Web Client (ASP.Net MVC app) so that user needs to login only once in day and not for every single request that it makes.
One option I can think of is once user is authenticated and token is received in web client then store it in in-memory session storage and use it for further requests. However down side of this is, it will reduce scalability of application and will require sticky sessions in load balanced environment.
Is there any better way I can handle this situation? Also want to validate above architecture if its correct architecture?
I have REST web services exposed by APIs controllers in my ASP.NET Application. These services are useful for me to synchronize my business layer with my view layer.
Now I want to make them more secure, because I feel like all my data is exposed and that anyone can have access to them, if only he types the http url of the web service. Is there any username/password security mecanism for my web services? Or is this done via a certain configuration to IIS?
If you would like to create your own security mechanism then it would not be to hard to authenticate using tokens in the http header. For example, you could use a public/private key scheme and hash a few items that change frequently such as DateTime and input parameters and the resource url itself.
.Net provides ways to place your security checks prior to reaching your service methods so you don't even have to check the token in the http header in each of your methods. They will only be invoked if the request is authenticated.
I've got 3 different clients accessing my ASP.Net service layer. I'm in the process of moving the Silverlight client to RIA services and I'd like to consolidate my authentication code if possible. I use a custom table in my database to store user credentials and profile information.
Can an ASP.Net Membership Provider be used for RIA, MVC and Web Service applications? Or is there an easier way?
WCF: http://msdn.microsoft.com/en-us/library/ms731049.aspx
RIA: http://msdn.microsoft.com/en-us/library/ee707353(v=vs.91).aspx
ASP.Net MVC: http://www.asp.net/mvc/tutorials/authenticating-users-with-forms-authentication-cs
I got myself tied up in knots a bit trying to use the same auth mechanism for RIA and a WCF REST & SOAP endpoints; RIA is a WCF endpoint at the end of the day. However consuming a RIA service is more comparable to using an MVC app; call a login service after which the browser or Silverlight app automatically attach a cookie to all subsequent requests which will be authorised by the ASP.Net membership provider.
Conversely clients of the WCF SOAP and REST services there are better ways to authorise requests rather than force them to call a login service, extract the cookie and attach it to all future requests. The above link for WCF actually describes a mechanism where the username and password are set for every request. In practice a lot of public web API's require a single header with a secret key to be set.
My conclusion is that I'll use the same membership provider for ASP.Net MVC and RIA but a different mechanism for SOAP and REST WCF services.
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.
I'm using HttpHandlers to generate PDF report files "on-the-fly" using the authenticated user context.
However, to create the report PDF file I need to call a method on a secure WCF service with the context of the caller (the authenticated user).
I saw plenty of answers for the Windows authentication but I'm using plain old Forms authentication so the answers don't apply.
The authentication on the service side is done using ASP.NET membership (same server that hosts the HttpHandler).
There should (I hope) be a way for me to just pass on the caller context to the service.
I'm afraid I didn't make myself clear enough.
What I have is a WCF service and an HttpHandler. The user is authenticated with the WCF service with ASP membership.
What I want to do is, in the HttpHandler, be able to do
SetContextAsCaller();
myWCFService.MyMethodCall();
and have MyMethodCall() called using the HttpCaller's context to pass on its ASP ticket/username etc.
You could - depending on what binding and thus transport protocol you use - use UserName/Passwort authentication, and instruct the WCF server side to use ASP.NET membership provider for authenticating the incoming callers.
Check out the Fundamentals of WCF Security and this blog post series on WCF security scenarios - they contain a lot of very useful information on how to use and set up WCF security.
Does that help, or do you need additional info? If so: what do you need?
Marc
UPDATE:
OK, after you commented, here are a few more articles that deal specifically with a WCF service impersonating the caller - hope these help:
WCF security guidance - How To Impersonate the original caller
Delegation and Impersonation with WCF
Setting up WCF to Impersonate Client credentials
Caller impersonation for WCF services