> 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 and we're trying to use
the uk federation. I thought the shibb to athens gateway was in the fed?
The lockin is wrt the gateway. We can't use the fed as all settings are
tied to the gateway. Accessing digimap via the federation has no real
value over the gateway. The users still use the same login creds but the
gateway route has their settings. 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.
I'm just frustrated by what seems like a lack of user support. 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. As far as users are concerned, all that's
changed is a URL.
IMHO middleware should never bleed this far into user land.
Alistair
--
mov eax,1
mov ebx,0
int 80h
> Alistair Young wrote:
>
>> It's a classic case of vendor lockin. Those users who have been
>> accessing [an SP that uses ePTI] via the shibb to athens gateway
>> are now locked into that.
>
> My previous message was written from the SP's perspective (whether
> it should offer an application feature, account linking, that would
> help dig customers out of the lock-in).
>
>>From an institution's perspective though, what you say above is
> true, and a good reason for an institution to think long and hard
> before deciding to use the Athens to Shibboleth gateway (or any other
> outsourced IdP) for access to services. Quoting from footnote 9 at
> section 7.1.1 of the UK federation's Technical Recommendations
> for Participants:
>
> "Migrating from one identity provider is not simple even when
> the scope can remain unchanged: in particular, values of
> eduPersonTargetedID are relative to the issuing entity,
> and would become invalid after any such migration without
> significant co-ordination between identity providers and
> service providers."
>
> Fiona.
>
|