Feature #2782

Authentication:add support for external authentication in the back form

Added by Laurent Opprecht almost 12 years ago. Updated about 11 years ago.

Feature implemented
Laurent Opprecht
Target version:
Start date:
Due date:
% Done:


Estimated time:


There are two screens to log into Chamilo: the front - homepage - screen and back screen hit when a user tries to access a url he has no access to.
The front screen can be customized - i.e. for shibboleth - but not the back screen.
This is needed for example if we want to access a widget from an external portal and there is no login.

  • allow to customize the back screen
  • allow to do autologin for shibboleth for ex.



Updated by Hans De Bisschop almost 12 years ago

Not too familiar with Shibboleth, but what you're describing seems (at least to my knowledge) to be already the case for the CAS external authentication. Every single component / page that requires authentication will automatically autologin if there's already a valid CAS SSO-session. Might I be correct in assuming that it boils down to whether the user has to explicity select Shibboleth to authenticate or is it also done in an automated way?

There is another issue embedded in this though: in some cases the system still acts as if the user is supposedly not logged in and therefore has no access. This should be clearly differentiated from actually not being logged in and just not having the necessary (access) rights.


Updated by Laurent Opprecht almost 12 years ago

Well maybe I should have looked a little bit more at how chamilo supports CAS but here are the issues we have with Shibb.


The user needs access to app A. It logs into A through Shib - or CAS for that matter. It receives an authentication token for Shib and application usually grant a session/access token.

Then user navigates to Chamilo. The Shib token is available but Chamilo doesn't see the Chamilo session token so it displays the usual front page - not logged in. The user then click on the login link. At which point Shib recognizes there is a token bypass the login screen and grant access to Chamilo. At which points Chamilo does its logging stuff, create a user session, etc, and displays the front page with user loged-in.

If we really want to do SSO we should bypass the click on the login link. For that we can add a javascript and/or some php logic. If user is not logged in Chamilo and there is a Shib token redirect to login link. That would force Chamilo to log user in transparently. Result: when user navigate to Chamilo and he is logged in Shib he is automatically logged in Chamilo as well. Nothing to do for him.

So, as you correctly described, what we want to do is to move from situation "user has access rights but is not loged in" to situation "log user in if he has access rights".

Well a small addition but it should be easy enough to do.

Back login screen

Well there is something specific with Shib - especially the way we implement it through the Apache module - is that we need to modify the login screen. Here is the reason.

First Shib is a federation. So there is not only one Identity Provider - idp - but severals. For example one for University of Geneva, one for University of Lausanne, etc. When the user want to log in he must specify where he comes from - i.e. which identity server is going to authenticate him - that's the discovery service. Therefore the login screen is composed of user login, password plus the list of Idps.

Second the way we implemented it is through the Apache module. So the login screen is not provided by Chamilo. What we do is that we secure a page at Apache level. When a user want to access it he is redirected to the Ship login screen provided by the shib Federation. On successful authentication Shib grant access to the page with needed - first name, last name, etc. There are a few advantages for that: same login screen for all applications secured by Shib. Login and password are never shared. Same method to secur all applications - you don't have to configure different libraries/applications.

The result is that the Shib login is not made of user login plus password but of a few hyper links. One for Idp unige, one for discovery service, etc. It is easy enough to make a new login block - I did it already - for Shib but the problem now is that we must modify the back login screen as well.

Well it is a small addition as well - the user could still navigate to front page, login, and go to where he wants. Yet that would be a little nice addition. Especially if we want to feed widgets from Chamilo to external applications - portal, web site, etc. Something we want to do.

Hope this helps.


Updated by Hans De Bisschop almost 12 years ago

Ok ... I think we're on the same page about this. The CAS authentication module works in a more or less similar way in that it automatically verifies if you already have a valid CAS session running and if so, automatically logs you in. Without the need to click any kind of link. If no CAS session exists the user obviously needs to log in and that's also when we redirect said user to CAS (providing a callback URL) to enter his credentials. Once validated he's redirected to (in this case) Chamilo again, which "notices" the CAS session and you're in.

The advantage we had in adding that module is that there's a pretty good phpCAS library out there which handles virtually everything for us. It was just a matter of hooking it into the system. Don't know if such a thing is available for Shibboleth.

Apart from the backend (the fact that it's federated first and foremost) I think the actual proces to get users logged in via Shibboleth is not all that different from CAS.


Updated by Laurent Opprecht almost 12 years ago

Yes, I think in the end the purpose is to do the same for Shibboleth we did for Cas.
Only this is a bit more complicated for Shib.


Updated by Laurent Opprecht almost 12 years ago

  • Status changed from New to Feature implemented
  • Assignee set to Laurent Opprecht

see #2783 resolved issue by autoforwarding in Shibboleth Authentication to the Shibb login form.


Updated by Hans De Bisschop almost 12 years ago

  • Project changed from Chamilo LCMS Connect to User
  • Category deleted (7)

Updated by Stefaan Vanbillemont about 11 years ago

  • Target version set to 2.1.0

Also available in: Atom PDF