Shibboleth Developers

At 4:41 PM -0500 11/14/03, Scott Cantor wrote:
>  > 1) support for htaccess-style access control. This would allow the
> >  local  administrator to create access control policy, on a per
> >  directory basis. Directives  would be similar to/the  same  as those
> >  supported by the apache version of the shibboleth target. The rules
>
> I believe the goal here should be compatibility with Apache .htaccess files.
>
>  > would be maintained using a) a text editor? or b) some sort of new
> >  GUI tool?. The policy file for a directory (the set of rules) would
> >  be stored as a text file in the directory itself. One result of this
> >  work would be the ability to create rules granting access to uses who
> >  are NOT in the local AD.
>
> We need to be careful talking about AD...I think it's out of scope to even
> address integration with the standard IIS security model or shadow accounts
> (the way MIT-based authn works in Windows). That may mean .NET is also
> impossible to address.

I'd agree 100% -- that at this point, we want to steer VERY clear of 
the standard IIS model, and the other "best practice" model. I 
mentioned AD in order to (begin to) differentiate our htaccess based 
approach from the standard approach -- did I end up just confusing 
the issue?

> >  2) Integrate support for managing the shib configuration into the
> >  standard IIS management GUI. Currently, the Shib target configuration
> >  files are managed by editing text files. The config directives still
> >  have to be stored in text files. But, we'd like some BLAH (is modules
> >  the right word?) that plug into the IIS management console, would
> >  behave consistently with the other management console plugins, and
> >  would allow a sysadmin to manage the Shib target config.
>
> The main options here are:
>
> - a stand-alone GUI that just helps manage the Shib/IIS config data
> - a library and property pages that implement the IIS management COM
> interfaces, appearing within the IIS console, possibly also storing some
> config data in the IIS metabase

I think I've heard option 2  mentioned more often that option one 
...not that a lot of people experience here, or have expressed 
opinions.....

> >  3) Improved installer package. (specifics?)
>
> The additional work would be doing web server configuration stuff during
> install and possibly prompting for more information, generating keys/certs,
> etc. I would say we need this just as much on Unix too.
>
> >  5) dynamic content  (eg a  library to be used from asp). -- Actually,
> >  should we ask the shib-users list about this one -- what would they
> >  want? And try to measure how strongly people feel about needing this?
>
> This is a similar set of issues to the Java target, but with the difference
> that we could probably slap COM interfaces on what we have and it would
> connect to ASP. Still need to address, IMHO, whether lazy session startup
> would be enough for 90% of these cases. The big argument seems to be that
> getting a site to install a filter isn't always possible.

I suspect we'd also have to provide access to an RM engine of some 
sort... even if its crude....