On Mon, 8 Jun 2015, Christian Rohmann wrote:
Hello cas-user,
being new to CAS, I spent quite some time reading through the
documentation and trying out a few things. Please excuse me though, if I
am suggesting or asking anything that has been discussed before or where
a solution already exists. I am more than thankful for a point in the
right direction in this case.
I am yet another one of those nagging folks, trying to serve the main
login page from another machine, but use CAS to do everything
authentication and session management wise.
Apart from changing the appearance of the page itself, there are
multiple ways to "replace" the built-in login screen with something else:
* https://wiki.jasig.org/display/CAS/Using+CAS+without+the+Login+Screen
*
https://wiki.jasig.org/display/CAS/Using+CAS+from+external+link+or+custom+external+form
* ...
All of those attempts do a similar thing, they "abuse" the cas login
page and fetch the necessary values such as
* lt (login ticket)
* execution (Spring WebFlow ID)
* JSESSIONID
in a first request (JS in the client browser or doing some prefetching
using PHP or whatever).
Parsing a nicely rendered webpage which is created to be seem by humans
and might change at any point in time, simply to fetch two values seems
really like a dirty little hack. Extracting the JESSIONID from the
cookies and to send it via URL variable later, makes things even
nastier. Don't even let me get into the error handling ...
The fact that people are still doing this indicated two things to me:
1. Custom login pages are really really wanted
2. CAS is still the way to go backend-wise, no doubt
this ultimately means, the strong bond between UI frontend and CAS
backend is somewhat the issue here. Every other CAS-enabled service uses
an simple API to validate Service Tickets or do whatever. Why not enable
the initial authentication to be properly done via API as well?
I found there are two REST APIs, an older, deprecated one in class
org.jasig.cas.integration.restlet and a current one in class
org.jasig.cas.support.rest. There is a big warning regarding the
security implications of opening up the REST API to the public. This
warning seems quite accurate as usage of the API does not involve any
use of login tickets or matters to fight replaying of credentials. Also
there is no rate limiting on the requests.
But since there are frequent attempts to create own login pages and
people do abuse the CAS login page to fill their own web forms, why not
extend the REST API to make this an easy and robust setup?
A simple method like createUniqueLogin to fetch lt, execution, JESSIONID
and what ever is necessary via REST and later submit those together with
the credentials? Certainly this API would then be restricted to only be
accessed by the front-end servers, not directly by a user (brute force
attacker).
Then it becomes easy to create a fully compatible and secure CAS login
page and to properly validate a login request and then serve a TGT out.
Depending on other requirements regarding access to CAS service-APIs,
this could enable CAS to be a backend service not accessible to users.
What are your thoughts on the matter?
It's really easy to write your own login page within CAS by modifying jsp
and CSS files. We do it here at OSU:
https://login.oregonstate.edu/cas/login
What is the purpose of hosting the login page outside of CAS?
Andy
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
