securing pages/access without using auth module

[alex.net]

Hello! I'm new to sitepoint, so I apologize if I'm asking something which has recently been asked.

I am developing a .NET website which I'll describe in Microsoft terms. There is varying content that can be any of the following:

• publicly exposed to unauthenticated users
• viewable by only authorized users
• post-able by users of role A
• deletable by users of roles A & B

I establish this protection by limiting access to pages which expose the above functionality.

All this is fine and dandy in a model that uses various .NET modules - but I'd like to implement this functionality myself. The explanation as to "why" is too long, but to summarize: this is a practice project for me and my team consists of bunch of .NET-skeptical PHP developers that demand all my code be short, concise, and written by me rather than "automagically" generated by Microsoft.

So I've come here to find some people smarter than me to tell me if what I'm doing is legitimate or riddled with flaws!

Skipping my SQL stuff and login code for now, I have made some code to secure a page from being viewed by the wrong user. My login code verifies username/pw and assigns the user to a UserGroup (analogous to Microsoft "roles"). From there the securing of a page is handled by the following::

public static class Protection
{
    //restricts to a certain usergroup, or if usergroup is "anyone" only checks for login
    public static void RestrictTo(UserGroup ugroup)
    {
        if ((bool)HttpContext.Current.Session["loggedin"] == false)
        {
            HttpContext.Current.Response.Redirect("~/Login.aspx");
        }
        else
        {
            //if its anyone...
            if (ugroup == UserGroup.Anyone)
            {
                //then we do nothing, we're good to go and access is granted
            }
            //if its a specific user group
            else if ((UserGroup)HttpContext.Current.Session["group"] != ugroup)
            {
                //if they're not that group take them to the root
                HttpContext.Current.Response.Redirect("~/");
                //todo: maybe take them somewhere else more specific
            }
        }
    }

    public enum UserGroup
    {
        Phpdev,
        Netdev,
        Administrator,
        Anyone
    }
}

the above code is then called as follows:

    protected void Page_Load(object sender, EventArgs e)
    {
        //restricts the page to just admins
        Protection.RestrictTo(Protection.UserGroup.Administrator);
    }

or

    protected void Page_Load(object sender, EventArgs e)
    {
        //restricts the page to anyone who is logged in, regardless of UserGroup
        //users who are not logged-in will be redirected to login.aspx
        Protection.RestrictTo(Protection.UserGroup.Anyone);
    }

What do you think? The code appears to do what I want in my test environment, but I'm fairly new to web-programming and would love some feedback. What are some other ways people do what I've done while steering clear of modules/custom modules?

Thanks for reading

[wwb_99]

While I understand the impetus, I would use the underlying bits of the framework's security model at least. Those underlying bits being the IPrincipal and IIdentity interfaces. It will be much cleaner and allow you to much more easily push the security below the Web UI layer where it belongs.

Longer term thing is that if you continue to make code like php developers in .NET you will end up having some significant issues. They are very different environments and you can't make one behave like the other.

[alex.net]

I would like to use existing framework, if i can keep it very very slim. I just don't want to write custom providers to sync up with my data and end up with an app that behaves more slowly than the one I have now.

Can I push the security out of the web UI layer without the following:

1. MembershipProvider
2. RoleProvider
3. Interfacing w/ some form of authentication that inserts objects into sessions

As it stands currently I have some tidy code for data access, email , encryption, pagination, etc and I've gone to the global.asax to write session_start variables. Its all very slim & modular, plus my PHP devs can read it. I would need a strong cause to justify remolding my existing features according to Microsoft coding practices (I am however quite opening to hearing reasons why I should in this case! Microsoft fails to to sway me in their MSDN writing). The alternative to which I am also open is some form of modular implementation of the framework in a way that it can help me with just this authorization feature without turning on too many extra features. Then I can keep all my other code.

Can you tell me more about how to push the security out of the UI layer?

[honeymonster]

By using the ASP.NET security infrastructure you allow for declarative access control. That is superior to programmatic white-list security which you must remember to put on each page. With declarative security you can secure a file, a directory or an entire site and override it at each level. For instance, you can make a the /admin directory only accessible by users who has the Admin role.

That's out of the UI layer, into one single or seperate distributed web.config. Best practice.

Need more reasons?

[wwb_99]

Well, the basics of authentication are tied deep into the ASP.NET stack and don't require "turning on" anything. Your PHP devs need to get past the "reading everything" fetish.