In Common as Infrastructure How Recommended Practices and

In. Common 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 Internet 2 Member Meeting, October 1, 2012

RL “Bob” Morgan

• 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! • edu. Person 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 Id. P, not just specify SAML) and require joining In. Common. Of course, not everyone joins. Language varies.

Attribute Release • Develop a simple default attribute release policy with maximal coverage (CMU policy next slide). • In. Common is creating categories of services to help Id. P and SP operators determine attribute requirements. – Research & Scholarship Category • https: //spaces. internet 2. edu/x/-IKVAQ

Carnegie Mellon Attribute Release

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 edu. Person. Principal. Name (e. PPN) happen to be a working, reliable email address eases cloud integrations • Ensuring e. PPN to be non-reassigned also eases cloud integrations. Use edu. Person. Targeted. ID 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 In. Common 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 Id. Ps, 14% growth SPs, 13% growth

edu. Person Schema • edu. Person 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 edu. Person schema in contracts

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

Repository • In. Common Ops committing to GITHUB soon: – SAML 2 JSON translator – Smart Web User Agent (smart_get) – SAML Metadata Cert Parser – SAML Entity Probe – SAML 2 Attribute. Filter. Policy XSLT script for R&S • Web page coming. Community contributions encouraged.

Federated Error Handling • Guidance at https: //spaces. internet 2. edu/x/xa 6 KAQ • 3 sites in R&S already using FEH – (PSU wikispaces, OSU carmenwiki, i 2 filesender) • Did you know there is FEH service? • https: //spaces. internet 2. edu/x/k. JOVAQ • https: //ds. incommon. org/FEH/

FEH Service Example

Federated Security Incident Response • See https: //spaces. internet 2. edu/x/8 o 6 KAQ • 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 In. Common • Metadata mgmt needs to scale. DA is critical to make this possible. • Distribute the mgmt for MDUI, Lo. A, descriptive info per SP, Federated Error Handling. • Easily allows In. Common as local federation • Supports federated access, of course. • http: //www. incommon. org/v/da_demo/

CMU – Profile • Spring 2011: deployed Id. P, begin using In. Common as local federation. • Summer 2011: Default attribute release policy • Fall 2012: 117 SPs, 2 Id. Ps. > 75% all auth. Ns now federated. 150 old pubcookie sites to go. • Up take was fairly quick. • Will decommit pubcookie summer 2013. • Sept 2012: > 1 M SSO events – google analytics

In Summary • The more successful is In. Common, the greater the benefit of In. Common 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 In. Common?