SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
1.
Federated Authentication in a
Campus System
Liferay .edu User Group, January 7, 2014
Matthew Hanlon
Maytal Dahan
2.
Introduction
● Texas Advanced Computing Center (TACC)
○ Advanced computing center with a diverse set of resources - high performance computing,
visualization, data centers, cloud computing, etc.
● TACC is part of The University of Texas System
○ 9 universities
○ 6 health institutions
● Our main goal is to maximize productivity and help support educators, scientists and
researchers by lowering the barrier of entry into these systems. One way to accomplish that is
via federated identities
● Use a single identity to authenticate to authenticate to the user portal to apply for allocations on
our resources, manage resource usage, etc.
3.
Federated Authentication
Allowing users to link a single identity and attributes across several distinct identity management
systems.
Technologies:
• SAML
• OAuth
• OpenID
• also, LDAP, Active Directory
4.
Terminology
IdP - Identity Provider
This is the entity that “provides” the authentication and authorization, and to whom the end user
authenticates.
SP - Service Provider
This is the entity providing a service that the user wants to use, e.g., a Liferay Portal.
SAML - Security Assertion Markup Language
XML-based open standard data format for exchanging authentication and authorization data
between parties
5.
1. The SP detects the user attempting to access restricted content within the resource.
2. The SP generates an authentication request, then sends the request, and the user, to the user's IdP.
3. The IdP authenticates the user, then sends the authentication response, and the user, back to the
SP.
4. The SP verifies the IdP's response and sends the request through to the resource which returns the
originally requested content.
Source: https://wiki.shibboleth.net/confluence/display/SHIB2/NewUnderstandingShibboleth
6.
UT System Research Cyberinfrastructure (UTRC)
• Project within The University of Texas System
• Improve the quality of IT for research for all 15 UT System Institutions
• High-speed Networking, including “last mile”
• Access to advanced data and storage capability (TACC)
• Access to high performance computing (HPC) resources (TACC)
• TACC provides access to the Data and HPC resources via the TACC User Portal (TUP) as well
as other access methodologies (SSH, FTP, GridFTP, etc.)
7.
Hurdles
• Onboarding hundreds to thousands of new users who lack experience using HPC resources
• Requirement to use campus credentials for login to prevent users from having to
create/memorize additional username/password
• need to federate authentication to 15 institutions
• Must retain current authentication/authorization in TUP for non-UT users
• also, existing users may want to enable login using campus credential
• Accounting requirements for accessing HPC resources
• export control, “countries of concern”
• need assurances of compliance
8.
UTFed/IdP Proxy
Source:
https://spaces.internet2.
edu/display/GS/SAMLIdPProx
y
UTFed:
https://idm.utsystem.edu/utfed
TACC User Portal
UT System SP
acts as
UT System IdP
UTFed - UT
System Institutions
9.
SAML Authentication in Liferay
What we didn’t use:
Liferay EE SAML Plugin: https://www.liferay.com/marketplace/-/mp/application/15188711
Enables configuring Liferay as an IdP or SP according to the SAML2 spec
What we did use:
Shibboleth2 with Apache mod_shib
Custom AutoLogin hook for SAML login
Custom Portlet for inital account creation/linking
12.
mod_shib Configuration
<Location /utdr> # this is a path that exists in Liferay
AuthType shibboleth
ShibRequestSetting requireSession 1
require valid-user
</Location>
13.
portal.properties
auto.login.hooks=edu.utexas.tacc.liferay.portal.security.auth.UtdrShibbolethAutoLogin
AutoLogin Hook
UtdrShibbolethAutoLogin
public String[] login(HttpServletRequest request, HttpServletResponse response) throws AutoLoginException {
String[] creds = null;
String fedId = (String) request.getAttribute("eppn");
Account user = null;
try {
user = dao.findAccountByFederatedId(fedId);
} catch (DaoException e) { ... }
// if user found, create and return credential array
...
}
14.
Portlet
The portlet handles three account states:
1. The email attribute for the UTFed user matches an existing TUP user
2. The email attribute for the UTFed user does not match an existing TUP user and:
a. the user already has a TUP account
b. the user does not have a TUP account
In cases 1. and 2a., the user enters the credential for the existing account to link the TUP account with
the UTFed identity.
In 2b., the user creates a new account, needing to only provide minimal information, since the UTFed
identity provides almost all of what we need.
17.
Questions? Comments?
More Information about TACC:
http://www.tacc.utexas.edu
Matthew Hanlon @mattorantimatt
mrhanlon@tacc.utexas.edu
Maytal Dahan @maytaldahan
maytal@tacc.utexas.edu