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<=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
