Re: Changing AppDomain.CurrentDomain Principal

From: Joe Kaplan (ilearnedthisthehardway_at_noway.com)
Date: 05/22/03

  • Next message: J-P Meunier: "Re: Compute XML Signature on external Xml document" 
    Date: Wed, 21 May 2003 23:24:24 -0500

    This is interesting. I wasn't aware of this limitation. I can think of a
    couple of things that might work:

     - Kill the current AppDomain and start a new one. Then, restart your
    application in the new AppDomain. This obviously makes things more complex
    though.
     - Redesign your custom principal so that you can change the identity and
    roles associated with it, but leave the current instance attached.
     - Set the principal on the current thread directly. This might get
    complicated in a multithreaded app though. I imagine this is allowed as
    ASP.NET sets the principal on each request thread to the current logged on
    user, but there is only one AppDomain (normally) in a web app.

    Any other ideas?

    Good luck,

    Joe K.

    "Daren May" <daren.getrid.may@spirent.com> wrote in message
    news:uEavL69HDHA.3804@tk2msftngp13.phx.gbl...
    > I have managed to confuse myself trying to solve the following problem:
    >
    > I have an application that stores user accounts (and passwords) in a
    > database. I have created custom IPrincipal and IIdentity implementations
    > which seem to work fine, i.e. I can call:
    >
    > MyPrincipal mp = MyPrincipal.ValidateLogin(userID, password);
    > AppDomain.CurrentDomain.SetThreadPrincipal(mp);
    >
    > MessageBox.Show("Current Principal: " +
    > Thread.CurrentPrincipal.Identity.Name.ToString());
    >
    > Which displays the correct Name value.
    >
    > However, my requirements state that a user must be able to logoff and
    logon
    > as another account (lets avoid a debate why... I am hoarse from the
    > "discussion" already... suffice to say, the requirement isn't changing).
    > Now as the Help docs state, you cannot use SetThreadPrincipal more than
    once
    > (nice exception) and you can send a null (again, nice exception).
    >
    > So, I am confused on how to change the user and associated permissions.
    > Should I be changing the Identity within the Principal, then reloading the
    > Permissions?
    >
    > TIA
    >
    > Daren
    >
    >

  • Next message: J-P Meunier: "Re: Compute XML Signature on external Xml document"

    Relevant Pages

    • Re: HTML embbeded (via <object> tag) Strong FullTrust Assemblies f
      ... > to the appdomain's permissions. ... > appdomain will now allow my assembly full access. ... you add a new code group under the ... You seem to be mixing up the .NET Framework security policy and the IE ...
      (microsoft.public.dotnet.framework.aspnet.security)
    • Re: security/strong name/zones clarification needed
      ... Was this also true in the Intranet Zone? ... >child code-group with full permissions granted to any ... >> needs to host the CLR, it creates an AppDomain, but due ... All my assemblies are strong named. ...
      (microsoft.public.dotnet.security)
    • Re: security/strong name/zones clarification needed
      ... > this AppDomain needs to be setup before your assembly can be loaded, ... > Your assembly will have enough permissions, ... When the call stack is initiated, ... All my assemblies are strong named. ...
      (microsoft.public.dotnet.security)
    • Re: security/strong name/zones clarification needed
      ... several but not publicly documented) about child code-group permissions ... a strong-name, or Authenticode signature evidence. ... This problem would also crop up in the AppDomain case also. ... All my assemblies are strong named. ...
      (microsoft.public.dotnet.security)
    • Re: security/strong name/zones clarification needed
      ... Either you can assign DNS permissions to your site on each client computer ... > this security permissions exceptions fired up? ... >> this AppDomain needs to be setup before your assembly can be loaded, ... All my assemblies are strong named. ...
      (microsoft.public.dotnet.security)