Re: upcoming features in IIS filter?

[Jarod Malestein <jarod@xxxxxxxxx>]

AllowUnauthenticatedAccess is in the current build of IISCosign and will be 
included in the 1.1.0 release.  I should be able to get a release candidate 
out for testing by tomorrow.

First, realize that if you continue to use the current 
<Protected>/Foo</Protected> format that IISCosign will behave as it does 
now.  The default for allowUnauthN is FALSE.  That is the current behavior 
of IISCosign.

By setting allowUnauthN to TRUE you can specify parts of your web site that 
can be viewed by both cosign-authenticated and unauthenticated users.  This 
makes it possible for web pages to be be customized for those who are 
authenticated and dispay a generic page for those who are not authenticated.

If you have a portion of your web site protected as follows:

<Protected allowUnauthenticatedAccess="TRUE">/Foo</Protected>

Users who access https://my.web.edu/Foo (and are not logged in or have 
expired cookies) will NOT be redirected to your weblogin server.  However, 
if the user is logged in then the HTTP_REMOTE_USER and HTTP_REMOTE_REALMS 
server variables will be made available.  HTTP_COSIGN_SERVICE will be made 
available in both cases.

Please ignore <RequireAuthN />.  This is a temporary fix to an issue we 
were facing at U of M.  The behavior that results from ReqAuthN will be 
made available in the next major release of IISCosign.  (Basically, it was 
easier to add this feature rather than have a department rewrite major 
portions of their very expansive web site.)   That behavior is to act more 
like the Apache module mod_cosign.  In mod_cosign admins are able to turn 
on cosign protected /foo then turn it off for /foo/bar then, optionally, 
back on for /foo/bar/goo.  This ON-OFF-ON alternating protection mechanism 
is not available for IISCosign currently.  That is, if you have /foo 
protected then /foo/bar and /foo/bar/goo will also be protected.

This becomes more complicated when you don't want to allowUnauthN on /foo, 
but you do on /foo/bar.  ReqAuthN overrides some of IISCosign's default 
behavior, but it IS NOT RECOMMENDED THAT YOU USE REQAUTHN!  The alternating 
Apache-style cosign-protection will be implemented and ReqAuthN will 
eventually be deprecated.

--Jarod Malestein
--University of Michigan
--ITCS


--On Thursday, September 09, 2004 11:25 AM -0400 Phil Pishioneri 
<pgp@xxxxxxx> wrote:

> Can anyone give more details on these new parameters for a future version
> of the IIS ISAPI filter?
>
> > You can now specify allowUnauthenticatedAccess to <Protected/> pages.
> > example:
> > <Protected allowUnauthenticatedAccess="TRUE">/MySweetWebApp</Protected>
>
>
> and
>
> > Added <RequireAuthN/> option. This was added because the IISCosign dll
> > does not follow the Apache rules of specifying cosign authentication.
>
>
> -Phil