thanks Dom.
It seems it's possible to share the value of eduPersonTargetedId among
a group of SPs. So perhaps the way to maintain "state" across access
methods is to share it among the Shibboleth to Athens gateway and
RefWorks, ScienceDirect etc. Sharing it should provide a migration
bridge from Athens to the Fed. Only testing will tell. I'll get on to
RefWorks and get us added to their WAYF. Ah but they're not in the
federation!
Alistair
On 25 Jan 2008, at 10:32, Dominic Benson wrote:
> Alistair,
>
> I take the point you are making but, FYI, RefWorks users should be
> able
> to log on with an individual RW username, password and group code,
> issued by email when they registered. Their data can, therefore, be
> backed up from an Athens account and restored to a Shibbed profile.
>
> In the case of ScienceDirect this can't be done, so alerts can't be
> migrated. Elsevier prefers that the institution to contact them so
> that
> Elsevier can deactivate the old user profiles (that's if you don't
> intend to run both Athens and Shibboleth signons side by side). This
> is
> the advice I received when we migrated from Classic Athens to
> AthensDA...
>
> --ooOoo--
>
> <<Technically, ScienceDirect and Scopus do not handle AthensDA
> differently from classic Athens - so the fact that you are seeing an
> "Activate Athens User Name" screen is perfectly normal. Everybody that
> enters SD with a new Athens un/pw for the first time is required to
> register; this not different between classic Athens and AthensDA. It
> might be that other publisher websites do not require users to
> register
> when using Athens, but the fact is that SD does. For the same reason,
> both classic Athens and AthensDA provide remote access to SD. It is
> therefore not needed to register with ScienceDirect with a
> ScienceDirect
> username/password.
>
> You need to re-register after having moved from Athens to Athens DA
> because ScienceDirect thinks you are a completely new user (which is
> what you mean with "old profiles can not be migrated to the new
> profile"). This is a known issue. We have worked with Eduserv to
> inform
> customers about this, telling them that customers need to tell us when
> they move from Athens to AthensDA. Main reason for this is that we
> need
> to de-activate the old user profiles before the customer starts using
> AthensDA, in order to keep the alerts from old user profiles from
> continuing to be sent. We need to do that BEFORE customers migrate,
> and
> not after, because we cannot distinguish between old and new profiles.
>
> In your email you state that you will keep Classic Athens running
> along
> side Athens DA, in this case then there is nothing we can do about old
> Alerts apart from delete each old profile one by one on a request
> basis.>>
>
> --ooOoo--
>
> Warmest regards,
>
> Dom
> --
> [log in to unmask]
> Electronic Resources Librarian
>
>
> -----Original Message-----
> From: Discussion list for Shibboleth developments
> [mailto:[log in to unmask]] On Behalf Of Alistair Young
> Sent: 25 January 2008 10:11
> To: [log in to unmask]
> Subject: Personalised settings in the fed - can we take our Athens
> ones
> with us?
>
> Is there anyone on the list who has enough knowledge to answer a
> rather
> fundamental question, that could decide whether using the federation
> is
> worth the hassle? The basic problem is personalisation of resources
> and
> the attributes used to do so. eduPersonTargetedId is used through the
> shibb-athens gateway but it's specced to be different for each SP.
> RefWorks through the gateway and RefWorks through the fed are two
> separate SPs with different entityId (I presume), so the spec says
> they
> cannot share the value of ePTID, except in exceptional circumstances.
> I'd argue the exceptional circumstance of losing all your references
> from RefWiorks because you change the middleware is cause enough to
> keep
> ePTID constant across these two SPs.
>
> The bottom line is, if someone gets kicked off athens for not paying,
> all their users lose all their settings in RefWorks because the
> middleware has changed. The settings are still there, they just can't
> get access to them due to a combination of middleware specs and
> implementation changes.
>
> It's not possible for an admin to login to RefWorks and transfer
> settings between "accounts". So you end up with multiple sets of
> settings depending on how you accessed the resource.
>
> To me, that sounds a good enough reason not to switch to the
> federation,
> unless someone can allay these fears. Anyone fancy it?
>
> We were hoping to answer these Qs between now and 2011 but that's
> not an
> option any more. It feels like we're being asked to evacuate Athens,
> leave all our possessions behind and build a new life in Federation
> City.
>
> Alistair
>
>
> --------------
> mov eax,1
> mov ebx,0
> int 80h
--------------
mov eax,1
mov ebx,0
int 80h
|