Shibboleth Developers

["Mark Wilcox" <>]

I think we need some clarification here on the MS side of the house because
on the server side of things ASP is the primary server tier for .NET (I'm
spending a lot of time these days working with .NET, though mostly on the
client end).

For Windows - we should probably be aiming at a short-term solution being a
COM component that provides the general Shib services as we're defining for
Java target. At a very high-level -- we pass the COM component an HTTP
session of some type (ie output stream, plus the HTTP request headers) and
it comes back with the Shib target stuff.

COM then provides the most flexibility for exposing Shib behavior to Windows
server applications -- IIS filters, old ASP, and .NET (aka ASPx which
defaults to VB.NET for language but can also use C#). While you should try
to avoid COM when programming with .NET (calling COM from .NET is a bit like
calling native code from Java, though much easier), it is definitely
possible.

Mark 


 


 



-----Original Message-----
From: 

 
[mailto:]
 
Sent: Friday, November 14, 2003 4:56 PM
To: 

Subject: RE: Work items, next W2K+ target package

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