Tuesday, November 29, 2011

CAS Domain Problem

In our company we have the problem, that we have 2 different domains where the authentication can happen. Unfortunately we can not assure that the credentials are unique over both Domains. e.g. there could be a user "Tom" in Domain1 and another "Tom" in Domain2 which belong to two different physical users (hopefully with two different passwords)

Now where's the problem? Well in the various applications we need to authorize the user depending on their position in the company. So it could be that the "Tom" in Domain1 can access an application but the "Tom" from Domain2 not. So how we can distinguish between the two "Toms"?

Despite that some of the applications, basically the ones that are developed in-house, can be extended to consider the domain passed as argument(see CAS & Attributes), there are some third party apps that cannot. So how those applications could have worked before? Basically for those we have one running version per domain, which solved the problem.

For those now we had to find another way. As we cannot check it on the application side the domain check needs to be implemented on CAS meaning that on "validateServiceTicket" another check to the authenticating Domain needs to be placed.

Important in this case is not to change to much of the original structure of CAS, in order not to loose the possibility to update when CAS updates. The solution has not yet been implemented nor tested, so stay tuned for the solution post.

UPDATE: Finally there is the solution

Friday, November 25, 2011

CAS Themes and Views

Recently we faced a big problem in our organisation regarding the look and structure of the login pages which could not be solved by CAS standard theme concept. By default the theme definition of CAS just changes the default CSS which for sure offers a wide variety within the pages, but made it difficult for us to fit our needs.

--> We had to change it in a way that also the views change

1) In the cas properties instead of telling the real name of the views I want to see just direct in any case to some defualt view like this cas.viewResolver.basename=views-default

2) Under src/main/webapp/WEB-INF/classes add one property file for each theme you want to use afterwards
+- cas-theme-theme1.properties
+- cas-theme-theme2.properties
+- ...

3) In this files just add one more property (beside the ones that are already there by default)
When the structure of your views is still like the one from default it should point perfektly to the views of theme1 in this example

4) Now change the default views e.g. src/main/webapp/WEB-INF/view/jsp/default/ui/casLoginView.jsp to the following

<%@ page contentType="text/html; charset=UTF-8" %>
<%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
<spring:theme code="theme.view" var="theme"></spring:theme>
<jsp:include page="${theme}casLoginView.jsp"/>

With this definition now the casLoginView.uses the view defined by the theme.view property in cas-theme-themeX.properties. file.

And now how to change the property file? Just use the Services GUI (e.g. https://login.cas.net/cas/services/manage.html) and enter there the name of the theme for the various services. And that's actually the power of the solution. Now you can define one default theme for your server and a lot of "real" themes for the various services that use you're CAS.

Of course it is a change in the basic logic of CAS, however it is reversable in a few steps if one day changing the basic CSS would be enough

By default the theme names are cas-theme-xxx which is at least 10 chars long. The default implementation of  the CAS Serive Managemant GUI allows theme names with a maximum length of 10, so change the add.jsp to allow the longer names

Linux boots into memtest86

Today I had the problem, that my ubuntu instance was booting automatically into the memtest86 grub entry. This was mainly because that was the only grub entry that remained after a linux image update.

The simplest way to fix this problem was using a live CD and the following commands:
1) boot into live CD

2) create a directory to mount the old linux on your hdd
sudo mkdir /mnt/temp
3) mount it
sudo mount /dev/sda1 /mnt/temp for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt/temp$i; done
4) copy the resolve.conf into the original ubuntu so that the apt-get will work in future commands
sudo cp /etc/resolv.conf /mnt/temp/etc/resolv.conf
5) change the root directory to the newly created mount point
sudo chroot /mnt/temp
6) now check if the kernel is already on your system. If not just install it
apt-get install linux
6.1) do some cleaning in your system
apt-get autoclean
apt-get clean
apt-get update
apt-get upgrade
apt-get install -f
dpkg --configure -a
7) if this still not works try to reinstall grub
apt-get purge grub grub-pc grub-common
apt-get install grub-common grub-pc
8) umount the whole stuff
for i in /dev/pts /dev /proc /sys / ; do sudo umount /mnt/temp$i ; done
9) restart the system

Now it should boot into the actual linux kernel and your system is back!