{"id":15018,"date":"2018-04-10T17:10:06","date_gmt":"2018-04-10T17:10:06","guid":{"rendered":"https:\/\/ephesoft.com\/docs\/?page_id=15018"},"modified":"2020-12-03T14:48:11","modified_gmt":"2020-12-03T21:48:11","slug":"sso-cas-based-sso-framework","status":"publish","type":"docs","link":"https:\/\/ephesoft.com\/docs\/products\/transact\/configurations\/user-connectivity\/single-sign-on-resources\/sso-cas-based-sso-framework\/","title":{"rendered":"SSO | CAS-Based SSO Framework"},"content":{"rendered":"

SSO (Single Sign-On) is a mechanism of\u00a0access control\u00a0that can be applied on multiple related but independent\u00a0software\u00a0systems. This way, a user\u00a0logs in\u00a0once and gains access to multiple systems without being prompted to log in again for each individual application.<\/p>\n

Previously, the SSO mechanism in Ephesoft Transact only supported integration of the SAML-enabled Spring Security framework. For more information on this feature, refer here<\/a>.<\/p>\n

In Transact 4.5.0.0, SSO functionality can also be implemented on the basis of CAS (Central Authentication Service). Now, you can configure Transact with Spring Security and CAS, both with and without CAS proxy support.<\/p>\n

CAS (Central Authentication Service)<\/strong><\/h2>\n

CAS is an Enterprise Java solution for web application authentication that also provides the benefit of Single Sign-On (SSO). Technically, SSO can be achieved because the authentication can be removed from the web application and handled centrally. And, when this authentication is handled by a single service, access to many services can be granted once and “remembered” for the life of the web session or even longer. Keep in mind that the SSO feature does not have to be employed and yet CAS authentication still provides a reliable authentication mechanism.<\/p>\n

CAS Server<\/strong><\/h3>\n

The CAS server is a Java servlet built on the Spring Framework. Its primary responsibility is to authenticate users and grant access to CAS-enabled services, commonly called CAS clients or services, by issuing and validating tickets. An SSO session is created when the CAS server issues a ticket-granting ticket (TGT) to the user upon successful login. A service-ticket (ST) is issued to a service at the user\u2019s request via browser redirect using the TGT as a token. The ST is subsequently validated at the CAS server via back-channel communication. Ephesoft Transact also supports proxy-granting-ticket (PGT), in which the server issues a PGT to Transact. Transact uses this PGT to create proxy tickets for accessing other web applications under the same authentication umbrella.<\/p>\n

CAS Clients<\/strong><\/h3>\n

The term \u201cCAS client\u201d has two distinct meanings in its common use. A CAS client is any CAS-enabled application that can communicate with the server via a supported protocol. A CAS client is also a software package that can be integrated with various software platforms and applications to communicate with the CAS server via some authentication protocol (e.g. CAS, SAML, OAuth). In our case, Ephesoft is a CAS client that communicates with the CAS server for the purpose of authentication and SSO.<\/p>\n

CAS with Proxy Support<\/strong><\/h3>\n

If proxy support is required, the CAS client requests a proxy-granting-ticket (PGT) rather than a normal service-ticket (ST). Using this proxy ticket, the CAS client can securely communicate with other CAS clients under the same CAS SSO umbrella. This rapidly increases the performance of the CAS client when communicating with other CAS clients under this umbrella because the CAS client with PGT no longer needs to request an ST for each request to other CAS clients. Configuring the CAS client with proxy support should be handled carefully as improper configuration may lead to a security breach. Proper configuration steps and suggestions are provided below.<\/p>\n

CAS without Proxy Support<\/strong><\/h3>\n

CAS without proxy support should be used when there is only a single application under the SSO umbrella or when the system does not require communication between CAS clients under the same umbrella. When CAS is used without proxy support, the CAS client works on a service-ticket (ST) granted by the CAS server. This configuration is preferable if the situation does not require proxy support as it is less vulnerable to a security breach.<\/p>\n

Configuring CAS-based SSO mechanism<\/strong><\/h2>\n

The following files must be configured:<\/p>\n