1. 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

2. RL “Bob” Morgan

3. Current/Active Practices and Federation Features Emerging Practices, trends and ideas Future issues

4. Current/Active Practices Assurance – Bronze/Silver Contracts Attribute Release – Easing integration – Categories Metadata – Timely data – Keys, endpoints & tigers, oh my! eduPerson Schema

5. 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

6. 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.

7. 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

8. Carnegie Mellon Attribute Release

9. 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.

10. 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!

11. Metadata Growth Fed Software developers and Federation Operators need to begin addressing this problem space. since SMM-2012 IdPs, 14% growth SPs, 13% growth

12. 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

13. Emerging Practices and Tools Repository of software and pointers to tools Federated Error Handling Federated Security Incident Response Delegated Admin for InCommon

14. 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.

15. 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/

16. FEH Service Example

17. 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.

18. 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/

19. 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

21. 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?