Hi Andy,
given the importance of persistent IDs for personalisation, we decided
long ago to use a database to store them once generated, as our users
move around the organisation and changing rules to follow them is
prolly more annoying than generating once and storing in a persistent
store.
There are technologies that can make the persistent store transparent,
such as an embedded database like Derby which can run inside the IdP
with no extra administration other than a one time config file and
should ideally be mostly invisible to the sysadmins. As it runs inside
the IdP there's no network connectivity to worry about and it gets
backed up with the IdP.
I can't speak for that particular IdP but that's what's available in
other IdPs. The embedded database is only used by the IdP so doesn't
need as full blown an infrastructure as MySQL or Postgres. If the IdP
supports an embedded database it could soften the blow of adoption.
Alistair
--
mov eax,1
mov ebx,0
int 80h
On 11 Mar 2010, at 13:29, Andy Swiffin wrote:
> 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?
|