Discussion:
How to use custom login page instead of CAS login page?
Chandramohan
2009-03-03 05:16:58 UTC
Permalink
Hi,



I have been googling from last 2 weeks to get my application
integrated with CAS.



Specific Requirements:

1. I do not want show the CAS login page, user should get logged-id /
CAS authenticated using applications custom login page.

2. As the user is CAS authenticated at the time of login, all the
secured page will be available to it.

3. I can not modify CAS server, I am writing only CAS client.



I have tried all the available solutions given on net.

1. Using Iframe

If the server and client are in different domain then how can clients
JSP access the objects of CASLogin form.

2. Using HttpClient

AS Server dose not create the required cookies but returns the ticket.
If client creates the cookies, server fails to identify them

3. Using ACEGI

There is no way to bypass the CAS login page, but still get CAS
authenticated.



Can any buddy please throw some light on this? Please send some sample
code, if possible.



I am using CAS server 2.x and CAS client 2.1.x

Can any buddy please throw some light on this?

Please send some sample code if possible.



Thanks and Regards,

Chandramohan
--
You are currently subscribed to cas-user-***@public.gmane.org as: gcjjcu-cas-Uylq5CNFT+***@public.gmane.org
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Bruno
2009-03-04 14:32:19 UTC
Permalink
Read INSTALL.txt that came with the server. You have to customize a few JSPs and rebuild. You also have to modify WEB-INF/deployerConfigContext.xml to configure how CAS will authenticate the username/password.

If you have trouble rebuilding with Maven, try importing the WAR into your IDE and skip Maven. In that case you have to manage the WEB-INF/lib JARs needed for the authentication mechanism you choose.
--
You are currently subscribed to cas-user-***@public.gmane.org as: gcjjcu-cas-Uylq5CNFT+***@public.gmane.org
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Andrew Feller
2009-03-04 14:55:31 UTC
Permalink
You only have to change deployerConfigContext if you want users to provide
credentials other than username and password.

To customize how the login page looks, you simply need to modify the
/WEB-INF/view/jsp/<view name>/ui/casLoginView.jsp accordingly.

If you want to use a completely different file for the login page, then you
need to store it within /WEB-INF/view/jsp/<view name>/ui/ and update your
view's properties file in /WEB-INF/classes/<view name>.properties. There
should be a property called "casLoginView.url" that will need to be updated
to this new file.

A-
Post by Bruno
Read INSTALL.txt that came with the server. You have to customize a few JSPs
and rebuild. You also have to modify WEB-INF/deployerConfigContext.xml to
configure how CAS will authenticate the username/password.
If you have trouble rebuilding with Maven, try importing the WAR into your IDE
and skip Maven. In that case you have to manage the WEB-INF/lib JARs needed
for the authentication mechanism you choose.
--
Andrew Feller, Analyst
LSU University Information Services
200 Frey Computing Services Center
Baton Rouge, LA 70803
Office: 225.578.3737
Fax: 225.578.6400
--
You are currently subscribed to cas-user-***@public.gmane.org as: gcjjcu-cas-Uylq5CNFT+***@public.gmane.org
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Nathan Kopp
2009-03-04 23:39:27 UTC
Permalink
Using an iframe on the same domain might be your only choice.



To accomplish this, we use a technique where the login form is served by
the client web site and simply posts the username and password directly
to the CAS server along with the "service" parameter. We're using CAS
3.0.x, so the login ticket ("lt") isn't actually required, allowing this
to work. Since you are using CAS 2.x, the "lt" parameter is required,
so this won't actually work without modifying the server code,
unfortunately. Also, we did modify the CAS server (which you want to
avoid) by causing it to redirect the user back to the client page (with
a special query parameter) if the username and password are incorrect.
However, we handled this by only modifying the JSP page, not class
files, by detecting the referrer header and redirecting back to that
URL.



We can use this in conjunction with "gateway" authentication to allow
the system to recognize users who have already logged in.



-Nathan



