I do not recommend that you tell the CAS server to pass you a login token.
Login Tokens only have meaning in the context of the web flow.

If using gateway is not sufficient for you, I would recommend that you
create a simplified form page (without decoration) and use an IFRAME to
embed the login page into your applications (similar to what Google does).
This way the only thing seeing the password is still CAS and if a session
already exists, it will detect it.

(Note the only other change you'll need to make is to use JavaScript for
redirect instead of 302 because of the way IFRAMEs work).

-Scott

On 8/1/07, Reid Morrison <[EMAIL PROTECTED]> wrote:
>
> In several places I have seen people asking about how they can supply
> their own login screen to CAS.
>
> One suggestion is covered on page 11 of :
>
> http://www.ja-sig.org/wiki/download/attachments/7824/CASClients.ppt?version=1
>
> The challenge we have run into is that the business is mandating that
> we put the username and password fields on the first screen that the
> user sees, along with other publicly available information. Once they
> login they will gain access to their private information.
>
> To address the above business requirements the following technical
> requirements need to be met:
>   1. Username and password fields on index page posting to CAS.
>   2. SSO : If the user is already signed into CAS through another Web
> Application, we must not display the username and password field on
> the screen. The private information must be immediately available
> since the user is already signed into CAS.
> 3. Any bookmarked links to completely private pages (not index) must
> be secured.
>
> These requirements can be addressed as follows:
> For 1:
> By adding a new form to the existing page these fields can be added.
>   The login ticket can somehow be obtained from CAS and the post is
> performed back to CAS, not the web application.
>
> For 2:
>   Before displaying the index page CAS server login is called to
> determine if the user is already logged in. Possibly using the
> gateway=true option for this purpose.
>
> For 3:
>   The current capabilities meet this requirement since CAS will
> intercept the page request and present it's own login screen as
> needed.
>
> A flow could be as follows:
> 1. A User requests the index page from the Web Application.
>
> 2. CAS client intercepts the request and since no session is
> established yet, it redirects the http get to CAS to determine if the
> user is already logged in. The http redirect is sent to CAS along with
> gateway=true&lt=true
>
> 3. CAS Server determines that the user is not signed in yet. Since the
> gateway=true option was supplied CAS Server does not display its own
> login page. Instead it immediately redirects the http get back to the
> service url (web application) without a service ticket.
>   Since the additional variable lt=true was supplied, the CAS server
> includes a valid login ticket in the http redirect back to the web
> application. E.g.  lt=LT-.....
>
> 4. CAS client determines that since the index page is a "semi-secured"
> page which does not require authentication it allows the screen to be
> displayed. It stores the login ticket in a session variable since it
> was supplied by the CAS server.
>
> 5. The web page determines that the user is not authenticated and
> displays the public information along with the username and password
> entry fields. Additional hidden fields are included in the form to
> hold the service URL (service) and the login ticket (lt) required by
> the CAS Server.
>
> 6. When the user enters their username and password and hits submit,
> the action is directed to the CAS Server which takes over since a
> valid login ticket was supplied. In this way the password never
> reaches the application and the cookie is properly associated with the
> CAS server.
>
>
> Is this a viable solution to the custom login page problem?
> _______________________________________________
> Yale CAS mailing list
> [email protected]
> http://tp.its.yale.edu/mailman/listinfo/cas
>



-- 
-Scott Battaglia

LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas

Reply via email to