cosign-discuss at umich.edu
general discussion of cosign development and deployment
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: upcoming features in IIS filter?
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
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:
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.
--University of Michigan
--On Thursday, September 09, 2004 11:25 AM -0400 Phil Pishioneri
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.
> <Protected allowUnauthenticatedAccess="TRUE">/MySweetWebApp</Protected>
> Added <RequireAuthN/> option. This was added because the IISCosign dll
> does not follow the Apache rules of specifying cosign authentication.