Skip to Content.
Sympa Menu

shibboleth-dev - RE: Work items, next W2K+ target package

Subject: Shibboleth Developers

List archive

RE: Work items, next W2K+ target package


Chronological Thread 
  • From: "Michael A. Grady" <>
  • To:
  • Cc:
  • Subject: RE: Work items, next W2K+ target package
  • Date: Mon, 17 Nov 2003 17:51:15 -0600 (CST)

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




Archive powered by MHonArc 2.6.16.

Top of Page