Robert Hurlbut Blog

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:

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