 |
 |
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