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