Alistair Young wrote:
> Previously they
> were all behind the same SP entityID (shibboleth to athens gateway).
This is of course one reason why *any* gateway is a less than optimal
solution from an architectural point of view; you don't know which of
the things beyond it you're really talking to.
> If
> we move to the federation and access RefWorks direct, the entityID will
> change, as will eduPersonTargetedId value and the users will lose all
> their settings.
Two points here, one related to the summary I gave in a parallel reply:
there's nothing stopping you (if you feel like coding it) from regarding
a directly-accessed RefWorks SAML entity as part of the group of service
providers represented by the Athens gateway SP's entity name.
That's a bad approach in the long run because the whole point of ePTI is
to provide privacy by not handing the same identifier to multiple SPs.
However, it's possible to consider doing something like this during a
transition. After all, you're already handing the same ePTI value to
*every Athens DSP* if you access them through the gateway: which is to
say, it's not really targeted at all for you right now.
The second point is that I'm not in any case sure that the ePTI that you
issue to the Athens gateway SP is being passed to the RefWorks Athens
DSP in such a way that even if you sent the same ePTI to it in its new
role as a SAML SP it would be able to recognise that the same value was
involved. That would presumably depend on both the Athens DSP protocols
and the RefWorks application. Does anyone who knows the Athens gateway
protocols at that level of depth like to hazard a guess?
-- Ian
|