Successfully reported this slideshow.

Federated Authentication in a Campus System



Upcoming SlideShare
Cache Security- The Basics
Cache Security- The Basics
Loading in …3
1 of 17
1 of 17

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Federated Authentication in a Campus System

  1. 1. Federated Authentication in a Campus System Liferay .edu User Group, January 7, 2014 Matthew Hanlon Maytal Dahan
  2. 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. 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. 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. 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:
  6. 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. 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. 8. UTFed/IdP Proxy Source: https://spaces.internet2. edu/display/GS/SAMLIdPProx y UTFed: TACC User Portal UT System SP acts as UT System IdP UTFed - UT System Institutions
  9. 9. SAML Authentication in Liferay What we didn’t use: Liferay EE SAML Plugin: 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
  10. 10. Installing Shibboleth (on CentOS 6) $> cat /etc/yum.repos.d/security-shibboleth.repo [security_shibboleth] name=Shibboleth (CentOS_CentOS-6) type=rpm-md baseurl= /shibboleth/CentOS_CentOS-6/ gpgcheck=1 gpgkey= /shibboleth/CentOS_CentOS-6/repodata/repomd.xml.key enabled=1
  11. 11. <ApplicationDefaults entityID="" REMOTE_USER="eppn persistent-id targeted-id" attributePrefix="AJP_"> <SSO entityID="" discoveryProtocol="SAMLDS"> SAML2 SAML1 </SSO> <MetadataProvider type="XML" reloadInterval="86400" uri=""> </MetadataProvider> <MetadataProvider type="XML" uri="" backingFilePath="UTfed-metadata.xml" reloadInterval="7200"> <MetadataFilter type="Signature" certificate="utfedops-sign.crt"/> </MetadataProvider> </ApplicationDefaults> Shibboleth2 Configuration
  12. 12. mod_shib Configuration <Location /utdr> # this is a path that exists in Liferay AuthType shibboleth ShibRequestSetting requireSession 1 require valid-user </Location>
  13. 13. 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. 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.
  15. 15. What it looks like for users?
  16. 16. Duplicate Accounts Users are crafty. :)
  17. 17. Questions? Comments? More Information about TACC: Matthew Hanlon @mattorantimatt Maytal Dahan @maytaldahan