FeduShare TechEx15
- 1. FeduShare A User-Managed Collaboration Framework This material is based upon work supported by the National Science Foundation under Grant No. ACI-1440609. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.
- 2. • Jill Gemmill, CTO Middleware (PI) • Billy Cook, Director Software Dev. & IAM • Nick Watts, Software Developer • Tyler Thompson, Mobile App Developer • Subhasish Mitra, Director IAM Strategy & Co-PI ● Jim Basney, Senior Research Scientist, NCSA & Co-PI Panelists:
- 3. Outline •FeduShare: What and Why ? (Jill, Clemson) •Non-web logon using Shibboleth: Options (Jim, NCSA@Illinois) •Demo •Technical Details (Nick, Clemson) •Accounts and Provisioning (Billy, Clemson) •Campus Partnerships Required (Subhasish, UUtah) •Happy Side Effects: Open Source Mobile Logon (Tyler, Clemson) •Q&A
- 4. Collaborators wants an environment where managing members & access to resources is FAST and EASY This! Not This!
- 5. The FeduShare Framework We have been modeling and designing campus infrastructure as a closed system with identities and resources we own What if we modeled and designed for open, multi-directional collaboration instead?
- 6. What National Research Infrastructure Provides for Collaboration •XSEDE, OSG, GENi, Science Gateways have been built by a handful of highly skilled experts ● Challenges: (1) How to share campus resources (2) How to integrate campus with national resources (3) Are there enough experts to get the work done? •These models are certificate based which does not match most campus infrastructures S A M L
- 7. Fluid, Transparent, Federated and Secure access to Distributed Resources is HARD University Campus IT have highly talented Identity and Access Management (IAM) and systems integration staff IDENTITIES BUT…… 1. They may not have been asked to solve the problem “Build Infrastructure to support Collaboration everywhere” 2. They may still be designing from a perspective that is inside the campus silo -- “add another guest user”
- 8. Actors 1. Researcher: a faculty member, student, employee, or other person involved in the collaboration. 2. Principal Investigator role: a. designates VO membership b. conducts out-of-band arrangements to obtain approved use of the remote resource(s) c. is responsible for behavior of the VO members regarding their use of these resources. 3. VO Manager: manages VO membership and access to shared resources under the PIs direction. 4. Resource Manager operates the remote resource and provides access according to local policy.
- 9. Assumptions •Actors and resource providers are InCommon members. •All support InCommon Research and Scholarship (R&S) Profile* •Shibboleth 2.4+ and can provide the required SAML assertions. •There exists a Virtual Organization Management service(s). •Access is controlled at the resource • where multiple resources are being shared by a single VO, there may be a single resource manager component between the user and each federated resource. *IdP releases EPPN, name, email address
- 10. Event Flow 1. Create the Virtual Organization 2. List the collaborators*. 3. If and when the VO requires use of resources, a PI must be designated**. 4. PI makes a request to one of more Resource Managers, is apprised of their responsibilities as PI, and is accepted by the Resource Manager as a trusted PI. 5. VO Members can begin to access resources through a Resource Request Protocol, with authorization based on their local campus authentication (EPPN) and VO Membership info. * Ideally, via an invitation approved by each member. **Note -- in OSG and Science Gateways, this is Step 1. Access is authorized based on VO membership, only, communicated in these cases via a VOMS-issued X.509 attribute certificate OR by membership in a science gateway portal; in this case all VO members may run as a single userid.
- 12. The Project: Two Use Cases + a Catalog Use Case 1: Federated access to a campus HPC cluster via console logon -- in PRODUCTION SYSTEMS (Year 1) Use Case 2: Federated access to multiple clouds/SDN testbeds (eg: GeNi and CloudLab ) (Year 2) Catalog: Open Source Software candidates to use for FeduShare framework components (Years 1 & 2) https://sites.google.com/site/fedushare/
- 13. Outcomes so far • In production use of Shibboleth ECP at Clemson and Utah • SAML Enhanced Client SASL and GSS-API Mechanisms https://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-13 • Enhanced collaboration intra-IT organizations • Documentation: https://sites.google.com/site/fedushare/ • Software: • mech_saml_ec library https://github.com/fedushare/mech_saml_ec • Apple Native Mobile AuthN: https://github.com/OpenClemson/SwiftECP • Work force development
- 14. Outline •FeduShare: What and Why ? (Jill, Clemson) •Non-web logon using Shibboleth: Options (Jim, NCSA@Illinois) •Demo •Technical Details (Nick, Clemson) •Accounts and Provisioning (Billy, Clemson) •Campus Partnerships Required (Subhasish, UUtah) •Happy Side Effects: Open Source Mobile Logon (Tyler, Clemson) •Q&A
- 15. 1. CILogon CILogon Browser IdP gsissh gsisshd 1. Choose IdP 2. SAML AuthnReq 3. SAML AuthnReq 4. SAML Authn Assertion 5. SAML Authn Assertion 6. X.509 Certificate 7. X509 Authentication grid-mapfile/GUMS InCommon
- 16. 2. ECP SSH IdP (ECP) ecpssh ecpsshd 1. SSH Userauth Req 2. SAML AuthnReq 3. SAML AuthnReq 4. SAML Authn Assertion 5. SAML Authn Assertion eppn -> username InCommon
- 17. 3. ECP PAM IdP (ECP) ssh pam eppn -> username InCommon sshd1. Username/Password 2. Username/Password 3. Username/Password 4. SAML
- 18. 4. SSH Keys Portal Browser IdP ssh sshd 1. Choose IdP 2. SAML AuthnReq 3. SAML AuthnReq 4. SAML Authn Assertion 5. SAML Authn Assertion 6. Register SSH Key 8. SSH Pubkey Authentication $HOME/.ssh/authorized_keys InCommon 7. SSH pubkey
- 19. 5. Stay in Browser Web Portal Browser IdP Resource 1. Choose IdP 2. SAML AuthnReq 3. SAML AuthnReq 4. SAML Authn Assertion 5. SAML Authn Assertion 6. Access 7. Access InCommon
- 20. Decision Matrix CILogon ECP SSH ECP PAM SSH Keys Web Portal No special client software ❌ gsissh ❌ ecpssh ✔ ✔ ✔ Software exists today ✔ ✔ ❌ ✔ ✔ Password not exposed to server ✔ ✔ ❌ ✔ ✔ No extra registration step ❌ cert ✔ ✔ ❌ key ✔ No new user-managed keys ❌ ✔ ✔ ❌ ✔ Uses SAML for SSH login ❌ ✔ ✔ ❌ ✔ Native SSH client ✔ ✔ ✔ ✔ ❌ browser
- 21. Outline •FeduShare: What and Why ? (Jill, Clemson) •Non-web logon using Shibboleth: Options (Jim, NCSA@Illinois) •Demo (don’t blink!) •Technical Details (Nick, Clemson) •Accounts and Provisioning (Billy, Clemson) •Campus Partnerships Required (Subhasish, UUtah) •Happy Side Effects: Open Source Mobile Logon (Tyler, Clemson) •Q&A
- 22. Outline •FeduShare: What and Why ? (Jill, Clemson) •Non-web logon using Shibboleth: Options (Jim, UICU) •Demo •Technical Details (Nick, Clemson) •Campus Partnerships Required (Subhasish, UUtah) •Accounts and Provisioning (Billy, Clemson) •Happy Side Effects: Open Source Mobile Logon (Tyler, Clemson) •Q&A
- 23. Requirements •mech_saml_ec library • https://github.com/fedushare/mech_saml_ec • Implementation of draft-ietf-kitten-sasl-saml-ec-13 “SAML Enhanced Client SASL and GSS-API Mechanisms” •Project Moonshot’s patched SSH server/client • http://www.project-moonshot.org/git/openssh.git •ECP enabled Shibboleth IDP (version 2.4+) •Shibboleth SP configuration
- 24. Overview SAML Identity Provider Client SAML Relying Party (HPC head node) 1. Advertisement Supported SASL mechanisms: SAML20EC SAML20EC-PLUS SASL / GSS API 2. Initiation Client initiates SAML20EC or SAML20EC-PLUS authentication 3. Server Response RP sends challenge containing SAML AuthnRequest 5. Client Response IDP replies with SAML Response containing authentication assertion. Client sends it as a response to server’s SASL challenge. 6. Authenticated! Establish SSH connection 4. IDP Authentication Client sends SOAP request containing SAML AuthnRequest Authenticates to IDP using HTTP Basic HTTPS
- 26. Transform Attribute Resolver <AttributeResolver type="LowerCase" dest="local-login-user" source="eppn" /> <AttributeResolver type="Transform" source="local-login-user"> <Regex match="^(.+)@campus.edu">$1</Regex> <Regex match="^[email protected]$">externaluser1</Regex> <Regex match="^[email protected]$">externaluser2</Regex> </AttributeResolver>
- 27. SimpleAggregation AttributeResolver <AttributeResolver type="SimpleAggregation" attributeId="eppn" format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"> <Entity>https://accountmap.sp.campus.edu/idp/shibboleth</Entity> <MetadataProvider type="XML" uri="https://accountmap.sp.campus.edu/idp/profile/Metadata/SAML" backingFilePath="/tmp/accountmap-metadata.xml" reloadInterval="60" /> </AttributeResolver>
- 28. Limitations •Requires patched SSH server and client •Requires user to know their organization’s IDP’s ECP endpoint
- 29. Outline •FeduShare: What and Why ? (Jill, Clemson) •Non-web logon using Shibboleth: Options (Jim, UICU) •Demo •Technical Details (Nick, Clemson) •Accounts and Provisioning (Billy, Clemson) •Campus Partnerships Required (Subhasish, UUtah) •Happy Side Effects: Open Source Mobile Logon (Tyler, Clemson) •Q&A
- 30. CUVault • Banner • Peoplesoft • Blackboard • Photo • Other authoritative sources Credentials (User accounts) Self Service & Administration Identity & Resource Directories CUID Directory CUVault External Interface to vault • Clemson login • Other authentication • Applications Provisioning Unique Directory
- 31. Individual’s Identity 504cbe00-99e6-11e1-a8b0-0800200c9a66 • Banner • Peoplesoft • Blackboard • Other authoritative sources • Name • Email addresses • Username • XID Photos Credentials Self Service
- 32. CUVault • Banner • Peoplesoft • Blackboard • Photo • Other authoritative sources Credentials (User accounts) Self Service & Administration CUID Directory CUVault External Interface to vault • Clemson login • Other authentication • Applications Provisioning Unique Directory Vetted Unique Identities VisitorIDs
- 33. Challenge Summary How do we mix identities with a lower level of assurance with campus identities that have a high level of assurance? - researchers - campus guests - alumni - summer campers
- 34. Outline •FeduShare: What and Why ? (Jill, Clemson) •Non-web logon using Shibboleth: Options (Jim, UICU) •Demo •Technical Details (Nick, Clemson) •Accounts and Provisioning (Billy, Clemson) •Integration with Campus Partnerships & Strategy (Subhasish, UUtah) •Happy Side Effects: Open Source Mobil Logon (Tyler, Clemson) •Q&A
- 35. University Of Utah - CHPC and IAM Partnership The Team at Utah • Robert Roll, IAM Sys Consultant - IAM - FeduShare Shib SME • Steve Harper, Sr Sys Admin - CHPC - FeduShare ECP/SSH SME • Subhasish Mitra, Assoc Dir - IAM/Info Sec - FeduShare CO PI At our Campus • Enabled ECP in Shib 2.4 IDP (Robert, IAM) • Complied ECP SSH - openMoonShot (Steve, CHPC)
- 36. University Of Utah - CHPC and IAM Partnership Current Story • CHPC is soley responsible for managing on-boarding and off- boarding of users to their HPC clusters, however they leverage Campus central identities for their processes & accounts Goal • FeduShare enables IAM and CHPC to gain/allow access to local HPC resources using external entity credentials
- 37. Outline •FeduShare: What and Why ? (Jill, Clemson) •Non-web logon using Shibboleth: Options (Jim, UICU) •Demo •Technical Details (Nick, Clemson) •Campus Partnerships Required (Subhasish, UUtah) •Accounts and Provisioning (Billy, Clemson) •Happy Side Effects: Open Source Mobile Logon (Tyler, Clemson) •Q&A
- 38. my.Clemson Native Login • We’re in the process of converting our hybrid mobile web app into a native iOS app • We wanted to build a native login screen that adds the option to save credentials in the iOS keychain (login-once paradigm) • We needed to integrate native login with Shibboleth since the web portion of our app (as well as other campus services) use it • We wanted to provide instant progress, success, and error messages without redirects or going out to the browser
- 39. Shibboleth ECP • ECP allows us to authenticate through Shibboleth with HTTP requests instead of browser redirects • The previous FeduShare work at Clemson ensured that our IDP supported ECP and was configured properly • Only our SPs needed extra configuration (a simple ECP=”true” attribute) • Client support remained the major blocker • Clients available for Python, Java, and Perl but not for Objective-C or Swift
- 40. SwiftECP • Open-source ECP client for iOS • https://github.com/OpenClemson/SwiftECP • Abstracts ECP details away from library user • Supports simplest use case (no delegation, channel bindings, or holder-of-key support) • Production-tested • Updating to Swift 2.0 in the near future • Adding attribute extraction soon • Pull requests/bug reports/audits welcome and encouraged
- 42. Pitfalls • If any of the three ECP requests fails, the entire login fails with it. This can be a problem on high-latency cellular networks • Major systems we integrate with, such as Blackboard, use homegrown Clemson token cookies • The usefulness of an ECP client is directly proportional to how many university systems adopt Shibboleth over legacy auth
- 43. Team FeduShare Jill Jon Steve Jim Barry Marshall Subhasish Mike Robert Billy Nick Tyler Kathy Corey
- 44. Q&A