Windows Forms Control Hosted in IE

[James]

Hi,

I have built a Windows Form Control which is hosted in IE (for our
Intranet). The form logs into a Web Service and retrieves information for
display. However, because the web service is on a different internal server,
we get the error message: "Error in document service. "Request for the
permission of type 'System.Net.WebPermission' failed". We have got this to
work on development machines by raising the trust level of the machine
hosting the webservice - but how do we do this for the clients on the rest
of the domain?

Has anyone seen this before... and if so, and more importantly... can you
suggest how to fix the problem?

We are running Framwework 2.0 and ASP.NET 2.0.

Thanks in advance,
James

 

[Nicole Calinoiu]

There are several options available for deploying CAS policy modifications
over a domain. See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/entsecpoladmin.asp
for some pointers.

 

[James]

There are several options available for deploying CAS policy modifications
over a domain. See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/entsecpoladmin.asp
for some pointers.

Thanks Nicole, so you think that this is simply a policy setting - not that
I should be coding the app differently?

Thanks
James

 

[Nicole Calinoiu]

You cannot elevate the assembly's permissions from within its own code. The
only code change you could make that would remove the requirement for the
additional CAS permissions is one that alters the application's behaviour so
that it no longer needs any permissions besides those granted to the zone
from which it will run (presumably the intranet zone in your case). If
connecting to a web service on a different web site is a fixed and
unavoidable requirement for the control, then I don't see how you can avoid
the additional permissions requirement. That said, moving the web service
(or at least a pass-through facade for the existing web service) to the
control host site would be an obvious approach to consider, but nothing
you've mentioned so far indicates whether that's an option that's available
to you...

 

[James]

You cannot elevate the assembly's permissions from within its own code.
The only code change you could make that would remove the requirement for
the additional CAS permissions is one that alters the application's
behaviour so that it no longer needs any permissions besides those granted
to the zone from which it will run (presumably the intranet zone in your
case). If connecting to a web service on a different web site is a fixed
and unavoidable requirement for the control, then I don't see how you can
avoid the additional permissions requirement. That said, moving the web
service (or at least a pass-through facade for the existing web service)
to the control host site would be an obvious approach to consider, but
nothing you've mentioned so far indicates whether that's an option that's
available to you...

Hi Nicole,

We spent this morning trying out your suggestion... It Works!

We raised the permissions for our domain to Full Trust for Intranet based
assemblies. Everything now runs perfectly.

Thanks very much for taking the time to answer my post, it is sincerely
appreciated.

James

 

[Nicole Calinoiu]

You might want to consider making the additional permission grant a bit more
restrictive, both with respect to code group membership and the granted
permission set. Granting unrestricted permissions to all code originating
on any network (even an intranet) leaves client machines open to additional
risk that could easily be avoided. For example, in your particular
scenario, it might be quite sufficient to grant only one additional
permission (WebPermission to connect to the target web service address) over
the baseline intranet grant, and you could probably be quite restrictive
about the code group membership criteria that are used to grant this
additional permissions. For example, on top of intranet zone evidence, you
could probably use URL evidence corresponding to your control's URL and
strong name and/or publisher evidence corrresponding to strong name and/or
authenticode signatures applied to the control assembly.