Shibboleth Developers

["Howard Gilbert" <>]

> do we have consensus, then, around a short-term strategy of 
> developing the COM component described above?

A COM solution appears to be necessary if we are to support classic
interpreted ASP scripts. There may also be some advantage to using logic in
a COM component over C logic in an ISAPI filter (because of the difficulty
of developing and debugging ISAPI).

However, if you only consider the new ASP.NET environment of the .NET
Framework, then a much more elegant solution presents itself. Classic IIS
only supported Windows Authentication for accounts in AD. ASP.NET provides
for Application-Managed authentication for principals that are not in the
domain based on application defined roles.

This can be implemented by declaring that an application (virtual directory)
is managed by Forms Authentication. Then the authentication (redirection to
the SHIRE, wait for the return, call to the SHAR) is done by a logon "page"
which is really a module written in some combination of managed languages
(C#, J#, VB, ...). We could supply a sample page that redirects the initial
request, waits for the return from the SHIRE, obtains the attributes from
the SHAR, and uses them to construct the .NET objects. Alternately, the same
thing could be done by an HttpModule (filter).

An anonymous request is represented by a GenericPrincipal object that
contains no roles and is marked anonymous. You create a new
GenericPrincipal, assign it application defined roles based on the
attributes, and put a reference to it in the Thread.CurrentPrincipal
pointer.

Neither we nor Microsoft define what a "role" is. They like to think about
"Manager" as a role, and we obviously think about "Student" or "Faculty".
However, if this is being done as application code in the "logon page"
logic, then we can supply some obvious examples and the application designer
can refine them.

Of course, access control still depends on someone applying logic to use the
roles to define permissions. That may be up to the application designer. We
could provide some sample code and let the administrator or application
programmer pick up the ball from there.

This is elegant within the context of ASP.NET because Shibboleth really is
an example of Forms Authentication. Instead of using a SQL database, as most
Microsoft examples of Forms Authentication, it uses the Federation and a
network protocol to perform the same function.

If this is not an interesting official product of the Shibboleth project, it
is still something that someone ought to do and make available externally.