Federated Authentication in a Campus System

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 @mattorantimattmrhanlon@tacc.utexas.edu

Maytal Dahan @maytaldahanmaytal@tacc.utexas.edu