Q1: What is the enterprise Central Authentication Service (CAS)?
A1: CAS is Rutgers’ official Single Sign-on authentication service standard for all web based application. University-wide adoption of CAS improves Rutgers’ overall security, its ability to effectively provision and de-provision users, and positions the institution to reduce the threat of phishing attacks by deploying two factor authentications to protect sensitive data.

Q2: What is Single Sign-on (SSO)?
A2: Users will be able to initiate SSO from any CAS protected web application throughout the University. The users only provide valid credentials (NetID & Password) at the first time the authentication session starts and will not be prompted for authentication again when switching web applications during the same session.

Q3: What applications are in SCOPE, required to be integrated with CAS?
A3: In scope web applications required to use CAS are those that provide access to University data classified as Restricted or Internal (see Information Classification Policy 70.1.2 appendix). This includes any third party developed, in-house developed, enterprise, unit, and school specific web applications. Cloud based hosted applications as a service will integrate with CAS via integration with Rutgers’ Federation authentication service (Shibboleth).

Q4: What applications are NOT in SCOPE, not required to be integrated with CAS?
A4: Non-web based applications and infrastructure interfaces and consoles.

Q5: What if a web application does not yet use enterprise CAS or enterprise LDAP to authenticate users?
A5: By July 31, 2015 University web applications that do not use enterprise CAS or enterprise LDAP to authenticate users must be registered with OIT using OIT’s Application Registration Site. By February 1, 2016: All units, including those currently using enterprise LDAP, will be required to convert their web applications to use the enterprise CAS standard.

Q6: What if a web application uses enterprise LDAP but does not yet use enterprise CAS?
A6: By February 1, 2016: All units, including those currently using enterprise LDAP, RBHS LDAP, or RBHS CAS, will be required to convert their web applications to use the enterprise CAS.

Q7: What if a third party hosted (cloud) web application as a service has not yet been integrated with enterprise CAS?
A7: As of February 1, 2016, third-party (cloud) hosted web applications as a service will be required to integrate with Shibboleth, the University’s federation solution with is integrated with CAS. If the vendor cannot comply, OIT’s Information Protection and Security must be consulted and must approve the use of the application’s authentication procedures.

Q8: What authentication protocols does CAS support?
A8: CAS currently supports OAuth, SAML, REST API, etc. It supports two-factor (2FA) authentication using DUO (https://www.duosecurity.com/).

Q9: What level of redundancy is there for enterprise CAS?
A9: Enterprise CAS has multiple instances on the Cloud, as well as, multiple instances in Rutgers on premise data centers.

Q10: What needs to be submitted to integrate a web application with CAS?
A10: The application owner will need to submit a request and accept the CAS Terms of Service. You can find this information in Request Access.

Q11: What are CAS terms of service?
A11: The Identity Management team with the consultation of the Information Protection and Security group (IPS) has published CAS terms of service that the applications are required to adhere to. You can find this in Terms of Service.

Q12: Can a web application opt-out users accessing their web application with a SSO session?
Q12: If a web application owner believes their CAS protected application should not participate in Single Sign-on, justification for an exception can be submitted for review and an executive management decision at this web page. Submit a CAS request. If approved, the application can opt-out their users from SSO in the authentication filters of the CAS agent.

Q13: As a good security practice, applications are recommended to provide an application log-out and have an inactive session time-out. Upon a user session end with an application, the application should provide a notice that for security purposes the user should close the web browser when done accessing services that require authentication. In addition at an application session end (log-out & timeout), the application should provide for the end user an option to CAS SSO log-out (i.e. provide the link https://cas.rutgers.edu/logout). Do you have a sample page of what should be presented?
A13: Yes, see this example.

Q14: In addition to the local web application log-out, can a web application also automatically invoke CAS log-out?
A14: No, automatically invoking CAS log-out web flow, unexpectedly for the end user, breaks the SSO experience and users would be required to re-authenticate to the next new CAS protected application not yet accessed in their current web browser session. Instead a web application’s log-out screen should provide for the end user an option to CAS SSO log-out (i.e. provide the link https://cas.rutgers.edu/logout). See this example.

Q15: Is there a test CAS instance to test integration?
A15: Yes, CAS test instance: https://test-cas.rutgers.edu/.