University of Chicago University of Illinois Indiana University University of Iowa University of Maryland University of Michigan Michigan State University University of Minnesota University of Nebraska-Lincoln Northwestern University Ohio State University Pennsylvania State University Purdue University Rutgers University University of Wisconsin-Madison Lowering Barriers for Distributed Service Integration The Cloud Cookbook Project By the CIC ID Management Research CI Working Group Presenters: Keith Wessel, Mark Nye, Keith Brautigam
What is the CIC? Founded in 1958, the Committee on Institutional Cooperation is an academic consortium of top-tier research universities, including members of the Big Ten Conference and the University of Chicago. CIC members collaborate to advance their academic missions, generate unique opportunities for students and faculty, and serve the common good by sharing expertise, leveraging campus resources, and creating innovative programming. The work of the CIC is carried out in two ways: 1) through targeted project partnerships that meet three primary criteria: addresses member university needs; creates new opportunities through the aggregation of resources; and would not be possible by a university acting alone; and 2) through communities of peers that meet together to address common issues, share best practices, and diffuse innovation throughout the network of universities. Building Collaboration Infrastructure
PURPOSE Why a Cloud Services Cookbook? Lower cost and effort in federating with a cloud service. Reduce need for schools to regularly consult for vendors. Help vendors understand IAM in higher education. Reduce duplicated efforts among CIC schools.
PROGRESS The story so far … The Cookbook is in the process of being written Developing a recipe for success Integration template for federated cloud services Best practices for cloud integration Complement to Internet2 NET+ initiative
PROCESS The Cloud Cookbook is a consensus-driven project! Thus far, we’ve … Surveyed CIC schools on the experience of implementing various cloud services. Combined survey results with common knowledge to create a document outline. Documented best practices for identity providers as well as service providers. Plan to produce both school- and vendor-facing documents.
FORMAT What will the Cloud Services Cookbook look like? “Do” and “don’t” best practice statements with concise explanations. No verbose expositions and definitions; that content is already available elsewhere. Where a recommendation isn't fully supported by all CIC schools, it will be included as a consideration instead of a definite do or don't.
TOPICS High-level Cloud Cookbook Topics: Authentication Identifiers Authorization Provisioning and Deprovisioning Trust Frameworks Operational Agility User Experience Policy and Compliance
best practice #1 TRUST FRAMEWORKS “If you want to scale, DO define a process for maintaining SAML Service Provider metadata.” SAML is an accepted standard. If trust isn't an issue, allow for anonymous services. Self-published SP metadata and exchanges don't scale well. Your best option is the use of a federation.
best practice #2 TRUST AND OPERATIONAL AGILITY “DO register SAML metadata with the InCommon Federation.” Joining InCommon takes care of many best practices: Leverages an existing trust framework. Provides for validated SAML and sound operational practices. Ensures daily metadata refresh. Automatically handles certificate and endpoint changes without service disruption. Automate security issues such as cert revocation.
best practice #3 IDENTIFIERS “Re-defining attributes is painful, so DON’T call a Foo a Bar!” Resist the temptation to force something you have into something you need. In federated contexts, standard attribute definitions are important. Carefully consider what's available before creating a new attribute. If the available attributes won't do, create something new instead of misusing a known attribute.
best practice #4 IDENTIFIERS “CONSIDER the relationship between eduPersonPrincipalName and mail.” It's hard to enroll for most cloud services without a standard enterprise address. University environments aren't as well- controlled as in the corporate world. Higher Ed can be multi-valued, and often is. Services want an identifier for three purposes: unique ID, address, and scope
best practice #5 IDENTIFIERS “DON'T be afraid of eduPersonTargetedID.” Continues to identify a user, even when their name or address changes. Might sound intimidating, but is simple to set up. Requires a unique and unchanging identifier. Because it's computed with a salt, it's opaque but unique to the SP.
best practice #6 AUTHORIZATION To avoid trouble later … “DO authentication at the campus, but authorize at the service.” Remember, it's the SP's job to do authorization. The IDP can make authorization decisions, but this doesn't scale. Service authorization changes are easier when the SP is interpreting the identity data. eduPersonEntitlement is an entitlement class, not an authorization decision.
best practice #7 PROVISIONING / DEPROVISIONING “DO practice ‘defensive programming’ when setting up provisioning services.” Be warned! Vendor service provisioning docs are often incomplete or inaccurate. Campus should test error conditions and unhandled failures and identify work-arounds. Service reliability under load can fluctuate. Schools need to plan for these issues.
CONCLUSION We want your help! You have an opportunity to shape the Cloud Cookbook Project. If you have feedback to share or you would like to get involved, please contact Keith, Keith, or Mark.
1819 South Neil Street, Suite D, Champaign, IL Preview the Cloud Cookbook working draft at: This is a CIC project, and your feedback and input is welcome! Keith Wessel - Mark Nye - Keith Brautigam -