 |
 |
The Shibboleth developers have been discussing this and are very much aware of the issues associated with requiring a database for deployment at any scale of deployment other that the very largest. The Shibboleth team are unwilling to ever commit to code until it has been written and proven, but currently there is a plan which will not require a database for IdP deployment (indeed I would say that for as far as I am concerned this is a non-goal). My personal view is that there is no reason to assume that this plan or a derivative cannot and will not be delivered upon. ComputedID is going away, but the function it currently provides (including backwards compatibility from 1.3) will still be there one way of another and no databases will be assumed. Further, part of the "next major release" story is that tools will be provided to seamlessly move from the current version of configuration to future versions (so moving and IdP from 2.x to 3.x will be only marginally more difficult than moving from 2.x.y to 2.x.z). Apologies for the delayed follow-up, we wanted a chance to discuss this face to face. Rod > -----Original Message----- > From: Discussion list for Shibboleth developments [mailto:JISC- > [log in to unmask]] On Behalf Of Andy Swiffin > Sent: 11 March 2010 13:30 > To: [log in to unmask] > Subject: Computed ID - will be removed at the next major shib release > > Hi, > > When I migrated to Shibboleth 2 I looked briefly at the Stored ID data > connector as a source for targetted/persistent ID generation before rejecting > it in favour of continuing with computed ID. > > The additional complexity of adding a database to the shibboleth mix seemed > unwarranted for what we would gain. I had noted that the documentation for > computed ID for shib 2 said at the start (in red, after a no entry symbol) > "This data connector is deprecated. The stored ID data connector should be > used instead." But like all of us I had a job to get done (amongst many > others) and needed to get the migration to shib 2 sorted. > > The rather strong use of deprecated continued to nag at me and in a discussion > with someone else about their Shib 2 migration it came up again very recently > so I thought I'd ask on the Internet 2 list why the word was used and what was > the problem with continuing to use computedID. > > I received a quick response from Chad La Joie to say: > > " that word was used because that's the exact > status of that plugin. It will be removed in the next major release of > the IdP. > ... > In addition, the next major release of the IdP will incorporate > attribute release consent functionality (i.e. uApprove) which will also > require a database." > > > While I think the (optional) addition of uApprove type functionality is a good > thing, to make the deployment of a database an obligatory part of an IdP may > well raise the complexity ( perceived or actual ? ) to the point where some > people will just not adopt it. Having been involved in encouraging other, > perhaps smaller and less well staffed, institutions to deploy their own IdP I > am only too aware of how daunting a task it can appear. > > I am wondering what other people think of this? > > I, myself, am quite happy to use computed ID, I see no need to have a database > tied in as well with the IdP here. > > Regards > Andy Swiffin > > > ************************************************************ > Please consider the environment. Do you really need to print this email?