IIS Policy Agent does more than Injecting Headers

I haven’t touch base around Policy agent in my last blog while introducing ForgeRock components but Policy Agent is kind a part of OpenAM itself.

Policy agent is a traffic inspector which intercepts each incoming request to your web server and check whether user is allowed to access the URL or not. If the URL is configured as a secured URL then Policy agent intercepts that request and sends the user to OpenAM login page. User is then authenticated here and then sent back to the original request he/she was trying to access. Below picture sort of depicts what I am trying to explain here. (Image downloaded from Google)

Policy Agent is also capable of injecting headers in the request as well for authenticated users. The headers can contain attributes which application can use to setup user session. Policy agents come in different flavors depending upon what type of application and web server you have. You can have IIS Policy agent, Apache or J2EE.

Theoretically, you should be able to use any above your application as all Policy agent has to do is to intercept traffic and send users to login page when required but recently I learned something interesting, IIS Policy agent over .Net application does not only intercepts the traffic and inject headers, it does also set the security context of the user in the application after which if you check Request.IsAuthenticated attribute in your app, it will return as true the same doesn’t happen with Apache Policy agent.

So let’s just check two scenarios below.

First, I have an Asp.Net application written protected by IIS Policy agent on my local IIS. The app has no custom code written in it but it just prints the header values & values of some security context variables.

See below what it prints post login from OpenAM. The value in Green is the OpenAM Cookie. The values in Blue are my headers but the values in Red are surprisingly all True.  IIS Policy agent post authentication sets the identity in WindowsPrincipal & GenericPrincipal after which if you do Request.IsAuthenticated, it returns true.

In second scenario, we have the same application code hosted on a separate website in IIS which is now protected by Apache policy agent also running locally on my machine. When I try to access this site, Agent running on Apache send me to OpenAM login page where post authentication, I again lands on my application but notice the difference between the values in RED.

    Apache Policy agent is not setting the user identity in WindowsPrincipal or GenericPrincipal due to which, If I do Request.IsAuthenticated, it returns false even after successful login after OpenAM. That is something you don’t want in .Net applications after you log in.

    Ideally you shouldn’t be using Apache Policy agent for IIS websites as the security should be closed to your application but we only had to do because, OpenAM IIS policy agent is not capable of securing multiple websites on IIS and 4.0 they released which can do this has it’s own problems.

    Anyways, I still need to understand how IIS Policy agent sets this security context for the application and how can we mimic this behavior with Apache. Will share this as well when I will figure it out.