Re: Adjusting security setting to run an embedded windows control in IE
From: Joe Kaplan \(MVP - ADSI\) (joseph.e.kaplan_at_removethis.accenture.com)
Date: 01/30/04
- Next message: Greg Busby: "Using Windows Integrated Security for Windows form application"
- Previous message: SYoung: "web.config - for multiple applications"
- In reply to: Crirus: "Re: Adjusting security setting to run an embedded windows control in IE"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 30 Jan 2004 14:39:29 -0600
I'm not an expect at all in Java applet security, but I do know that the
.NET CAS model is very different.
Essentially, code is sorted into membership of different code groups based
on evidence it presents to the system. Evidence can be things like the URL
it came from, it's strong name, etc. Based on the code groups it is put
into, it will be granted certain permissions.
Thus in your example, your code is presenting some evidence that gets it
included in a certain code group that is not granted the permission it needs
to run. In order to fix this, you probably need to either:
- Get your code to fall into a code group that has the permissions you need
- Modify the local security policy on the machine to ensure that some
evidence you can present will get you into a code group with the correct
permissions
As I was poking around in the default security policy, it looked to me that
the Trusted_Zone code group gets special permission to connect back to its
site of origin. Do you know if IE is finding your site to be in Trusted
Sites? If so, based on what I can see you should be getting the permission
you need.
If that won't work, then you might need to modify the local security policy.
You could use a URL membership condition or perhaps a strong name.
Joe K.
"Crirus" <Crirus@datagroup.ro> wrote in message
news:%23PculYw5DHA.1052@TK2MSFTNGP12.phx.gbl...
> This is the scenario:
> Clinet open the browser, access my server, receive a client app, embedded
in
> IE that start running. Now, the client app need webPermission to connect
> back to the same server and request some data...
>
> My question is if this is allowed, I see no reason why I cant request data
> from my own server with my own client application... Any java applet can
do
> that
>
> Java only restrict the acces to server on the same port 80 from where it
was
> first downloaded
>
> I'm kinda lost in the woods with this permissions...
> So, do the client need to set some permisions? The permission I need is
> WebPermission but i'm not sure how it works...
>
>
>
>
> --
> Cheers,
> Crirus
>
> ------------------------------
> If work were a good thing, the boss would take it all from you
>
> ------------------------------
>
> "Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote
> in message news:uL%23ooJq5DHA.3308@TK2MSFTNGP11.phx.gbl...
> > Assuming that the code will not execute given the permissions it is
> getting
> > in the zone it is running in, I'm pretty sure you aren't going to get
this
> > to work without changing some kind of security permissions on the
client.
> >
> > The reason is that if that code isn't granted the permission to do what
it
> > needs to do, there is no way for the code to get around that. .NET
> security
> > policy is administered on the local machine. The idea is that the
> > administrator gets to decide which resources get which permissions.
Then,
> > code is allowed to execute automatically with the permissions it is
given.
> > This is very different from the downloadable ActiveX control model which
> > asks the user for permission to install and run and then can do anything
> the
> > user has permissions to do on their machine.
> >
> > Are you sure you can't make adjustments to the client machine security
> > policy? Are you sure the permission you need isn't already granted to
the
> > zone that the code executes in?
> >
> > Joe K.
> >
> > "Crirus" <Crirus@datagroup.ro> wrote in message
> > news:eCh%23IUm5DHA.2560@TK2MSFTNGP09.phx.gbl...
> > > I have a application, embedded in IE (html assambly).
> > > That aplication need to connect back to the server in order to get
some
> > > data.
> > > What are conditions to succeed without requesting any special
> permissions
> > > from client? As an applet do it....
> > > Should I connect back to the server only using port 80?
> > > Right now the client app is serverd by Apache and connection back is
> tryed
> > > to another aplication on port 9500
> > >
> > > Changing security permission by the client is not an option
> > >
> > > --
> > > Cheers,
> > > Crirus
> > >
> > > ------------------------------
> > > If work were a good thing, the boss would take it all from you
> > >
> > > ------------------------------
> > >
> > > "Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com>
> wrote
> > > in message news:OUVp7Zb5DHA.2764@TK2MSFTNGP09.phx.gbl...
> > > > The best way to do this is to give just the assemblies that need
Full
> > > Trust
> > > > that permission.
> > > >
> > > > The reason it doesn't work in your situation is that when IE creates
> the
> > > > AppDomain that it runs your code in, that AppDomain is created based
> on
> > > the
> > > > URL which will have some sort of partial trust (unless that URL or
the
> > > whole
> > > > zone has been given Full Trust).
> > > >
> > > > Two things happen after that:
> > > > - If your assembly is not marked with the
> > > > AllowPartiallyTrustedCallersAttribute, the partially trusted
AppDomain
> > > that
> > > > it is running in will not be able to call it.
> > > > - Any code that requires a permission will hit your assembly, where
> it
> > > will
> > > > be granted due to your Full Trust, but will likely fail when the
stack
> > > gets
> > > > up to the partially trusted AppDomain since the AppDomain may not
have
> > > that
> > > > permission.
> > > >
> > > > You have basically two options to solve this:
> > > > - Make the AppDomain have Full Trust with something like a URL
> > membership
> > > > condition. This is the easiest thing to do, but is not very secure,
> > > > especially if the URL is not very specific.
> > > > - Add the AllowPartiallyTrustedCallersAttribute and use Assert on
the
> > > > Permissions that you need when you need them to prevent the stack
walk
> > > into
> > > > the containing AppDomain. This is more work, but is vastly more
> secure
> > > and
> > > > is the recommended approach.
> > > >
> > > > There have been some good articles on implementing the second
> approach.
> > I
> > > > believe Ivan Medvedev has some good info on his website. You might
> > start
> > > > there:
> > > > http://www.dotnetthis.com/Articles/WritingForSEE.htm
> > > >
> > > > Joe K.
> > > >
> > > > "Marina" <someone@nospam.com> wrote in message
> > > > news:Os5oCLb5DHA.2572@TK2MSFTNGP09.phx.gbl...
> > > > > Hi,
> > > > >
> > > > > I am trying to find the minimum security settings to allow a
windows
> > > > control
> > > > > embedded in IE have full trust.
> > > > >
> > > > > If I give the entire Intranet zone full trust, this works.
However,
> > this
> > > > is
> > > > > very broad and gives the entire zone high privleges.
> > > > >
> > > > > I tried giving just the assembly full trust (using the full URL
for
> > the
> > > > > DLL), but this doesn't seem to work.
> > > > >
> > > > > Any direction in how to accomplish this?
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
- Next message: Greg Busby: "Using Windows Integrated Security for Windows form application"
- Previous message: SYoung: "web.config - for multiple applications"
- In reply to: Crirus: "Re: Adjusting security setting to run an embedded windows control in IE"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
