Disabling Glimpse on production and to glimpse.axd

Question

How can I limit access to glimpse.axd when deploying to production?

I am using a custom RuntimePolicy to ensure that glimpse is not enabled in production however I want to ensure that users do not get to the axd as well.

If we were using authorization from asp.net then I understand that i could protect via location path in web.config but this option is not available to me.

Ideas?

Chrysotile

Answer 1

Glimpse provides a few different mechanisms for security configuration.

The first, as you mentioned, is to leverage ASP.NET's built in security features. To do this, in your web.config you can add a <location> element, like this:

<location path="glimpse.axd">
  <system.web>
    <authorization>
      <deny users="*"/>
      <allow roles="Admin"/>
    </authorization>
  </system.web>
</location>

and now only users in the Admin role will be able to access Glimpse.axd.

Coincidentally, the path does not have to be /Glimpse.axd, this is just a default setting. You can move the HttpHandler's location to a url only known by you and your team by making a few changes to your web.config:

<!-- configure system.webServer and/or system.web depending on your ISS configuration -->
<system.webServer>
  <handlers>
    <add name="Glimpse" path="unknownLocation.axd" ... />
  </handlers>
</system.webServer>
<system.web>
  <httpHandlers>
    <add path="unknownLocation.axd" ... />
  </httpHandlers>
</system.web>

<!-- then just configure Glimpse -->
<glimpse defaultRuntimePolicy="On" endpointBaseUri="~/unknownLocation.axd">

The second approach is to create an IRuntimePolicy. Runtime policies can secure access to resources (which are served though Glimpse.axd) as long as you return RuntimeEvent.ExecuteResource from their ExecuteOn property. Unfortunately for you, Glimpse is designed to ignore the IRuntimePolicy's for requests to the default resource (which is Glimpse.axd). The good news is, you can change the default resource. Here's how:

1. Create or update a class so that it implements IServiceLocator.

2. Update your web.config to point Glimpse to your service locator implementation.

   <glimpse defaultRuntimePolicy="On" endpointBaseUri="~/Glimpse.axd" serviceLocatorType="YourNamespace.GlimpseLocator, YourAssembly">

3. Now Glimpse knows about your locator and will ask it for any type that it needs, including for the default resource.

4. Implement an IResource. I'll show an example of how to create one that just redirects the user to the normal config page (that is no longer the default resource), but you could have it do anything you'd like.
5. Now the calls directly to /Glimpse.axd?n=glimpse_config will respect all IRuntimePolicy's you have in place, and calls to Glimpse.axd redirect to there anyways.

Here's the code:

// Create the ServiceLocator that is referenced in web.config
public class GlimpseLocator : IServiceLocator
{
    public T GetInstance<T>() where T : class
    {
        if (typeof(T) == typeof(IResource))
            return new SecurityResource() as T;

        return null;
    }

    public ICollection<T> GetAllInstances<T>() where T : class
    {
        return null;
    }
}

//Implementation of new default resource that just redirects
public class SecurityResource : IResource
{
    public string Name 
    {
        get { return "Security"; }
    }

    public IEnumerable<ResourceParameterMetadata> Parameters 
    {
        get { return Enumerable.Empty<ResourceParameterMetadata>(); }
    }

    public IResourceResult Execute(IResourceContext context)
    {
        return new RedirectResourceResult("/Glimpse.axd?n=glimpse_config");
    }
}

// Your custom runtime policy
public class CustomPolicy : IRuntimePolicy
{
    public RuntimeEvent ExecuteOn 
    {
        get { return RuntimeEvent.ExecuteResource; }
    }

    public RuntimePolicy Execute(IRuntimePolicyContext policyContext)
    {
        //Perform any logic you like and return RuntimePolicy.On or RuntimePolicy.Off
        return RuntimePolicy.Off;
    }
}

Now, when users go to Glimpse.axd they get redirected to Glimpse.axd?n=glimpse_config which will either show the standard config page, or a *Runtime policy does not allow execution of resource named 'glimpse_config'.* message - depending on your IRuntimePolicy.

So, like I said, the use case we optimized for is the first, to leverage ASP.NET's built in security mechanisms. Glimpse is not tied to that model though, you just have to jump through a few hoops to configure it ATM.

On a related note, we are going to be greatly improving the configuration story in Glimpse 2.0, which is currently in process.

Capeskin

I'm looking at implementing the second option you outlined above to have a custom RuntimePolicy, but (I'm sure I'm missing something here) I can't get the actual edit page to come up. The Execute method on CustomPolicy doesn't seem to be getting fired. I get the redirect happening correctly to n=glimpse_config and the "Runtime policy does not allow execution of resource named 'glimpse_config'." message coming up but no matter what I put in the Execute method it still doesn't show up. Is it something I'm missing? It does breakpoint into ExecuteOn. – Pirbhai

We short circuit the evaluation of the policies once one says that Glimpse is Off. Check in the Glimpse log to find out which policy is disabling Glimpse. – Capeskin

Thank you, Nik. Just a thought: as for me it is easier to implement a custom HttpModule and make all the necessary permission check there. – Czarevna

Answer 2

Since Glimpse 1.7.0, they have added a better way to secure Glimpse.axd:

http://blog.getglimpse.com/2013/12/09/protect-glimpse-axd-with-your-custom-runtime-policy/

1. Uncomment the code in GlimpseSecurityPolicy.cs (added to your project when you do nuget)
2. Change httpContext.User.IsInRole("Administrator") to whatever logic is relevant for you

N.B. RuntimeEvent.ExecuteResource in ExecuteOn() ensures this logic is run when you request Glimpse.axd.

Censure

Answer 3

I don't have enough reputation to comment, but I thought it was necessary to save someone from the following mistake in nikmd23's thorough answer:

<location path="glimpse.axd">
  <system.web>
    <authorization>
      <deny users="*"/><------------
      <allow roles="Admin"/>
    </authorization>
  </system.web>
</location>

The arrow points to the issue that deny * will match all users before authorization even gets a chance to allow roles="admin". Reverse this order (as seen below) to reach the desired functionality.

reference: ASP.NET Forms Auth Allowing access to specific file in subdirectory when all others should be denied

<location path="glimpse.axd">
  <system.web>
    <authorization>
      <allow roles="Admin"/>
      <deny users="*"/>
    </authorization>
  </system.web>
</location>

Terni