I have a working CSLA v4 MVC3 App. I have it setup with a MVC Web tier, and a Application Server tier. It's setup using wsHttpbinding. It uses a self generated 509 certificate.
Anyway, I was setting up a test box, and set it up with basicHttpBinding without SSL. Again, it works fine.
I was writing a anonymous controller method for MVC, and to my shock any CSLA business object was able to call the Application Server just fine. This seems wrong to me.
I would have expected that CSLA would check my Identity "IsAuthenticated" flag before I went across the wire to the Application tier, or throw an exception on the application server.
The reason this concerns me is what if I placed my Application Server outside the firewall? What are the security implications then? Granted you will have SSL turned on. So, is it reasonable to think everything will be secure because of my SSL setup?
What I don't want is someone who steals my Business Object DLL is able to call my Application server without being authenticated. Currently, this is the case with basicHttpBinding or wsHttpBinding. Except, they would need to get my SSL cert on their end. This seems flawed, because what if I used GoDaddy? Would they be able to call my Application Server then?
Maybe the community can calm my fears, as I had always assumed CSLA was enforcing the IsAuthenticated flag on the Application Server.
Thoughts?
Would it always be required to have IsAuthenticated = true? - No.
But - you can easily add this to your serverside DataPortal.
Just create your own class that implements IAuthorizeDataPortal and configure this by setting CslaAuthorizationProvider in web.config.
This is the default authorizer class:
protected class NullAuthorizer : IAuthorizeDataPortal { /// <summary> /// Creates an instance of the type. /// </summary> /// <param name="clientRequest"> /// Client request information. /// </param> public void Authorize(AuthorizeRequest clientRequest) { /* default is to allow all requests */ } }
In reality - if anyone can get your assemblies they can do whatever they like!!!!!!
Reflection in .NET is so powerful that a developer/hacker can do whatever he wants
and set IsAuthenticated to true in your principal.
True, but then it seems like you would never want your Application Server out on the Internet? It seems like a security flaw that I could create a message to my application server, without being authenticated. If you have MVC with ASP.NET Forms Authentication you need a special cookie that is only created on the server, unique to that user's IP, and time bombed. This would stop a hacker (assuming Forms Authentication has not been compromised, but Microsoft seems to be quick to fix these issues).
However, CSLA's way it serializes to the Application Server seems flawed. There is no mechanism that I can see that would prevent someone to record WCF messages and re-play them back. I will give the custom Authorize a go. But like you said it's still a problem.
I am not a fan of Security by Obscurity... Maybe there is someone who has a more secure way to communicate between both tiers?
As a follow-up. I decided to add a custom authorize, checking if the CSLA user is authenticated. It's filled-out at that point, which made it easy. Then we are making sure we always use our own x.509 certificates (through WCF). That should make it so only the Web Server can talk to the Application Server. This seems to be the easiest thing to do at this point. If anyone has more ideas I would welcome them!
Like ASP. NET, CSLA is designed to support a wide range of scenarios, including the idea of guest users, and low security transports like basicHttp and other bindings.
Again, just like with any web app or service, it is up to you to understand how to secure your service or site. As Jonny points out, we provide you with a clear location to check the validity of each inbound request. Additionally, we default to using WCF, and support all the security models it supports. So you can secure your channel as much as WCF will allow and the data portal will run within that context.
Copyright (c) Marimer LLC