Hello UF Web Managers,

Indeed, Shibboleth adoption is not stalled, but in fact has been
picking up in the past few months. I've been setting up 1-2 users
a week for the last few weeks, and we have 20+ users in various
states of production and testing. I'd expect there to be another
Shibboleth event in the coming months, too.

I'd encourage you to join the SHIBBOLETH-L open discussion list
(send an email with "subscribe shibboleth-l" to
[log in to unmask]) so that all of the current Shibboleth
users and us, too, can benefit from the discussion.

I'll reply inline (below) to some of the concerns raised. Thanks
for the discussion & interest in Shibboleth!

Martin B. Smith
[log in to unmask] - (352) 273-1374
CNS/Open Systems Group
University of Florida

-- snip, replies inline --

On Wed Apr 08 10:04:37 EDT 2009, Randy Switt <[log in to unmask]>
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.

That's correct. Shibboleth is meant to solve a particular problem
-- moving all of the different services that handle user
credentials into a single point of signon. In fact, we prefer that
data from Shibboleth was used only for user authentication and
keying users to sessions, but not saved for reports or other uses.
If you need enterprise/directory information for users that aren't
logged in, you'll need to get it from another source than
Shibboleth.

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

Yes, Shibboleth is definitely not stalled. We're delighted to be
getting multiple new users of the service every week. All of the
new SP folks have been great to work with, and I'd encourage other
folks that might be interested to give it a test.

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

I think you'll find the IIS6 ISAPI filter is quite usable, and
we'd work with you to overcome any problems in the IIS7 ISAPI
filter as well. More feedback to the developers of the filter is
the best way for us to get improvements on it, though they say it
currently *does* work.

We'd like to make it as easy as possible for folks to use the
Shibboleth service, so we'd always welcome feedback too, to make
it easier for people to adopt.

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

Thanks for the CC, Randy :)