federated authentication in a campus system
DESCRIPTION
Presentation to the Liferay .EDU User Group, January 7, 2014TRANSCRIPT
Federated Authentication in a Campus System
Liferay .edu User Group, January 7, 2014Matthew HanlonMaytal Dahan
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.
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
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
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
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.)
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
UTFed/IdP ProxySource:https://spaces.internet2.edu/display/GS/SAMLIdPProxy
UTFed:https://idm.utsystem.edu/utfed
TACC User Portal
UT System SP
acts as
UT System IdP
UTFed - UT System Institutions
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
Installing Shibboleth (on CentOS 6)
$> cat /etc/yum.repos.d/security-shibboleth.repo
[security_shibboleth]
name=Shibboleth (CentOS_CentOS-6)
type=rpm-md
baseurl=http://download.opensuse.org/repositories/security:/shibboleth/CentOS_CentOS-6/
gpgcheck=1
gpgkey=http://download.opensuse.org/repositories/security:/shibboleth/CentOS_CentOS-6/repodata/repomd.xml.key
enabled=1
<ApplicationDefaults entityID="https://portal.tacc.utexas.edu/shibboleth" REMOTE_USER="eppn persistent-id targeted-id" attributePrefix="AJP_"> <SSO entityID="https://sso.utrc.utsystem.edu/simplesaml/saml2/idp/metadata.php" discoveryProtocol="SAMLDS"> SAML2 SAML1 </SSO> <MetadataProvider type="XML" reloadInterval="86400" uri="https://sso.utrc.utsystem.edu/simplesaml/saml2/idp/metadata.php"> </MetadataProvider> <MetadataProvider type="XML" uri="https://idm.utsystem.edu/downloads/UTfed-metadata.xml" backingFilePath="UTfed-metadata.xml" reloadInterval="7200"> <MetadataFilter type="Signature" certificate="utfedops-sign.crt"/> </MetadataProvider></ApplicationDefaults>
Shibboleth2 Configuration
mod_shib Configuration
<Location /utdr> # this is a path that exists in Liferay
AuthType shibboleth
ShibRequestSetting requireSession 1
require valid-user
</Location>
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
...
}
Portlet
The portlet handles three account states:
1. The email attribute for the UTFed user matches an existing TUP user2. The email attribute for the UTFed user does not match an existing TUP user and:
a. the user already has a TUP accountb. 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.
What it looks like for users?
Duplicate Accounts
Users are crafty. :)
Questions? Comments?
More Information about TACC: http://www.tacc.utexas.edu
Matthew Hanlon @[email protected]
Maytal Dahan @[email protected]