thanks Fiona. Eduserve were going to send me details of how they generate
a persistent ID from EPTI, which they then give to the resources behind
the gateway. If the value is different for each resource then there's a
chance we can "migrate" the settings from Athens to the fed by
implementing those rules against our EPTI for those providers who have
settings "locked-in".

It's still at the hand waving stage but AFAIK the resources, such as
Digimap, key settings against the munged value of EPTI they get from the
gateway. Theorising for a moment, that would suggest that if we gave
Digimap the same value of EPTI when accesing it via the fed, then the
settings will still be accessible. All we need are the munging rules,
which we can then implement in our IdP. It might work, it might be pie in
the sky(e) but I'm waiting to get the details of the munging rules.

Hopefully it'll all come out in the wash.

cheers,

Alistair


-- 
mov eax,1
mov ebx,0
int 80h

>> > and a good reason for an institution to think long and hard
>> > before deciding to use the Athens to Shibboleth gateway
>>
>> we don't. We use the Shibboleth to Athens gateway
>
> Sorry, I misread that previously as Athens to Shibboleth.
> Your case is even clearer unfortunately though.
>
>> and we're trying to use the uk federation.
>
> Directly from your Shibboleth IdP, yes?
>
>> I thought the shibb to athens gateway was in the fed?
>
> Unfortunately not.  Eduserv collect their own metadata about IdPs that
> sign up to use the Shibboleth to Athens gateway, which effectively
> forms its own private Athens federation, distinct from the UK federation.
>
>> The lockin is wrt the gateway.
>
> Absolutely.  From the perspective of (say) Digimap, when one of
> your users logs in via the Shibboleth to Athens gateway, they are
> logging in as an Athens user, using the Athens protocol stack,
> just as if they were using a classic Athens account or AthensDA
> (your Shibboleth IdP is acting here as an Athens local authentication
> system, effectively an equivalent to the instiutional component of
> AthensDA).  No Shibboleth protocols are involved at the Athens DSP
> (note, not Shibboleth SP) at all.
>
>> We can't use the fed as all settings are tied to the gateway.
>
> You can't use Athens and the federation indistinguishably, back and
> forth, for personalised services.
>
>> Accessing digimap via the federation has no real value over the gateway.
>
> Both routes are available for the moment.  It's up to you to decide
> which option makes most sense for you.
>
>> The users still use the same login creds but the gateway route
>> has their settings.
>
> That's right.  So if you want to migrate users of personalised
> applications from Athens to the federation, you will either need
> to get the users to migrate their settings or persuade every one
> of those service providers to implement account linking in their
> applications (and then train the users to link the old and new
> accounts).
>
>> The fed route is empty and they have to start again and Edina are
>> quite happy for them to start again but they're not.
>
> "Happy" is perhaps too strong.
>
>> I'm just frustrated by what seems like a lack of user support.
>
> That's what I'm trying to do just now.
>
>> The fed is being promoted as best practice for federated access
>> management but those of us who took up the offer of the halfway
>> house of the shibb to athens gateway are now in a bad place.
>
> The Shibboleth to Athens gateway was usually presented only as a
> transitional crutch to enable sites moving to federated access
> to continue temporarily to access not-yet-Shibbolized Athens resources.
>
> In any case it is not really a halfway house: a user of the Shibboleth
> to Athens gateway is as much a 100% Athens user as someone with a
> classic Athens account or AthensDA.
>
>> As far as users are concerned, all that's changed is a URL.
>
> Unfortunately you are in a position where you need to look at this
> from an implementation perspective as well as the user perspective.
>
>> IMHO middleware should never bleed this far into user land.
>
> That is certainly an admirable goal.
>
> Fiona.
>