Single SIgn-On Central Authentication Service (CAS)

Ad Astra supports single sign-on (SSO) using either SAML 2.0 or Central Authentication Service (CAS).  The following information will help in setting up SSO. 

This article will cover the Central Authentication Service (CAS), for SAML 2.0 see the Single Sign-In SAML 2.0 article.

The CAS server can be downloaded from https://www.apereo.org/projects/cas/download-cas.

System Settings

There are two required and two optional Ad Astra system settings, shown below, that are available for configuring a single sign-on.

Required Settings

Two system settings must be added to the Ad Astra System Settings table.  (See System Settings for more information on how to configure these settings) You will need to update the value of the VALUE field to point to the CAS server.

1. security.sso.option: Disabled, CAS, CWL (case insensitive).  If this setting does not exist, it is the same as being set to Disabled.
2. security.sso.authenticationURL: Root URL for SSO service. Ex: http://casserver:8080/cas/

Optional Settings

Two settings are available to configure sign-out behavior when SSO is enabled.

• ShowLogoutLink: Set this to false to hide the logout link when SSO is enabled. If this setting does not exist, it defaults to true.
  
  If this option is used, then the user's session will not end until it times out.
• security.sso.logoutURL: Use this setting to specify a URL to which a user will be redirected upon signing out of Ad Astra.
  
  This will look something similar to: "http://casserver:8080/cas-server-webapp-3.5.0/logout?service=http://www.page-to-go-on-logout.htm".
  • The /logout tells CAS to end the CAS session.
  • The service parameter tells CAS to redirect to the page specified after ending the CAS session.

To use logout redirection in CAS, the CAS server must be configured.  The p:followServiceRedirects="true" attribute must be added to the logoutController bean in the cas-servlet.xml file located in the cas-server-webapp-3.5.0\WEB-INF folder under the webapps folder in Apache Tomcat.

If the security.sso.logoutURL is blank or missing, the default behavior for CAS will be to redirect the user to the CAS login page after they sign out of Ad Astra.

Passing CAS ticket from the homepage to Ad Astra

The homepage can link to any Ad Astra page.  It needs to append the user’s ticket to the URL in the parameter named “ticket”.

Examples

Link to Ad Astra user's homepage:

http://astrawebserver/astraschedule/default.aspx?hometicket=798798SDF89009SDFSDF2JKI9F

Link to Ad Astra Academics main page:

http://astrawebserver/astraschedule/academics/default.aspx?ticket=798798SDF89009SDFSDF2JKI9F

Link to the Event List page:

http://astrawebserver/astraschedule/events/eventlist.aspx?ticket=798798SDF89009SDFSDF2JKI9F

URLs would be used by Ad Astra to interface with CAS

(CAS_ticket is replaced with the ticket passed to Ad Astra, and ReturnURL is replaced with the Ad Astra URL accessed by the user)

Validate Ticket Passed to Ad Astra
http://casserver:8080/cas/serviceValidate?ticket=CAS_ticket&service=ReturnURL

CAS Login – if user attempts to access Ad Astra without a CAS ticket
http://casserver:8080/cas/login?service=ReturnURL 

Guests and Invalid Sign In

If the user is authenticated by CAS but does not exist in Ad Astra, the user is allowed to access Ad Astra as a guest user.

If the ticket passed to Ad Astra is not valid, the user is directed to the Ad Astra sign-in page. 

Bypass Single Sign-On

To bypass the single sign-on mechanism for sites that are configured for SSO, the user may use the URL for the sign-in page with the nosso URL parameter.  This may be useful if there are internal users that do not use SSO.  Because of this feature, it is important to assign a strong password when creating users.

Ex: http://astrawebserver/Logon.aspx?nosso=

Trusted Certificates and SSL 

You may need to update the trusted certificate authorities if you are using SSL to communicate between Ad Astra and CAS and are using a certificate that was not issued by one of the major certificate issuers (VeriSign, Thawte, GlobalSign, etc).  You can update the trusted certificate authorities on the webserver using the Certificates snap-in.  This should allow you to resolve any issues with HTTPS. See Microsoft's instructions for accessing the Certificates snap-in.