Okay, here's what we ended up with - an HTTPModule to handle the AuthorizeRequest Event.  This allows us to leave the app's Path-Based Authorization in place and maps it to Umbraco's virtual paths - seems to work as expected but, as always, comments are appreciated.  Drop the following into a class, compile to an assembly and register via <httpModules> in web.config:

using System.Web;
using System.Security;
using System.Web.Security;

    // add this snippet to web.config to hook up the httpModule
    //  <httpModules>
    //  <add name="AuthorizeEventHandler" type="MotusConnect.HttpModule.AuthorizeEventHandler" />
    //  </httpModules>

namespace MotusConnect.HttpModule
{
    public class AuthorizeEventHandler : IHttpModule
    {
        public AuthorizeEventHandler() { }

        public void Dispose() { }

        public void Init(HttpApplication context)
        {
            context.AuthorizeRequest +=new System.EventHandler(context_AuthorizeRequest);
        }

        private void context_AuthorizeRequest(object sender, System.EventArgs e)
        {
            // check roles here and allow access or redirect
            HttpApplication app = (HttpApplication)sender;
            HttpContext context = (HttpContext)app.Context;

            if (app.User.Identity.Name == null)
            {
                // redirect to login
                context.Response.Redirect(FormsAuthentication.LoginUrl);
            }
        
            // get required role for current page, if there is one
            bool allowed = false;

            if (SiteMap.CurrentNode != null)
            {
                foreach (string role in SiteMap.CurrentNode.Roles)
                {
                    if ((context.User.IsInRole(role)) || (role == "*"))
                    {
                        // ye shall pass if you are the right role
                        allowed = true;
                    }
                }

                // or not if you don't have the right role, no page for you
                if (!allowed)
                {
                    // redirect to login
                    context.Response.Redirect(FormsAuthentication.LoginUrl);
                }
            }

            // you're in!
        }
    }
}

-Paul

Hi Paul,

This is the same technique I used once to deny / reject requests based on IP addresses. Only the IP addresses in a certain 'white list' were able to access specific content. Never came a cross any problems.

The way you use it, seems like a good implementation, even more because it pluggable into any other .NET solution.

Greets,

Gerben

Hi both!

I know this post is old but I am hoping someone is still looking at it or at least someone who see's this knows about it!

I am new to this type of thing but I think it's what I need but I'm not sure!

I want to add a new check to the authentication process when a user visits a page.
It needs to still check if the users user group is allowed to access the page but then I also want to check an entirely separate table that has userIds against nodeIds.
This table contains temporary permissions that particular users have for particular pages (nodes), so if a user isn't in a role that has permission for a page I want to see if they have been given specific permission against that page in my table.

So my question is, if  create a module like you have will I be able to do this extra check in the context_AuthorizeRequest procedure? 
Will the standard role based authentication still work or do I have to add that into this procedure too? (I'm not sure if this completely overrides it?)

Any advice would be greatly appreciated!

Bex

is working on a reply...