After much study, testing, and checking with the experts, I have found that using Code Access Security (CAS) is a no-go when it comes to crossing distributed boundaries.
Last week, I was looking at CAS and Enterprise Services (ES) and found that it wasn't easy to transfer the forms-authentication information from a Partial Trust ASP.NET application through a COMPlus/ES middle-tier simply because of the need to translate .Net roles into COMPlus roles.
This week, I have been looking at CAS with .Net Remoting and have found similar results. In particular, I was looking at setting up an HTTP Channel with a Binary Formatter, allowing ASP.NET to host my server object. In this article, I found the following:
When objects are hosted by ASP.NET and the HTTP channel is used for communication, the client can be authenticated and authorization can be controlled by the following mechanisms:
That sounds great until I realized this is for the client-side ONLY. A little later, I read in another location something that stopped me in my tracks:
Note IPrincipal objects do not flow across .NET Remoting boundaries.
This means that CAS will only work on one side of the fence or the other (client-side or server-side). In some ways that makes sense that you can't transfer the client security frame to the server security frame, but it is still disappointing that I will need to develop a “home-grown” solution to deal with security:
There are two ways to flow the caller's context:
What does this mean for distributed applications on this side of Indigo? It appears that we are still stuck with ad-hoc security when it comes to crossing distributed boundaries. That would apply, it seems, to both Forms Clients and ASP.NET clients. You can use CAS on the client side, but at the boundary, you would have to figure out some way to pass the secure credentials and do the right checks on your own.