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? Regards Christian -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
