Single Sign-On Led by Terrice McClain, Jen Paulin, & Leighton Wingerd Adirondack Solutions Users Group 2017 Single Sign-On Led by Terrice McClain, Jen Paulin, & Leighton Wingerd Monday 1:00PM – 2:00PM

Agenda What is Single sign-on? Why Single Sign-On? Which SSO Options are Supported? How It Works Basic “How-To” Hosted Clients On-Premise Clients

What is Single sign-on Single sign-on is a user/session authentication process that permits a user to enter one username and password in order to access multiple applications. The process authenticates the user for all the applications they have been given rights to and eliminates further prompts when they switch applications during a particular session. 

Why Single Sign-On SSO Provides Better Security Centralized enforcement of password policy Centralized lockout One password to remember Improve user experience Same login page across all web applications that use SSO Login once, access many applications Reduce operational cost Ease burden on developers

Which SSO Options are Supported? Adirondack Solutions supports other authentication methods as well, including: CAS Pass-through (for self-service products, only) Banner Self-Service Integration (for self-service products, only) Ellucian Ethos Identity Management Active Directory LDAP SAML ADFS Shibboleth CAS Pass-through Custom Banner Self-Service

Caveats SAML Authentication Assuming Id Provider (IdP) and Service Provider (SP) already installed and operational Using primarily Shibboleth terminology Authentication versus Authorization

How To: Hosted Clients SAML Authentication Submit an eSupport request to initiate the process Information needed for setup: IDP URL Meta Data Attribute that contains the username ASI Staff completed configuration and provides meta data URL ASI and client staff coordinate testing for each environment and application involved

How It Works SAML Authentication Web site placed under the Shibboleth/ADFS umbrella If credentials are not present on page request, browser is redirected to SSO login page On successful authentication, browser is redirected to original page request with credentials Page requested must detect proper user attribute and determine authorization accordingly

Caveats CAS Authentication If required the service url must allowed on the CAS server and IP address of the application server allowed to send request for authenication. The process is designed to work with CAS version 2.0 and 3.0

How It Works CAS Authentication Web site has to be configured to authenticate with the CAS server. If credentials are not present on page request, browser is redirected to SSO login page On successful authentication, browser is redirected to original page request with credentials Page requested must detect proper user attribute and determine authorization accordingly

How To: Hosted Clients CAS Authentication Submit an eSupport request to initiate the process Information needed for setup: CAS Server URL Attribute that contains the username ASI Staff completed configuration and provide CAS service URL ASI and client staff coordinate testing for each environment and application involved

Pass-through Authentication Caveats Pass-through Authentication Sometimes requires custom coding Requires familiarity with tools such as web-advisor, share-point or web-tailor

Pass-through Authentication How It Works Pass-through Authentication Link or button to THD Self-Service is configured in the web-portal Token information such as time, key and Student number are hashed passed to THD Self-Service. THD Self-Service confirms that the hash is valid and that it is within the allotted time limit. URL or Hidden variables are Pass-through to allow access.

Pass-through Authentication How To: Hosted Clients Pass-through Authentication Submit an eSupport request to initiate the process Information needed for setup: Identify web-portal system Agree on shared variables and key Attribute that contains the username ASI Staff completed configuration and provides meta data URL ASI and client staff coordinate testing for each environment and application involved

How To: On-Premise Clients Edit Index.cfm to check CGI attributes Create supplemental authorization script Create SSO user in database Create startup HTML file Edit DataSourceName.cfm to use the supplemental authorization script Place web site under Shibboleth/ADFS umbrella

Contact Information Thank you for participating! Should you have any questions regarding this presentation, please use the contact information below: Terrice McClain, terrice@adk.tech, 800.372.3165 x 212 Jen Paulin, jen@adk.tech, 800.372.3165 x 215 Leighton Wingerd, leighton@adk.tech, 800.372.3165 x 211