I have the Using CSLA e-book series, and I've gone through a bit of the security-related sections but I'm having trouble pinpointing where to find a description of what I want to accomplish using CSLA 4 / ASP.NET MVC 4. I'm hoping someone can point me to the location that is relevant for what I'm looking at.
I want to have an MVC app on an IIS server in the DMZ (not part of the company domain). I want the user to be able to log in using his domain credentials, and have those credentials passed to an app server behind the firewall in our domain where that can somehow sync up with Active Directory so that he can be authenticated and given appropriate authorization based on the AD group(s) he is in. I do not want to have to require the user to create yet another password for one of our applications. In other words, I think it looks like this:
How would I go about this? Does the Using e-book series address this specific scenario or are there other resources that would assist? Thanks.
No, the books don't cover this scenario.
You should look at ASP.NET MVC focused books or content, because the problem you face has nothing to do with CSLA, and everything to do with ASP.NET and Windows AD security models.
Once you solve the core problem from an ASP.NET/IIS/Windows perspective, getting CSLA to work with the resulting solution is easy, and is covered in the book, because it is just a matter of telling CSLA to use the principal you'll end up creating as part of your solution.
This is really outside my area of expertise, but there are a couple possible things I'd look into.
First, Kerberos might be helpful in allowing a non-domain server to authenticate with domain credentials. I don't know if that's true, but every time I encounter a complex Windows authentication scenario it seems like Kerberos is part of the answer :)
Second, you could do a low-tech solution by having the web server get the username/password from the user (presumably over an SSL connection), and then you could pass those values to the app server yourself. There's a way to use the WindowsPrincipal (or WindowsIdentity?) types in code to impersonate a user if you have their username/password.
In this second case, your solution would be extremely similar to the way you'd implement AD security in a Silverlight app. Just think of the MVC server as being a Silverlight client, and the app server being the app server. The WPF/Silverlight book walks through this scenario in some detail.
Assuming I go with the "low-tech" solution you mention, what kind of authentication mode would I tell CSLA to use?
I have already found how to impersonate via code, so what I guess I would do is as follows...does this sound right?
Yes, you are correct. And this is what is typically done to implement AD authentication in a Silverlight app. What's important about that, is that the SL book has the code necessary to get the AD roles into a custom identity object.
Even though this has nothing to do strictly with CSLA, I wanted to ask a question since I've made some progress on the "low-tech" solution Rocky and I were discussing.
I have the external website (in the DMZ) set up to use SSL for obvious reasons. Now that I have successfully tested the authentication process, I'd like to know if it is necessary to have the DMZ server communicate with the remote DP server (inside the firewall in our domain) also over SSL. Is it possible for someone to do packet sniffing on that channel? Or can I safely assume that the data going over the wire between the DMZ and internal servers is now invisible to someone on the outside?
By way of reminder, the scenario is:
- user supplies credentials to page on DMZ server (over SSL)
- credentials are sent to the remote DP on an internal server (*** do I need SSL here? ***)
Thanks.
The method I described uses CslaAuthentication of CSLA in the main web.config with a custom Principal and Identity that are loaded in your main application from a FormsAuthentication cookie.
The authentication portal is actually a separate application with the IIS security type set to Windows which just verifies the user's identity and sets the cookie (probably pushing the roles into the userdata portion of the cookie). It will also need a separate (or embedded) DP that uses Windows CSLA authentication.
In your case you'd probably want a regular login page with a button that would redirect to AD authentication that would try to authenticate based on their AD login name. When the user is redirected back, your application can read the forms cookie.
Nick - thanks for your input. I don't have a good understanding of security and haven't worked with ASP.NET in a while (and not with CSLA), so I don't quite follow. Is your recommedation taking into account the limitation imposed by the app being in the DMZ and not a part of the company domain? How does this differ compared to what Rocky mentioned (the second option using impersonation)?
From what I understand, it sounds like you are saying the MVC app would create a custom Principal & Identity and pass those to an app server (on the domain) to be compared to AD. However, you also mention redirecting to the AD authentication site, but that would assume the user would have access to hit an internal IIS server. Is that correct? We're not going to directly expose our internal web servers to the outside so I'm not sure how this would work. But I probably misunderstand...
There are two problems you have to solve.
In the DMZ:
Inside the network:
You can create a separate authentication app that uses windows authentication to set a the FormsAuthentication cookie for your custom CSLA Priciple and Identity. The main app would redirect to the authentication portal to automatically set the cookie, but if the user cannot access the authentication portal it would have to direct them to a regular login page.
Copyright (c) Marimer LLC