210 likes | 384 Views
InCommon as Infrastructure: How Recommended Practices and Federation Features Help Scale Federated Identity Management. Michael R. Gettes, Carnegie Mellon University Renee Shuey , The Pennsylvania State University Internet2 Member Meeting, October 1, 2012. RL “ Bob ” Morgan.
E N D
InCommon as Infrastructure: How Recommended Practices and Federation Features Help Scale Federated Identity Management Michael R. Gettes, Carnegie Mellon University Renee Shuey, The Pennsylvania State University Internet2 Member Meeting, October 1, 2012
Current/Active Practices and Federation Features • Emerging Practices, trends and ideas • Future issues
Current/Active Practices • Assurance • Bronze/Silver • Contracts • Attribute Release • Easing integration • Categories • Metadata • Timely data • Keys, endpoints & tigers, oh my! • eduPerson Schema
Assurance • Virginia Tech has achieved Bronze & Silver! • Many institutions currently working towards Bronze & Silver • If Silver is too soon for you – consider Bronze! • POP vs. Bronze • www.incommon.org/assurance
Contracts • University of California and University of Texas language at www.incommon.org/working_sp.html • Carnegie Mellon and Penn State specify software interoperability (work with Shib IdP, not just specify SAML) and require joining InCommon. Of course, not everyone joins. Language varies.
Attribute Release • Develop a simple default attribute release policy with maximal coverage (CMU policy next slide). • InCommon is creating categories of services to help IdP and SP operators determine attribute requirements. • Research & Scholarship Category • https://spaces.internet2.edu/x/-IKVAQ
Attribute Release • While a security principal is supposed to be just a security principal – with cloud integrations we see more usage of email addresses as principals – this is unfortunate. • Having eduPersonPrincipalName (ePPN) happen to be a working, reliable email address eases cloud integrations • Ensuring ePPN to be non-reassigned also eases cloud integrations. Use eduPersonTargetedID where possible.
Metadata Until metadata is no longer distributed via files… • Describes all Fed Entities (Identity & Service Providers) • Timely metadata update is important! • Pay attention to strong keys (2048 keys) in MD • Quickly moving to all endpoints via SSL (don’t forget the InCommon Certificate Service!!!) • MD is transforming to provide UI hints, error handling & other benefits effecting operations and user experience.GOOD METADATA IS IMPORTANT!
Metadata Growth Fed Software developers and Federation Operators need to begin addressing this problem space. since SMM-2012 IdPs, 14% growth SPs, 13% growth
eduPerson Schema • eduPerson started as an LDAP schema but its practicality has exceeded LDAP. Now used as lingua-franca for R&E app integrations. • Pay close attention to this schema to aid with attribute release issues and ease application integrations. • Consider referencing of eduPerson schema in contracts
Emerging Practices and Tools • Repository of software and pointers to tools • Federated Error Handling • Federated Security Incident Response • Delegated Admin for InCommon
Repository • InCommon Ops committing to GITHUB soon: • SAML2JSON translator • Smart Web User Agent (smart_get) • SAML Metadata Cert Parser • SAML Entity Probe • SAML2AttributeFilterPolicy XSLT script for R&S • Web page coming. Community contributions encouraged.
Federated Error Handling • Guidance at https://spaces.internet2.edu/x/xa6KAQ • 3 sites in R&S already using FEH • (PSU wikispaces, OSU carmenwiki, i2 filesender) • Did you know there is FEH service? • https://spaces.internet2.edu/x/kJOVAQ • https://ds.incommon.org/FEH/
Federated Security Incident Response • See https://spaces.internet2.edu/x/8o6KAQ • Origins from CIC Id Mgmt Task Force • Federated identity introduces new challenges for security incident response. Federation participants should consider the impact of federated identity in their incident response practices and treat federated identity partners impacted by a security incident in a similar manner as they would local parties.
Delegated Admin for InCommon • Metadata mgmt needs to scale. DA is critical to make this possible. • Distribute the mgmt for MDUI, LoA, descriptive info per SP, Federated Error Handling. • Easily allows InCommon as local federation • Supports federated access, of course. • http://www.incommon.org/v/da_demo/
CMU – Profile • Spring 2011: deployed IdP, begin using InCommon as local federation. • Summer 2011: Default attribute release policy • Fall 2012: 117 SPs, 2 IdPs. > 75% all authNs now federated. 150 old pubcookie sites to go. • Up take was fairly quick. • Will decommit pubcookie summer 2013. • Sept 2012: > 1M SSO events – google analytics
In Summary • The more successful is InCommon, the greater the benefit of InCommon to all of us. • Knowing other participants operate well increases the trust among us. • We must express how we operate (metadata) • We need to share our methods, tools and policies so we may help/learn from our selves. • So why don’t we all put our SPs into InCommon?