Using CAS without the CAS login screen

https://wiki.jasig.org/display/CAS/Using+CAS+without+the+CAS+login+screen

This page is for documenting how to use CAS without using the CAS login screen.

Why not to do this

One of the advantages CAS brings to the table is a single authentication user experience across all applications using CAS. The user doesn't have to wonder whether he should be giving his password to any particular application, because no applications other than CAS receive the password.

Implementing this hack results in applications other than CAS having access to actual usernames and passwords. This is a bad thing. It reduces the security value CAS is trying to give you.

Existing features

The CAS gateway feature allows your application to attempt to use CAS single sign on to authenticate the user without interrupting the user experience to display a CAS login screen. If no SSO session already exists, CAS simply redirects back to your service without displaying the login screen.

Other proposed solutions

• 'Using CAS from external link or custom external form' page
• 'Using CAS without the Login Screen' page
• A google group discussion

Alternative approaches

An alternative to your application rendering its own login screen is to get CAS Server to render the login screen you would have wanted to render. WIND goes this route. This is on the feature list for CAS 3.

A relatively easy option (for portals, at least) is to proxy the HTML of the CAS login page and display it inline in the portal page.  The proxied form should still submit to CAS itself.  You can tweak the CAS jsps to use different CSS styles depending on the User Agent or Remote Host, to provide a modified (e.g. smaller) login screen.

Using CAS without the login screen

Suppose you really do want your service to be handling the user's username and password.

First, produce your custom form. When your custom form submits, the recipient of the submit needs to do the following:

Validate the username and password

Somehow, you need to figure out whether this username and password are correct.

One thing to do would be to generate an HTTP request for CAS login, parse out a valid login ticket, then issue a request for CAS login posting the login ticket, username, and password. Parse the response. If it indicates a success, the username and password are valid. Otherwise not.

Another thing to do would be to go directly against whatever it is that CAS is using to validate usernames and passwords.

If the username and password didn't match, redisplay your form. If they did match, then either 1) you're done because all you wanted to do was authenticate the user, or 2) now you need to establish the CAS SSO session in the web browser and obtain a Service ticket.

Establish the SSO session and possibly get a Proxy Ticket

Again, get a login ticket and the jsessionid. Then, generate a redirect to the browser placing the sesisonid, login ticket, the username, and the password on the CAS login URL to which you're redirecting:

https: //cas.example.com/cas/login;jsessionid=XXXXXXXX?username=XXXXXXX&password=XXXXXXX&lt=XXXXXX

Specify the service to be your application where you want to receive the service ticket.

CAS will set the Single Sign On cookie so the user will have a CAS SSO session established.

Since the username, password, and login ticket are good, CAS will redirect back to your service with the service ticket. Grab the service ticket and validate it in the normal way (presumably using a CAS client). This is your opportunity to obtain a Proxy Ticket.

Note: This only works as long as the user has not visited the CAS webpage before. Otherwise he or she got a different sessionid cookie which has priority over the sessionid in the url.

Experience Reports 

Here is an experience report on how an UI-less mode for CAS has been achieved using javascript only on the client side. Passwords are only handed over to the SSL secured CAS service, not to a third party.