Print

Print


Actually, there is updated information available at

http://www.it.ufl.edu/identity/shibboleth/shibboleth.asp

As I understand it, the it.ufl.edu/project page is no longer the  
current location for information about the Shibboleth service.
The project is completed and now the service is running on an  
operational basis.

Regards,

Christine Schoaff
President, Academic and Professional Assembly
Director, UF Web Administration



On Apr 8, 2009, at 10:04 AM, Randy Switt wrote:

> Notes inline:
>
>> -----Original Message-----
>> From: UF Web types [mailto:[log in to unmask]] On Behalf Of
>> Mark Brackett
>> Sent: Wednesday, April 08, 2009 9:32 AM
>> To: [log in to unmask]
>> Subject: Re: ASP .NET Example For OBTAIN PERSON LOAF
>>
>> My *understanding* is that Shibboleth only covers the logged in use
>> case
>> - getting info for a another user would fall out if it's scope. Also,
>> the info you get would be subject to the appropriate Attribute  
>> Release
>> Policies, which may or may not be the same as your current Directory
>> access.
>
> This is true, Shibboleth only returns information about the logged  
> in user,
> you would need to use other internal connections to query other user  
> info.
> Otherwise you can certainly coordinate your Attribute Release  
> Policies to
> match your needs, assuming they are approved.  I was going to respond
> similarly to Joe initially, but then it did occur to me that  
> Shibboleth
> doesn't cover all the info that PERSON LOAF does.  It's certainly  
> feasible
> to *use* Shibboleth to authenticate access to the PERSON LOAF info,  
> but
> that's not what the original question was.
>
>> My *impression* is that Shibboleth @ UF has stalled - I haven't  
>> seen or
>> heard anything new since the "Gatorlink Is Dead" presentation  
>> sometime
>> last year (of course, I haven't been actively looking either).
>
> Not true, though I'd agree that there could be more communication.   
> I hadn't
> heard much either, but I managed to ferret out the documentation,  
> fill out
> the appropriate forms, get approval for a couple of Service  
> Providers, and
> roll out my first Shibbolized application last week.   The forms and
> approval process were the most time consuming, once done the install  
> and
> configuration were pretty painless.
>
>> As for simplifying - I suppose that's a matter of opinion. From my
>> perusal of Shibboleth documentation, I personally wouldn't call
>> /implementing/ it simple - though using it may be. It strikes me as a
>> whole lot of complication surrounding federation - which we don't  
>> plan
>> to make use of. Last I checked, there was no IIS7/managed code module
>> either - while not necessary, my experience with open source ISAPI
>> modules makes me wary of the unmanaged one (even though I haven't
>> actually used it).
>
> Implementation was simple other than the initial xml configuration  
> file
> setup was a bit inscrutable (mostly because I was implementing  
> multiple
> providers).  Martin Smith over at CNS was able to walk me through it  
> without
> too much difficulty though.  He indicated that they may be offering  
> either
> more assistance with that in the future, or providing pre-written XML
> configurations for new implementers.  Most of the federation  
> complication
> seems to be at the infrastructure level, which we don't have to deal  
> with.
>
> Good point about IIS7 though, I'm using IIS6 which is directly  
> supported, so
> I didn't notice the more problematic IIS7 support.  I don't know if  
> anyone
> involved in supporting Shibboleth can speak to this.
>
>> Either way, there are certainly uses for the DB2 Directory (at least,
>> for my department) that have little or nothing to do with web
>> authentication.
>
> Yes, though I did want to chime in as an implementer and note that
> Shibboleth is not *dead* or stalled, but just under publicized ;-).
>
> Randy S.