RE: [aus-dotnet] Permission coding


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
    • From: Corneliu I. Tusnea
    • Subject: RE: [aus-dotnet] Permission coding
    • Date: Thu, 10 Jan 2008 11:06:11 -0800

    Dylan,

     

    You might have seen that in my presentation at CodeCamp or TechEd on security where I was talking also about a nicer approach:

    [PrincipalPermission(SecurityAction.Demand, Role="Manager")]

    This is a nice way of defining roles required however the concept is not that useful in smart clients applications as you can use a tool like Hawkeye (http://www.acorns.com.au/projects/hawkeye) to change the reported roles on the fly and all your tests (these ones or the ones with IsInRole) become useless.

     

    For a smart client it’s very important to realize that this type of role checks should only be used for usability purposes and not for security.

    You should be aware that any check that you do it’s easy to modify either at runtime (see Hawkeye) or by modifying the assemblies (decompilation/recompilation).

     

    Regards,

    Corneliu I. Tusnea
    Readify | Senior Consultant

    M: +61 410 835 593 | C: corneliu.tusnea@xxxxxxxxxxx

    PPlease consider your environmental responsibility before printing this e-mail

    From: peter@xxxxxxxxxxx [mailto:peter@xxxxxxxxxxx] On Behalf Of Tusler, Dylan
    Sent: Thursday, 10 January 2008 4:39 PM
    To: dotnet@xxxxxxxxxxx
    Subject: RE: [aus-dotnet] Permission coding

     

    I remember doing some really exciting stuff around this topic on the advanced .NET course at Readify.

     

    Unfortunately I don't have my notes at hand, but I'm sure somebody out there will know what I'm talking about...

     

    Dylan.

     

     


    From: peter@xxxxxxxxxxx [mailto:peter@xxxxxxxxxxx] On Behalf Of Greg Keogh
    Sent: Thursday, 10 January 2008 10:42 AM
    To: dotnet@xxxxxxxxxxx
    Subject: [aus-dotnet] Permission coding

    Warning: Email may contain offensive content. You are advised not to view email or attachments unless sent from a known and trusted source.

     

    Folks,

     

    I have previously fallen into the coding trap where your project becomes littered with permission checking code like this:

     

    if (IsInRole("Customer"))

    {

      panelThing.Visible = true;

      labelOther.Text = "Some other message".

    }

     

    As an app grows, this sort of tedious code can get out of control, and I want to find a better way of doing this.

    CAB uses Action Catalogs for this sort of thing, but I never got around to using them due the clumsiness of implementing them. They seem to use policy injection techniques internally, but I haven’t tried to unravel how they do it to steal the idea.

     

    Has anyone fiddled in this sort of coding area? I’m going to run some webs searches on ‘injection security declarative’ keywords to see what turns up.

     

    Cheers,

    Greg

    Get the latest Council news delivered to your desktop.

    Subscribe to eFocus, Maroochy Council's free online newsletter: http://tinyurl.com/3cb9tz

    ======================================================
    The
    contents of this message may express views and opinions not necessarily shared by Maroochy Shire Council. This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed.

    Maroochy Shire Council is a government organisation and is subject to Freedom of Information legislation. You must assume that any material sent to Maroochy Shire Council may be monitored and may be accessible by persons other than the intended recipient.
    =======================================================
    Note: Maroochy Shire Council does not accept vulnerable file types such as executables via email.
    Emails must be in English and under 10MB.
    mscmail 5.2.10

     




    (Click here for more information on the aus-dotnet mailling list)