[Building Sakai] CAS login with local login

Tue Apr 6 17:46:31 PDT 2010

See below....

On 07/04/2010, at 9:14 AM, Steve Swinsburg wrote:

With the CAS gateway feature, what happens if a person is not logged into CAS but they should be?

With the Gateway feature if the person is not recognised by CAS then they are returned to the application without being presented with a login screen. The application needs to know what to do with this. It shouldn't redirect back to CAS as this would just create a loop.

>From what I have seen, if gateway=true, and they are not logged in to CAS they will be redirected back to the host application. So they would still need to authenticate, and still need to make the decision about what authentication method to click, right?

Yep. At some point they still need to make the choice... The only major advantage here would be in catching people that are already authenticated from some other point in the System (being all the collective systems that make up your environment).

The disadvantage is that for CAS users they may be unsure of this particular login screen as it won't be familiar. (Solution two solves this)

The second method is to leave the gateway component out and add a custom login page for Sakai to CAS. (From memory) You can add an indicator to CAS to detect where the login has come from and you can customise the login page (Steve: We are going to use this approach for TLCAdmin and eSubmission). This way if the person isn't known they will still get the standard CAS login, but it will be presented with a custom login page which will provide redirects and information regarding how to login if they aren't a CAS user. This will essentially redirect them to a direct login for the app (e.g. /portal/xlogin) where they can login.

At present, an incoming request for some Sakai resource consults the CAS server to check if they are authenticated. Does this also check a local user account session? If not, it should. It is then at this point where they have no CAS ticket and no local session that some choice should be made about how to authenticate them.

So three parts.
1. Modify the CAS check so it uses the gateway feature for checking CAS, but not presenting the login box if it fails.
2. Modify Sakai so it also consults a local session to check for authentication.
3. If neither 1 or 2 succeeded, have the intermediate window where they choose how to login.

This is about right in what the user sees. Steps 1 and 2 are actually the opposite from the systems point of view (if I understand correctly).

For Gateway:
1. System receives a request
2. It checks that the request is already authenticated (and if so then authorised)
3. If the identity is not known it redirects to CAS
4. If CAS returns unknown it redirects to an un-authenticated area (to stop infinite loops) and presents a login page (you can add a non-gatewayed link back to CAS here)
5. User authenticates and continues.

I'm most familiar with the Spring security stack.

In our current system we have three different authentication methods.

HTTP Auth (Basic)
Form login (Direct application login, connected to LDAP)
and CAS

The authentication stack follows that path. CAS is the only one that the application presents. The user can then click on a link to reach the Form login.

WDYT?

cheers,
Steve

On 07/04/2010, at 8:59 AM, Gerwood Stewart wrote:

I know of two ways.

1 is use the CAS gateway feature which means CAS will be checked and if the user is NOT known (i.e. logged in) CAS will pass back to the app without forcing an authentication. This can be complex as your app then needs to capture this and provide an alternative way of logging in.

2. Is to create a customised page on the CAS login page such that the CAS login is presented as normal and text/link to an alternative login is provided on the CAS login page.

We have tested both methods in various pieces of software. Both can have issues and both will ultimately result in a user having to decide how to login. A final alternative would be to provide separate entrance points that once the login has been performed the system (not necessarily CAS) performs a SSO to Sakai. This would bypass CAS entirely.

Gerwood

On 07/04/2010, at 8:53 AM, Steve Swinsburg wrote:

You would need an intermediate page that presents the users with the options, rather than making an assumption about how to present for login credentials.

For XYZ users, login here: <button goes to CAS>
For all other users, login here: <button goes to xlogin>

That would be a pretty good enhancement to the CAS integration, configurable so that if you only have CAS users you can disable the intermediate page and do a straight passthrough to CAS.

cheers,
Steve

On 07/04/2010, at 2:45 AM, Charles Hedrick wrote:

We're in a situation where we need to use CAS for most users, but others will have to continue using local logins. There are instructions for putting two login buttons on the front page. But if you follow those, other ways into the system, e.g. following a link into /access/content, always go through CAS. Has anyone done an implementation where all logins can be done either way?

_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org<mailto:sakai-dev at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org<mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a subject of "unsubscribe"

<smime.p7s>_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org<mailto:sakai-dev at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org<mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a subject of "unsubscribe"

_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org<mailto:sakai-dev at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org<mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100407/52a0722b/attachment.html 