From: Chandramohan [mailto:ChandramohanM-ce6H5ZEQk3aaMJb+***@public.gmane.org]
Sent: Tuesday, March 03, 2009 12:17 AM
To: cas-user-***@public.gmane.org
Subject: [cas-user] How to use custom login page instead of CAS login
page?





Hi,



I have been googling from last 2 weeks to get my application
integrated with CAS.



Specific Requirements:

1. I do not want show the CAS login page, user should get
logged-id / CAS authenticated using applications custom login page.

2. As the user is CAS authenticated at the time of login, all
the secured page will be available to it.

3. I can not modify CAS server, I am writing only CAS client.



I have tried all the available solutions given on net.

1. Using Iframe

If the server and client are in different domain then how can
clients JSP access the objects of CASLogin form.

2. Using HttpClient

AS Server dose not create the required cookies but returns the
ticket. If client creates the cookies, server fails to identify them

3. Using ACEGI

There is no way to bypass the CAS login page, but still get CAS
authenticated.



Can any buddy please throw some light on this? Please send some
sample code, if possible.



I am using CAS server 2.x and CAS client 2.1.x

Can any buddy please throw some light on this?

Please send some sample code if possible.



Thanks and Regards,

Chandramohan
--
You are currently subscribed to cas-user-***@public.gmane.org as:
nathan.kopp-K/e5JtR/***@public.gmane.org

To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed to cas-user-***@public.gmane.org as: gcjjcu-***@gmane.org
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Michael Ströder
2009-03-05 00:58:56 UTC
Permalink
Post by Nathan Kopp
To accomplish this, we use a technique where the login form is served by
the client web site and simply posts the username and password directly
to the CAS server along with the “service” parameter.
Hmm, one should think about some security implications of such an
approach...

Ciao, Michael.
--
You are currently subscribed to cas-user-***@public.gmane.org as: gcjjcu-cas-Uylq5CNFT+***@public.gmane.org
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Nathan Kopp
2009-03-06 03:52:43 UTC
Permalink
Actually, we did consider security implications of posting directly from the remote site to the CAS server. This approach theoretically opens up additional risk for phishing attacks, but actually most users would be just as susceptible to phishing attacks when the standard CAS redirect protocol is used. For example, how often do you REALLY double-check the URL in your browser's address bar when you're logging into your own CAS implementation? I know I personally don't check it very often. (For that matter, I trust that "www.gmail.com" will correctly redirect me to "google.com/accounts" and I almost never check the address bar on Google.) Avoiding phishing is all about user training, and users can probably be trained to recognize phishing in context of this technique as effectively as they could with respect to the standard CAS redirect implementation.

The most "real" additional risk, I think, is the risk of replay attacks because the "lt" parameter is not included. We are currently only using this technique with a single site for a proof-of-concept, so we will be considering ways to mitigate the risk of replay as we look towards the possibility of more widespread use. One option is to use a REST API to fetch a login ticket, possibly with JavaScript using cross-domain AJAX techniques to fetch the login ticket right before the form is submitted. Another possibility is to use a timestamp instead of "lt", and putting a narrow validity window around the timestamp.

While I have considered a number of scenarios and identified these two risks, I would be interested in hearing if others can uncover additional ways that this technique would introduce additional security risks.

-Nathan

-----Original Message-----
From: Michael Ströder [mailto:***@stroeder.com]
Sent: Wednesday, March 04, 2009 7:59 PM
To: cas-***@lists.jasig.org
Subject: Re: [cas-user] How to use custom login page instead of CAS login page?
Post by Nathan Kopp
To accomplish this, we use a technique where the login form is served by
the client web site and simply posts the username and password directly
to the CAS server along with the “service” parameter.
Hmm, one should think about some security implications of such an
approach...

Ciao, Michael.

--
You are currently subscribed to cas-***@lists.jasig.org as: ***@ccci.org
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user


--
You are currently subscribed to cas-***@lists.jasig.org as: gcjjcu-***@gmane.org
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/
Loading...