This post originated from an RSS feed registered with .NET Buzz
by Sam Gentile.
Original Post: Code Access Security - No with ES/COM+, Remoting, Distributed Applications
Feed Title: Sam Gentile's Blog
Feed URL: http://samgentile.com/blog/Rss.aspx
Feed Description: .NET and Software Development from an experienced perspective - .NET/CLR, Rotor, Interop, MC+/C++, COM+, ES, Mac OS X, Extreme Programming and More!
Robert details our intense last week of architecture design and redesign. Basically, as we were detailing last week, the CAS security thread is dropped at the ES boundary. We were finding issues enough with the ES implementation of COM+ - suffice it to say that the ES design has not been well thought out IMHO and seems to be a managed wrapper slapped over COM+ incurring performance overhead with one unmanaged transition thunk (while cleverly avoiding another) as well as ES Roles != CAS .NET Security Roles! All this stuff will change and work with Indigo but we need a solution now. Since we are not using 98% of COM+/ES features and have a very small amount of distributed TX anyhow, I made an architectural decision to move to .NET Remoting as we just need to get from one box to another (multiple boxes with multiple tiers) and seperate off the Distributed TX stuff in a much smaller assembly of its own using ES. The hope was that somehow the CAS security thread flowed across Remotiong boundaries. It doesn't.
This week, we have been looking at CAS with .Net Remoting and have found similar results. In particular, we were looking at setting up an HTTP Channel with a Binary Formatter, allow ASP.NET to host my server object. In this article, we 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:
URL authorization
File authorization
Principal permission demands (declarative and imperative)
IPrincipal.IsInRole checks in code
That sounds great until I realized this is for the client-side ONLY.
As Robert says “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.“
Thats what it is. We have our homegrown method of serializing the credentials from an ASP.NET forms based authentication into a encrypted string or byte and passing it as a parameter in our calls down the layers. Ingo verified all this in our IM Chat this morning. CAS only appears to be useful if you have a standalone client calling other .NET assemblies on the same box. How useful is that in a distributed world that .NET is supposed to be geared for? I have zero apps that fit that criteria. This is a major inconvenience and waiting for Indigo is not the helpful answer right now.
Previous Topic
