FeduShare TechEx15

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.

• 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:

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

Collaborators wants an environment where
managing members & access to resources is
FAST and EASY
This! Not This!

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?

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

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”

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.

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

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.

Federation
Administration
/Management
Interface
Actor

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/

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

1. CILogon
CILogon
Browser
IdP
gsissh gsisshd
1. Choose IdP
2. SAML AuthnReq
3. SAML AuthnReq
4. SAML Authn Assertion
6. X.509 Certificate
7. X509 Authentication
grid-mapfile/GUMS
InCommon

2. ECP SSH
IdP (ECP)
ecpssh
ecpsshd
1. SSH Userauth Req
2. SAML AuthnReq
3. SAML AuthnReq
eppn -> username
InCommon

3. ECP PAM
IdP (ECP)
ssh
pam
eppn -> username
InCommon
sshd1. Username/Password
2. Username/Password
3. Username/Password 4. SAML

4. SSH Keys
Portal
Browser
IdP
ssh sshd
1. Choose IdP
2. SAML AuthnReq
3. SAML AuthnReq
6. Register SSH Key
8. SSH Pubkey Authentication
$HOME/.ssh/authorized_keys
InCommon
7. SSH pubkey

5. Stay in Browser
Web Portal
Browser
IdP
Resource
1. Choose IdP
2. SAML AuthnReq
3. SAML AuthnReq
6. Access
7. Access
InCommon

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

Outline
•Non-web logon using Shibboleth: Options (Jim, NCSA@Illinois)
•Demo (don’t blink!)
•Q&A

Outline
•Non-web logon using Shibboleth: Options (Jim, UICU)
•Demo
•Q&A

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

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

Account mapping
EPPN local-login-user

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="^u0001@elsewhere.edu$">externaluser1</Regex>
<Regex match="^u0002@elsewhere.edu$">externaluser2</Regex>
</AttributeResolver>

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>

Limitations
•Requires patched SSH server and client
•Requires user to know their organization’s IDP’s ECP endpoint

Outline
•Demo
•Q&A

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

Individual’s Identity
504cbe00-99e6-11e1-a8b0-0800200c9a66
• Banner
• Peoplesoft
• Blackboard
• Name
• Email addresses
• Username
• XID
Photos Credentials
Self Service

CUVault
• Banner
• Peoplesoft
• Blackboard
• Photo
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

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

Outline
•Demo
•Integration with Campus Partnerships & Strategy (Subhasish,
UUtah)
•Happy Side Effects: Open Source Mobil Logon (Tyler, Clemson)
•Q&A

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)

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

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

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

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

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

Team
FeduShare
Jill
Jon
Steve
Jim
Barry
Marshall
Subhasish
Mike
Robert
Billy Nick
Tyler
Kathy
Corey

FeduShare TechEx15

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (19)

Semelhante a FeduShare TechEx15

Semelhante a FeduShare TechEx15 (20)

Mais de jbasney

Mais de jbasney (14)

Último

Último (20)

FeduShare TechEx15