1. Strawman proposal to use Moonshot for Command Line & Rich Client Sign-on July 7,2011 Chris Phillips –chris.phillips@canarie.ca
2. Goals To model a possible deployment approach To stimulate discussion about: validity & possible gaps problems that this calls out & possible responses scope & scale considerations Costs Install & start Ongoing Receive feedback and adjust as necessary More questions than answers will be raised … 2
3. The Challenge How can a Federation Operator enable federated credentials to sign into non web and rich client infrastructure safely, securely, and reliably? 3
4. Proposed Deployment Can be any computing infrastructure, but HPC site likely candidate Proposed requirements to participate Member of one or more federations trust fabrics (RADIUS &/or SAML) Canada manages both eduroamand Shibso these would be our choices On the target site: Has administrative control over the target to log into (unix box) Has deployed local Moonshot enhancements to said unit (a patched SSHd and Moonshot enhanced GSS libraries) Manages a RADIUS server for their site that is connected to eduroam and is a SAML SP in the Shib Fed. runs Moonshot enhancements Has made necessary configurations in each of the pieces to allow access Has provisioned the necessary information to an acount to permit sign in 4
7. Implementation Questions How does the local environment interact with Moonshot? GSS exposes the data via attribute release from querying it: How does this map to local environment variables? implicit trust that the attributes in those variables are trustworthy & immutable via GSS API call – is this ok? How is the GSS API call secured against a multi-homed multi-user environment? If on same system, can I query for various GSS sessions and walk the users on the system? (doubtful, but want to ask to verify) Assumption is GSS takes care of partitioning users. 7
8. Implementation Questions How do the central components interact with Moonshot? See a need for a formalized schema map to benefit 80% and let 20% extend. Most cost effective is set one standard (based on input) ‘internationally’ with ability to extend Does this style of schema exist elsewhere (e.g. GridShib toolkit?) Various origin datasources are in play so centralized schema in different formats (e.g. 3NF tables for SQL, ldapobjectclass definitions, and SAML profiles would be great to level the playing field. Thoughts on how long/big/worthwhile this is and how repetitive it will be? Thoughts on how elements go from ‘core’ from the extensions? (aka Governance?) 8
9. Total Cost of Ownership How will the account provisioning and maintenance work? Representing a federated cred in a remote environment…how? How will the policy decision on access work? If at the ‘edge’ or end points, need a way to manage mass deployment (>1000’s of systems – think EC2) OR centralize this somehow Need to harmonize the way to deal with schema and consistent view of data across RADIUS & SAML & DB & LDAP…thoughts? Complex is ok, as long as automation can prevail, but what skills will be required to keep the lights on for this software ecosystem? 9
10. Possible Limitations RADIUS attribute passing is limited to 253 bytes per attribute My understanding is that Moonshot takes care of packing/unpacking long attributes over RADIUS protocol Not an issue, but as a more rich attribute definition is built out, there could be large profiles (think XML & x509 certs BASE64’d into this) which may suffer over RADIUS’ UDP. Should we be concerned? 10
