Child pages
  • Advanced Federation
Skip to end of metadata
Go to start of metadata
  • Scenario 1: a fairly standard federation layout in a healthcare setting, with the added complication of HIPAA.
    • Multiple IdPs and a single SP. Need to match the users in the IdPs for audit purposes.
    • A use case close to this is covered in the OpenAM FR-420 training.
    • In these scenarios, you could decide between pushing the identities to the SP and letting the individual orgs add and remove users in the SP, or, the individual orgs manage the identities and the SP trusts the assertions the org's IdP makes.
  • Scenario 2: separate systems in US and EU, customer manages the IdP, administrator owns  the SP. There is a global load balancer that directs users to US or EU systems. But they are not allowed to replicate the data.
    • You could have a landing page in front of SP, they enter their email, if can find it in the local SP, then great. If not, do a REST call to the other system to see if they know who the user is.
    • Replicating is obviously the other way to do it, but it's not allowed in this case. And the personally identifiable info gets very complicated across borders.
  • Scenario 3: IdP is OpenAM, controlled by the speaker. Want to integrate with SalesForce and a hosted app there, but the app on SF uses protected services (APIs) owned  by the speaker.
    • Using OpenID Connect to most of this now, but running  into problems.
    • Could turn OpenAM into and IdP and an SP, which would solve it.
  • Scenario 4: in order to maintain privacy, a government has an IdP that is the main citizen login page. A bunch of agencies act as SPs. When they generate an assertion, they have a unique identifier for the user, per SP. This avoids leaking data between the agencies. But now want a 'tell government once' option for users to make changes across systems. Have created a translation service to abstract the user tokens that the SP can use to effect the change. But UMA can make this much simpler. 
  • No labels