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.
Astra Schedule and Platinum Analytics can act as a Service Provider (SP) to integrate with an Identify Provider (IdP) using the SAML 2.0 protocol. The SAML 2.0 protocol allows for federated authentication between two parties without the need of a direct VPN connection between Ad Astra and the Identity Provider.
Capabilities for SAML 2.0 Authentication
- Redirection of users upon logon to an Identity Provider for authentication (SP-initiated Single Sign-On)
- Support for SAML 2.0 Redirect and POST bindings
- Redirection of users upon logoff to the Identity Provider to terminate IdP sessions (SP-initiated Single Sign Off)
- Requires a sign-off URL to be supplied to Ad Astra
- User binding – Identity Provider users can be bound to Astra users in the following ways:
- Map an entire SAML attribute value to a username by specifying the Object Identifier (OID) for the attribute
- Map a portion of a SAML attribute value to a username by using the OID along with a regular expression and matching group (e.g. Group #1 with regex string "(.)(@)(.)" to separate "mailbox" from value email@example.com
- If the user is authenticated by an IdP but does not exist in Astra Schedule or Platinum Analytics, an Astra Schedule user is created with a default role. The default role is established during SSO configuration.
SAML 2.0 Integration Process
SAML 2.0 requires an an initial metadata exchange for trust purposes. Ad Astra can exchange metadata either directly or via participation in InCommon.org.
- IdP metadata:
- Submit your IdP metadata (via URL) or directly to Ad Astra support to initiate the Integration Process.
- Ad Astra SP metadata:
- Available via request for Astra Schedule 8 or Platinum Analytics instances.
- Unique for each URL under https://aaiscloud.com, so production and test systems will require different SP metadata.
- SP metadata for Ad Astra can be retrieved via REST api once the initial configuration is complete.
Contact the Ad Astra support team for assistance with setting up SAML 2.0 authentication.
Central Authentication Service (CAS)
The CAS server can be downloaded from https://www.apereo.org/projects/cas/download-cas.
There are two required and two optional Ad Astra system settings, shown below, that are available for configuring single sign-on.
Required: 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.
- sso.option: Disabled, CAS, CWL (case insensitive). If this setting does not exist, it is the same as being set to Disabled.
- sso.authenticationURL: Root URL for SSO service. Ex: http://casserver:8080/cas/
Optional: two settings are available to configure logout 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.
- sso.logoutURL: Use this setting to specify a URL to which a user will be redirected upon logging out of Ad Astra.
This will be something like 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 log out of Ad Astra.
Passing CAS ticket from homepage to Ad Astra
The homepage can link to any Ad Astra page. It just needs to append the user’s ticket to the URL in the parameter named “ticket”.
Link to Ad Astra user’s homepage
Link to the Academics Main Page
Link to the Event List Page
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
CAS Login – if user attempts to access Ad Astra without a CAS ticket
Guests and Invalid Logins
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 login 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 login 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.
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 web server using the Certificates snap in. This should allow you to resolve any issues with HTTPS. See http://msdn.microsoft.com/en-us/library/ms788967.aspx for instructions for accessing the Certificates snap in.