70 likes | 148 Views
F Id M. Federated Identity Management at the Indiana CTSI Bill Barnett ( barnettw@iu.edu ) Anurag Shankar ( ashankar@iu.edu ). What are Federated Identities?.
E N D
F Id M Federated Identity Management at the Indiana CTSI Bill Barnett (barnettw@iu.edu) Anurag Shankar (ashankar@iu.edu)
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).
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 (?)
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
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.
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
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