Skip to Content.
Sympa Menu

shibboleth-dev - RE: TargetedID Durability

Subject: Shibboleth Developers

List archive

RE: TargetedID Durability


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: TargetedID Durability
  • Date: Mon, 1 Aug 2005 11:04:05 -0400
  • Organization: The Ohio State University

> I've heard a somewhat related use case from commercial info providers
> who work in the medical space -- a significant portion of their
> customer base moves from one site to another, especially during their
> early training days. When Jane moves from hospital A to hospital B,
> the SP would like Jane to be able to associate her new identity (as
> represented by whatever attributes the two hospitals are releasing)
> with her existing profile at the SP --
>
> if it were only the SP that cared about this, perhaps I wouldn't be
> very concerned. But, the SP argues that in fact the doctors (or
> doctors in training) very much want this capability....
>
> I can imagine a number of different ways to do this -- is there a
> SAML-2 flow that supports this use case?

No, not unless the user is already federated at both IdPs with the SP. Then
you could map between them, but at that point you don't need to, since the
SP would already have federated the user with IdP2.

I think you'd have to address this kind of thing administratively via bulk
federation, or just by forcing the user to manually federate.

Stop me before I use federate as a verb again...

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page