After hearing various comments and setting up some more production implementations, I figured I would share some tips beyond the straight setup here. I will reserve the other post for keeping the basic instructions and use this one for any additional notes as I come across them.
Version compatibility
Many people seemed to have trouble with the directions using more recent versions of the software than this was made on. I have successfully connected Pentaho 4.1 to CAS 3.4.11 following these directions, so they will most likely remain valid until Pentaho implements a more recent version of Spring Security (which would probably be Pentaho 5 at the earliest). The only part of the install that is absolutely version specific is the spring-security-cas-client-2.0.5.RELEASE.jar file. A later version of this jar will not work.
The difficulty connecting that many people seem to have most likely comes from applicationContext-spring-security.xml file. Since the directions were made with a specific version of CAS, all of the URL references in it are made to the “http://localhost:8080/cas-server-webapp-3.4.8/” version of the webapp. Since you can technically name the webapp anything, these URL references need to be changed to match, such as “http://localhost:8080/cas-server-webapp-3.4.11/” for the current version.
Security
While CAS will complain on its login page about not using SSL, I am as of yet to find a version that will actually not allow pentaho login. This does not mean that certain setups will not run into this problem, and many other CAS clients require SSL connections Either way, setting up your server to use SSL is always a good idea. The instructions apache provides (http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html for the version of tomcat pentaho uses) should be sufficient for setting this up, and remains mostly consistent between later versions of tomcat.
Again changes need to be made to the applicationContext-spring-security.xml file’s URLs, this time make sure to change the “http://localhost:8080” to the equivalent secure URL such as “https://localhost:8443” to make sure it actually uses the SSL.
XML Encoding
This is something that I’m sure some people have run into before, namely that when copying the XML over it sometimes cannot be read by the server. The primary cause of this is due to the XML file requiring UTF-8 encoding, and many text editing programs (especially in Windows land) tend to automatically save to more modern text encodings. So When editing these files, make sure to force UTF-8 encoding when you save.
Authentication vs Authorization
CAS like its spelled out name implies is designed to handle authentication, i.e. verifying a valid username and password combination. This does not include authorization, i.e. checking if a user is actually allowed to access something. Authorization is handled on the client end, in this case Pentaho. Any time a user successfully logs in to CAS but does not have any authorization in pentaho, they will be redirected to the default public/casFailed page which does not exist by default. As usual, this can be changed in the applicationContext-spring-security.xml file.
Normally both are handled in Pentaho, with authentication handled in the applicationContext-spring-security.xml that is modified as part of the CAS integration, and also in another file that is imported through the pentaho-spring-beans.xml file, the default being called applicationContext-spring-security-hibernate.xml. After CAS is integrated, this imported file is mostly ignored, as CAS is bypassing all of the beans in it.
Authorization is handled primarily by another file imported through the pentaho-spring-beans.xml file called applicationContext-pentaho-security-hibernate.xml by default. Like the similarly named file mentioned previously, there are a number of alternate versions that can be used instead of the default hibernate version, such as -jdbc (checks against a database query), -ldap (checks against an ldap server), -memory (checks against data written directly in the XML file).
I haven’t fully explored all of the possibilities those different authorization options may provide, so it is very possible that there is an elegant solution available in modifying those files. If the user base for a pentaho deployment is not especially large and/or does not change often, updating user permissions by hand may be a more cost effective solution than spending hours coming up with a custom solution. When confronted with this same problem with a client who had potentially thousands of users, I went to the Pentaho developer’s multipurpose tool: PDI.
This ETL is designed to check the USERS table found in the hibernate database that Pentaho CE comes with against an LDAP server and make comparisons for any new users, which it then adds to the Hibernate database with the basic Authenticated role. The main advantage of this technique is that it is not difficult to implement against any size, and can be scheduled to run regularly to keep the records up to date. It also allows the Admin Console to still be used to add additional roles to the users. The main disadvantage is the fact that there will always be a time delay until its next scheduled run or the next time someone manually does so. It also lacks flexibility, as it grants the same permission to every user it adds, so still requires human intervention to make users an admin or some other role. This could probably be overcome with further development and more precise deployment specifications from a client, and in its current form is still very effective at authorizing large groups of users at once.
If there are any other solutions out there, or other comments about these or any other issues, let me know.
