google-code-export / rubycas-client

Automatically exported from code.google.com/p/rubycas-client
1 stars 1 forks source link

CAS Login with gateway #3

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
In a Ruby on Rails application the requirement has arisen to allow the
index action of a controller to display public information without
requiring authentication. On this same screen a link will be displayed
allowing users to sign in. After signing in, the index action should now
display private information for that particular user on the same page.

According to the write-ups on the CAS JA-SIG site, this is a requirement
that Yale themselves have implemented.
  See page 11 of
http://www.ja-sig.org/wiki/download/attachments/7824/CASClients.ppt?version=1

After enabling the gateway option (CAS::Filter.gateway = true) we run into
a condition where the rubycas-client goes into a loop with the CAS server.
 I.e. Client redirects to Login and server redirects back, ...

We want to keep CAS as the authentication server, but allow pages to be
public with optional private data.

Before making any changes I would need to better understand the current
implementation of the gateway mechanism. 

Any guidance would be appreciated.

Original issue reported on code.google.com by ruby...@gmail.com on 30 Jul 2007 at 1:53

GoogleCodeExporter commented 9 years ago
I'm not sure if using the CAS gateway functionality is the best way to do this. 
We
have an identical scenario where we do something like this in a controller:

before_filter CAS::Filter, :except => [:inde, :login]

protected
def is_authenticated?
  not session[:casfilteruser].nil?
end
helper_method :is_authenticated?

You can then use is_authenticated? in your views to check if the user has been
authenticated and render private content accordingly.

There are many other ways to do this however (for example you could have a 
filter
chain where a subsequent filter would load a User model based on :casfilteruser 
into
an @user variable that you could then access in your views...)

Does this answer your question?

Original comment by matt.zuk...@gmail.com on 30 Jul 2007 at 5:50

GoogleCodeExporter commented 9 years ago
The drawback we ran into is that if a user is already signed into CAS through 
another
Web Application, it will show on the screen that they are not logged in yet and 
need
to log in to display additional information. When the user attempts to login, 
CAS
determines that they are already logged in and the index page just re-displays 
with
the private information visible. From our end users perspective, it does not 
provide
true Single Signon for all their Web Applications.

Would it be possible to implement a specialized filter for pages/actions that 
can be
"gateway-ed" vs the private/secured pages ?

Original comment by ruby...@gmail.com on 31 Jul 2007 at 5:30

GoogleCodeExporter commented 9 years ago
Gatewaying has been fixed in the client in the latest svn revision.

You can use gatewaying the normal way (by setting CAS::Filter.gateway = true) 
but for
your purposes it probably makes more sense to use the new GatewayFilter. For 
example,
you could do this:

  before_filter CAS::Filter, :except => [:index]  
  before_filter CAS::GatewayFilter, :only => [:index]

Now your index view is protected using a gateway'ing filter and all other views 
use
the normal, restrictive filter.

Original comment by matt.zuk...@gmail.com on 1 Aug 2007 at 11:14