Native IIS7+ module/filter

Description

Not a 2.6.0 thing, but never created an issue for this.

One of the main design parameters for this is to try and avoid the configuration hell the current design creates in IIS, see if we can support server variables in place of headers, and if we're really feeling our oats look at POST preservation.

Environment

None

Activity

Show:

Rod Widdowson September 25, 2017 at 10:33 AM

Declaring this done.

I'll promote the two remaining subtasks (code reveiw and re-test) back up to real ones

Rod Widdowson April 25, 2017 at 12:34 PM

this might be relevant. Its protected by a modified BSD3 license so for now I'm not going any further than reading the license and stopping. But it does appear to be an existence proof that you can do claims based AuthZ

Rod Widdowson April 25, 2017 at 12:30 PM

Another day another random walk through the problem space.

I have determined that the IHttpUser.IsInRole method can be called from standard IIS URL AuthN. In my experiment I arranged for all Shibboleth Authorized users to get a principal which said "true" in response to IsInRole("ShibUser"). I then set up URI Authorization as per the documentation (turn it on in programs and features) and configured it (from IISMgr) to protect my virtual dir unless you you are a member of that group.Hey presto one gets access if logged in and not if not.

In order for this to work one needs to have configured Shib to do the AuthZ (the AuthN happens at a later stage in the pipeline). This is actually how I tested it (I made the area under the IISN AuthN wider than the <Path> which has requireSession="true" on.)

By turning the debugger to be "Mixed" you get to see the entire stack at is swaps between native and managed code (4 times in this case) and the managed stack givces an insight into hat is going on. Even better a quick search yielded this site which in turn led me to download of the C'# code that IIS uses and thus establish that there appears to be no calls made to GetUserVariable (which is a shame).

My next nature study will be into the nature of Claims based AuthN. Of course (as seems to be the usual case when I go head to head with an MS API) the documentation describes how to use, not how to provide the building blocks, but if they've broken it down correctly the Claims AuthN should be separate from the code (in ADFS or wherever) that provides the claims.

Rod Widdowson April 24, 2017 at 4:04 PM

Pushed current version which has optional <Site> and new <IIS> configuration (which is where I put the useHeaders/useVariables stuff for now.

I may poke around the IHttpUser and membership to see if we can get anything cool out of it, but the largest substantive new item left is installation which I may look at but not checkin before mid-May

Rod Widdowson April 20, 2017 at 2:17 PM

I've cleaned up the code and moved it over to the real repo as 86add3b.

I'll not push (and this make this sticky for life) for a bit longer. I'll do some more development locally but in the main line and if that all looks OK I'll push this this weekend,

Fixed
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Components

Fix versions

Created April 28, 2016 at 5:53 PM
Updated August 2, 2018 at 3:13 PM
Resolved September 25, 2017 at 10:33 AM