Strawman proposal to use Moonshot for Command Line & Rich Client Sign-on<br />July 7,2011<br />Chris Phillips –chris.phill...
Goals<br />To model a possible deployment approach<br />To stimulate discussion about:<br />validity & possible gaps <br /...
The Challenge<br />How can a Federation Operator enable federated credentials to sign into non web and rich client infrast...
Proposed Deployment<br />Can be any computing infrastructure, but HPC site likely candidate<br />Proposed requirements to ...
Logical View<br />5<br />
Sequence Diagram <br />6<br />EditableWebSequence Diagram: http://bit.ly/CAF-Moonshot-WSD<br />
Implementation Questions<br />How does the local environment interact with Moonshot?<br />GSS exposes the data via attribu...
Implementation Questions<br />How do the central components interact with Moonshot?<br />See a need for a formalized schem...
Total Cost of Ownership<br />How will the account provisioning and maintenance work?<br />Representing a federated cred in...
Possible Limitations<br />RADIUS attribute passing is limited to 253 bytes per attribute<br />My understanding is that Moo...
Upcoming SlideShare
Loading in...5
×

Moonshot Brainstorming Strawman

1,147

Published on

Published in: Technology
4 Comments
1 Like
Statistics
Notes
  • Correct, you don't need Moonshot for O365. Office 365 can support SAML (their notation is SAMLP), but when configuring your domain for federation be sure to see a proper SAML redirect. Firefox+ Firefox SAML tracer plugin is a great tool for this.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Maybe I don't need Moonshot to get Shibboleth authentication to O365 without ADFS. I configured everything as instructed by Microsoft. I am not getting any error in Shibboleth, but still cannot login in to Office 365. The only error is: Your organization could not sign you in to this service.

    Who might be best placed to help resolve this? I have all the logs etc.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Hi Richard,
    Which issues in O365 would be my first question. SAML ECP profile supported by Shibbileth is what will permit password transit from a non web device (phone, outlook client etc) at the expense of the password going through MSFT's infrastructure.
    The challenge around moonshot adoption is a different one and I think the key message around your question. At this stage of the game vendor adoption is going to be weak until it is a proven, and maybe overwhelmingly proven, before someone like MSFT would adopt at all. There's no incentive to abandon or support such a new approach and depart their own in house (and officially supported) methods -- I'm specifically avoiding the word standard here.

    Does that help?

    Chris.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Just wondering if Moonshot might help overcome some issues I'm currently experiencing with Shibboleth authentication to Office 365.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
1,147
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
4
Likes
1
Embeds 0
No embeds

No notes for slide

Moonshot Brainstorming Strawman

  1. 1. Strawman proposal to use Moonshot for Command Line & Rich Client Sign-on<br />July 7,2011<br />Chris Phillips –chris.phillips@canarie.ca<br />
  2. 2. 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 />
  3. 3. 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 />
  4. 4. 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 />
  5. 5. Logical View<br />5<br />
  6. 6. Sequence Diagram <br />6<br />EditableWebSequence Diagram: http://bit.ly/CAF-Moonshot-WSD<br />
  7. 7. 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 />
  8. 8. 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 />
  9. 9. 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 />
  10. 10. 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 />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×