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