This blog talks about how to Enable CAS in Different Applications

What is CAS

The Central Authentication Service (CAS) is a single sign-on protocol for the web. It’s purpose is to permit a user to access multiple applications while providing their credentials (such as userid and password) only once. It also allows web applications to authenticate users without gaining access to a user’s security credentials, such as a password. The name CAS also refers to a software package that implements this protocol.

The CAS protocol involves at least three parties: a client web browser, the web application requesting authentication, and the CAS server. It may also involve a back-end service, such as a database server, that does not have its own HTTP interface but communicates with a web application.

When the client visits an application desiring to authenticate it, the application redirects it to CAS. CAS validates the client’s authenticity, usually by checking a username and password against a database (such as Kerberos or Active Directory).

If the authentication succeeds, CAS returns the client to the application, passing along a security ticket. The application then validates the ticket by contacting CAS over a secure connection and providing its own service identifier and the ticket. CAS then gives the application trusted information about whether a particular user has successfully authenticated.

CAS allows multi-tier authentication via proxy address. A cooperating back-end service, like a database or mail server, can participate in CAS, validating the authenticity of users via information it receives from web applications. Thus, a webmail client and a webmail server can all implement CAS.

How CAS Works

1. A user, via a web browser, requests a resource from a particular web application/service.
2. The web application/service (via the application’s security mechanism) determines if the user has already been authenticated and authorized to use the application. How the web application does this it up to the web application itself. This is not part of CAS, but it is an important part of web application security. It should be noted that all applications should implement local sessions for managing the interaction between the application and the user. In other words, the application should not interact with CAS for every request made to the application. This would be an inappropriate use of the CAS service. Of course, if a user comes to the web application and the application does not know who the user is, then the application should redirect the user to CAS.

If the user has a local session (authN and authZ) then the user can have access to the resource which was requested.

3. If the user does not have a local session, then the web application should check to see if the URL contains a CAS ticket. If the URL does not contain a CAS ticket (e.g., …? ticket= QQIMux0k2Em), then the web application needs to redirect the browser to CAS so that the user can get a ticket.
4. Once the user’s browser gets to CAS, CAS looks to see if the user has already authenticated with CAS. It does this by looking to see if the browser sent a CAS cookie with the request. If the user does not have a cookie, i.e., they have not already authenticated, and then CAS displays the user with the login screen.

Upon successful authentication, CAS will look up the user in the LDAP Directory and store the user’s UID in its memory for future reference. After it has done this, it will set a CAS cookie in the user’s browser (this is called a Ticket Granting Cookie), and then redirects the user back to the original service with a ticket.

This ticket is only valid for the service to which CAS redirects the browser, and can only be used once. Also, the ticket is tied to the UID mentioned above.

5. Once back at the application, the security component of the web application goes through steps 2 and 3 again. This time, however, on step 3, the web application sees that the URL has a ticket. At this point, the web application needs to take that ticket and verify with CAS that it is a legitimate ticket.

Here, the web application makes an https request to CAS (no browser is involved in this transaction). (Note, this can only happen over SSL.)

6. When CAS receives this request, it validates the ticket with the following two tests:

1. Is this the first time this ticket is being presented back to CAS?
2. Is the ticket actually valid for the service listed in the URL?

If both tests are true, then CAS looks up the UID that is associated with the ticket (this was set in step 4) and responds back to the application with a success response and includes the UID of the user.

If either 1 or 2 are false, CAS responds back to the application with a failure response.

As mentioned in step 4, a ticket is only valid for a particular service, and is only valid once. For instance, you would get the failure message above if you took a ticket and asked CAS twice if it is valid. On the first attempt it would be valid – because it was the first time CAS was presented with the ticket – however, on the second attempt, it would not be valid because it was already used. This is done for security reasons.

Integrate CAS With Applications

Install JA-SIG CAS

1. Download the CAS server distribution. All the (recent) downloads are available here)either zip or tar)

http://www.jasig.org/cas/download

2. Exploding that tar.gz, I grabbed the cas-server-3.4.5/modules/cas-server-webapp-3.4.5.war
3. Rename the file to cas-web.war.
4. Copy the war file and paste it to the Tomcat webapps directory.
5. Hit http://localhost:8080/cas-web in browser. You will see CAS Login screen.

Integrate CAS with Liferay

1. Open Liferay Portal.
2. Login as Admin user.
3. Select Go To à Control Panel.
4. Select Portal Settings in Portal panel from your left side menu.
5. Select Configuration à Authentication from your right side menu.
6. Select CAS tab.
7. Fill the required information:

1. Save.
2. Logout from Liferay. You will see CAS logout screen.
3. Enter Liferay server url (Click on Sign-in if you don’t see CAS login Screen). Enter username and password.

NOTE: This CAS Server is running on “5080” port and using “username=password” technique. So when you go through this process you have to enter your password same as username. Otherwise, if you need, you can change your CAS login algorithm or you can authenticate against LDAP also.

Best Open Source Business Intelligence Software Helical Insight is Here

A Business Intelligence Framework

Free
Download