Shibboleth Developers

["Mark Wilcox" <>]

Java Servlet also support the notion of "forms" authentication similar to
ASP. 

I totally forgot (most people still roll their own due to inconsistencies in
implementations) until I read down the thread.

Mark

-----Original Message-----
From: Michael A. Grady 
[mailto:]
 
Sent: Monday, November 17, 2003 6:51 PM
To: 

Cc: 

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

One of my staff (Dale Sinder) has put together a presentation on a
recommended approach to incorporating our local WebISO (Bluestem) into
the .NET environment -- he is in fact presenting this in a couple of
days at a conference day we host for campus computer support professionals.
I asked him to put it somewhere that folks on this mailing list could
get to:

   http://staffdb.cites.uiuc.edu/Bluestem.NET
   
The approach pretty much aligns with Howard's suggested approach below
for Shibboleth with .NET.
   
>From: "Howard Gilbert" 
><>
>To: 
><>
>Subject: RE: Work items, next W2K+ target package
>Date: Mon, 17 Nov 2003 14:09:19 -0500
>X-YaleITSMailFilter: Version 1.1d (attachment(s) not renamed)
>X-Loop: 
>
>X-no-archive: yes
>List-Id: <shibboleth-dev.internet2.edu>
>List-Help: 
><mailto:?subject=help>
>List-Archive: <https://mail.internet2.edu/wws/arc/shibboleth-dev>
>
>
>
>> 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.

 
--
Michael A. Grady                               217.244.1253 
Senior Technology Architect and Strategist     217.265.5635 fax
Manager, Integration and Software Engineering
Campus Information Technologies and Educational Services (CITES)
University of Illinois at Urbana-Champaign
Rm. 103, 2212 Fox Drive, Suite C, Champaign, IL 61820