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 COM+/ES middle-tier simply because of the need to translate .Net roles into COM+ 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:

• 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.  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:

• Pass default credentials and use Kerberos authentication (and delegation). This approach requires that you impersonate within the ASP.NET Web application and configure the remote object proxy with DefaultCredentials obtained from the impersonated caller's security context.
• Pass explicit credentials and use Basic or Forms authentication. This approach does not require impersonation within the ASP.NET Web application. Instead, you programmatically configure the remote object proxy with explicit credentials obtained from either, server variables (with Basic authentication), or HTML form fields (with Forms authentication) that are available to the Web application. With Basic or Forms authentication, the username and password are available to the server in clear text.

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.

<Personal>

Following up on previous posts about having to move out of our home, we finally moved into our new home yesterday.

We moved into a 5-bedroom house with room to have a 6th bedroom as well as extra family-room.  I finally have a home office as well as everyone in the family having plenty of room to live.  As you may recall, we couldn't find anyone to rent to us or find a house to buy.  One of the houses we looked at previously decided they wanted to go with the rent-to-own deal, and contacted us and gave us a much better deal than we originally drafted.  So, we are now in a much better place than the fallback house we thought we would have to live (it was a cramp 4-bedroom house that had no potential for growth).

Thanks to all for your encouragement and support during this difficult time for my family.

Regarding my earlier question about .Net and ES/COM+ security, I found this older article from the MSDN docs that describe the relationship:

Sam mentions his COM Interop article series has begun on MSDN.  The first installment “Has Anyone Seen the Bridge?” gives an overview of why bridges are needed between the COM world and the managed (.Net) world.  I had the pleasure of seeing some early drafts, and I know this will be very helpful to many developers who have wrestled with COM Interop.

As Sam told us at work, the title of his first article is part of a famous song.  Your guess?

UPDATE:  Even today, at work, someone was having problems with their first COM Interop app crashing, and used Sam's article with the Marshal.ReleaseComObject call information to fix the problem.

I have been immersed in Code Access Security (CAS) this weekend as we ramp up .Net security for an ASP.Net/Enterprise Services (ES) project.

This book Improving Web Application Security: Threats and Countermeasures, among others, has been my resource.  Also, John Lam's work a couple of months ago has been very helpful as well.

One design I am looking at is setting up ASP.Net pages with Partial Trust (this is only allowed in 1.1).  In order to call Fully Trusted GAC-installed ES/COM+ components by Partially Trusted ASP.Net pages, I have to use a sandbox wrapper component that is also installed in the GAC with Full Trust, but with the AllowPartiallyTrustedCallersAttribute. 

The one item I m wondering about is how to transfer security-roles created using Forms Authentication to the ES/COM+ roles-based security?   According to docs, I know that in 1.0, the security stack is not transfered to ES when the thread switches, but I am not sure about 1.1.  That means, to me, I have to re-translate the custom roles from ASP.Net into NT Group Roles created for COM+ security.  Any ideas from anyone on this?

Andrew Gray mentioned his own work with Rotor and FreeBSD 5.1:

I had a look at building Rotor on FreeBSD 5.1 recently. I resolved some issues, but did not get it working.
The following newsgroup posting (linked above) includes a patch for the things I resolved and some notes on the unresolved issues.

Even though Andrew was not able to get Rotor working on FreeBSD 5.1, these are some great notes about problems he resolved as well as a good starting point to the next phase of research.  Thanks Andrew!

I have been setting up FreeBSD 5.1 under Virtual PC tonight, so I am heading that way myself.  More to follow ...

After seeing the news about RedHat Linux discontinuing all support for versions 7-8 and 9, Andrew and I have been wondering about our Rotor/Linux port.  Does it make sense to continue our RedHat Linux/Rotor research when RedHat is dropping all support?  We have both learned a lot from the the Linux port, so it is not for loss.

For now, I will be looking at porting (or patching, really) tests of Rotor on the BSDs.  In particular FreeBSD 5.1 (as I mentioned previously) as well as the latest flavor of OpenBSD.

Andrew is looking more at porting to a new OS other than Linux.  I also am very interested in this as well, and I know we will continue to learn from each other and share notes as we learn more about the internals of the CLR and how best to port/patch Rotor.

Regarding OpenBSD, this DevelopMentor [DOTNET-ROTOR] list entry a year ago points to an attempt to compile Rotor on OpenBSD that failed because of the lack of dladdr, that is required by Rotor.  I am wondering if the situation has changed?  Time for some research ...

Update:  I noticed that the above entry was written by Eric Albert, who just completed the Panther patch this past weekend.  I wonder if he has done some more research on OpenBSD since a year ago?

Update2:  In my comments, Eric is encouraging us to look at other Linux versions, not just RedHat, for a kernel port of Rotor.  Andrew and I agree, that we should do an about-face now and still look at the Linux kernel.