SlideServe
Menu
Préférences
© SlideServe · v2026

Understanding Federated Identity Management in Indiana CTSI

steven-bowman avatar
7 diapositives · 166 Views · Nov 20, 2014

Learn about federated identity management, its benefits, implementations, and implications for users accessing data across domains. Explore InCommon and OpenID federations and their operational mechanisms in the Indiana CTSI environment.

Understanding Federated Identity Management in Indiana CTSI - slide 1
01 / 7Understanding Federated Identity Management in Indiana CTSI
1 / 17

Télécharger la présentation

Understanding Federated Identity Management in Indiana CTSI
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation
  1. F Id M Federated Identity Management at the Indiana CTSI Bill Barnett (barnettw@iu.edu) Anurag Shankar (ashankar@iu.edu)

  2. What are Federated Identities? “Federated identity, or the ‘federation’ of identity, describes the technologies, standards and use-cases that serve to enable the portability of identity information across otherwise autonomous security domains. The ultimate goal of identity federation is to enable users of one domain to securely access data or systems of another domain seamlessly, and without the need for completely redundant user administration.” (Wikipedia - http://en.wikipedia.org/wiki/Federated_identity).

  3. Why Should I Care? • Single sign-on access to multiple resources, including federated resources • Allows the management of multi-institutional trust relationships • Standard being adopted by NIH (ctsaweb.org) and federally (grants.gov) for authentication • A foundation for access to secure data, including HIPAA • Could POTENTIALLY disambiguate individuals (?)

  4. What Federations Are Out There? • InCommon (www.incommonfederation.org): 95 higher education participants, 6 agencies (inc. NIH), 33 corporate partners – as of March 30, 2009. Institutionally managed identities. • OpenID (www.openid.net): Supported by ISPs (Google, Yahoo, AOL) and other service providers (eg., Blogger, LiveJournal, WordPress). Self-asserted identities. There is no conflict between these. We support both on the IndianaCTSI HUB

  5. How Does It Work? • Based on the Security Assertion Markup Language (SAML) • Resource Providers (RPs) manage identities and Service Providers (SPs) provide services. The Indiana CTSI is a SP, but Indiana University is the RP because they manage the login credentials. • Authentication happens via the Shibboleth authentication framework.

  6. How Does It REALLY Work? • You attempt to login to a Service Provider (SP) application that supports Shibboleth authentication • That application transfers you to your institutional RP for authentication • Your institutional RP sends back a SAML assertion that delivers your personal attributes that are accepted by the SP to provide you with access to the SP services

  7. What Are (some of) The Issues? • All applications have to support Shibboleth authentication • Authentication provides NO authorization. That must be handled separately • You have to negotiate federation relationships for each institution individually, based on the trust relationship you have with that institution • Personal attributes delivered are controlled by each RP and be as little as an assertion only that this person belongs to the RP’s institution • For collaborative activities and for authorization to use private (eg., HIPAA) data, some personal attributes need to be exchanged