Federation Strategy Robert Ricci GENI-FIRE Workshop September 2015

Preview:

Citation preview

Federation StrategyRobert Ricci

GENI-FIRE Workshop September 2015

Basics of GENI Federation• Partitioned trust• All identities and assertions verified cryptographically• No federation member can forge credentials for other members

• Separate Authentication and Authorization• Authentication: “Who is this user?” (Member Authority)• Authorization: “Why are they allowed to use the facility?” (Slice Authority)

• Use untrusted tools as much as possible• Eg. multiple portals• “Speaks-for” for accountability

• Federation established by a trusted third party (Clearinghouse)• Anyone can join more than one federation• As simple as adding and removing root certificates

Successes in GENI Federation• 142 aggregates federated• Moderately heterogeneous

• Clusters• Wireless• Backbone networks• Existing testbeds

• Includes international resources• Reasonably broad and consistent tool support• Adding a new federate is easy (from a clearinghouse standpoint)• Decentralized model / autonomous facilities• Model is used for multiple testbeds / federations• Multiple overlapping federations

Contributing Factors• Limited number of implementations

• Can use personal communication, not precise specs

• Limited number of resource owners -> common purpose• Mostly moving in the same direction

• Limited heterogeneity• Would be hard to find what you want, but most of it is similar

• Not much policy diversity• Don’t have to explain differences to users, tools

• Frequent meetings• Close communications, forcing functions

Scaling to an International Effort• More implementations

• Heavier reliance on specifications and tests

• More resource owners• Every owner needs an incentive to federate

• More heterogeneous• Ability to search

• More policy diversity• We are going to have to talk more about how to expose this to users

• More loosely coupled development• More reliance on online collaboration, less on face-to-face meetings

Rob’s Thoughts

Infrastructure doesn’t federate, people federate

Give people-organization features priority from the beginning

Build loose, rather than strict, federations

Federation structures between people are complex and vary a lot

– Clarke’s Third Law

“Any sufficiently advanced technology is indistinguishable from magic.”

–Ricci’s Addendum to Clarke’s Third Law

“… but any sufficiently advanced federation is still distinguishable from a

single facility.”

Users want to do research or take classes, not learn about infrastructure

Smooth over the differences you can, expose those that you can’t directly

–Clarke’s Second Law

“The only way of discovering the limits of the possible is to venture a little way past

them into the impossible.”

Enable people to use the infrastructure for things you didn’t think you designed it for,

without asking your permission.

–Clarke’s First Law

“When a distinguished but elderly scientist states that something is possible, he is

almost certainly right. When he states that something is impossible, he is very

probably wrong.”

Federate early and often

Recommended