InCommon as Infrastructure: How Recommended Practices and

Federation Features Help Scale Federated Identity Management

Michael R. Gettes, Carnegie Mellon UniversityRenee Shuey, The Pennsylvania State University

Internet2 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!

• 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

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

MetadataUntil 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-2012IdPs, 14% growthSPs, 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/

FEH Service Example

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?