1 / 18

Authentication via campus single sign-on

Authentication via campus single sign-on. 2012 VIVO Implementation Fest. Welcome & Who are we? . Vincent Sposato, University of Florida Enterprise Software Engineering Primarily focused on VIVO operations and reproducible harvests Alex Viggio , Colorado University

adrian-goff
Download Presentation

Authentication via campus single sign-on

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Authentication via campus single sign-on 2012 VIVO Implementation Fest

  2. Welcome & Who are we? Vincent Sposato, University of Florida Enterprise Software Engineering Primarily focused on VIVO operations and reproducible harvests Alex Viggio, Colorado University Office of Faculty Affairs FIS Developer

  3. Goals of this session • Provide you with a why for single sign-on • Provide a basic implementation of a single sign-on solution, as implemented at UF • Answer questions

  4. Why Single Sign-On?

  5. What is single sign-on? • Is a property of access control of multiple related, but independent software systems • Is usually an independent authentication system, with stricter rules, that provides confirmation of identity to these systems • Is often thought to be the unicorn of authentication, as many have heard of it but no one has truly seen it • Has been referred to as Enterprise Reduced Sign-On

  6. Why single sign-on? • Reduces ‘password fatigue’ from remembering multiple usernames and passwords for different systems • Reduces amount of duplicating password entry for same user within same environment • Provides for enforcement of more robust security requirements and compliance reporting, since there is a centralized authentication mechanism

  7. Why not single sign-on? • Potential for increased risk should identities be compromised, as single sign-on gives the ‘keys’ to the castle away • Loss of singular authentication system, would result in denial of service to a large amount of systems • Can be difficult to integrate with older systems, and /or closed systems that do not natively support separate authentication

  8. Who has single sign-on Every Major Institution in the world … That we know of

  9. Typical SSO Implementations • Kerberos • Once authenticated a ticket-granting ticket is given to the system • This TGT is handed around to gain authentication to other systems that support • Smart Card • Use of a password to unlock the Smart Card • Other applications make call to the Smart Card without further need to provide password • One Time Password (OTP) • RSA SecurID is an example of a OTP, and is the standard for 2-Factor Authentication • Integrated Windows Authentication (Active Directory) • Microsoft standard for integrating credentials between supporting systems – uses Kerberos, SPNEGO, and NTLMSSP – to accomplish SSO • Shibboleth • Open-source federated identity-based authentication and authorization system based on Security Assertion Markup Language (SAML)

  10. What do I need to have? • Guides about the Identity Management System @ your institution • The required software for your identity management system installed and configured on your VIVO application server

  11. Implementing Shibboleth

  12. How does it all work

  13. Setting up the Server to Secure VIVO • You can use shibboleth.xml to secure applications • We use the apache configuration files • Add the following lines fix confusion between tomcat, apache, and shibboleth JkUnMount /Shibboleth.ssso/* default JkUnMount /Shibboleth default JkUnMount /shibboleth-sp/* default

  14. Setting up the Server to Secure VIVO • Next we need to specify the location of VIVO login processing /loginExternalAuth and turn on shibboleth for that file <Location /loginExternalAuth> AuthType shibboleth ShibRequireSession On require valid-user require shibboleth ShibUseHeaders On </Location>

  15. Setting up VIVO for the SSO • Most SSO pass an apache header variable once authenticated. If they don’t you’ll need to write an application to generate one based on its method of passing the authenticated users information • Set in your configuration file • external.Auth.netIDHeaderName

  16. Setting up VIVO for the SSO • Its not always easy to change styles and pages in VIVO for someone who isn’t a web designer. So instead of keeping the login text generic with “Login” we can change the text from the deploy properties file. • externalAuth.buttonText

  17. Setting up VIVO for the SSO • You need to have in your VIVO a data property populated with the identifying information that will come from your SSO. This is used to associate an individual with their profile in VIVO • Set that data property into • selfEditing.idMatchingProperty To • http://vivo.mydomain.edu/ontology/vivo-md/institutionid

  18. Questions?

More Related