CoSign: Collaborative Single Sign-On  
AnnouncementsDiscussion
 

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 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









 
Copyright © 2002 - 2004 Regents of the University of Michigan :  Page last updated 15-December-2010