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

5. Logical View
5

6. Sequence Diagram
6
EditableWebSequence Diagram: http://bit.ly/CAF-Moonshot-WSD

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 environmenthow?
How will the policy decision on access work?
If at the edge or end points, need a way to manage mass deployment (>1000s 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 & LDAPthoughts?
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 BASE64d into this) which may suffer over RADIUS UDP. Should we be concerned?
10