Monday, February 22. 2010
Machinarium
I have just finished an adventure game called Machinarium. This is a funny story about a little robot trying to rescue his robot girlfriend. The game is very very addictive with the perfect mixture of complexity and playability. The quizzes presented throughout the story are fantastic and I have to admit I played long hours this weekend. Thank goodness, it is quite short too. In its web page there is a web three stage demo everybody can play with. And over the internet there are lots of walkthroughs like this in case you get stuck and you do not want to play the shooting key trick (I just used it only two or three times which proves the quality of the adventure).
The game is made with flash so there is a linux version and I could play in my debian testing box. The only problem was my installation is amd64 and the game is only offered in 32 bit (i386 or x86). So you have to provide all the 32 bit libraries the executable needs (and a few more not specified because the game loads them dynamically at startup, one example is the flash plugin library itself).
The good news are I did not have to install anyone manually. The debian-multimedia repository (a famous repository for debian which provides many multimedia packages) has all the dependencies not installed by official repos. I needed to install three packages from there to make machinarium work:
Besides I had yet installed a bunch of ia32 packages from normal testing repositories:
And, of course, the nonfree flashplugin package is needed:
With all these packages the game runs like a charm.
The only snag is I have wasted a weekend.
Happy Machinarium.
The game is made with flash so there is a linux version and I could play in my debian testing box. The only problem was my installation is amd64 and the game is only offered in 32 bit (i386 or x86). So you have to provide all the 32 bit libraries the executable needs (and a few more not specified because the game loads them dynamically at startup, one example is the flash plugin library itself).
The good news are I did not have to install anyone manually. The debian-multimedia repository (a famous repository for debian which provides many multimedia packages) has all the dependencies not installed by official repos. I needed to install three packages from there to make machinarium work:
- ia32-libs-libnss3
- ia32-libs-libnspr4
- ia32-libs-libcurl3
Besides I had yet installed a bunch of ia32 packages from normal testing repositories:
- ia32-libs
- ia32-libs-gtk
- lib32gcc1
- lib32stdc++6
- lib32z1
- libc6-i386
And, of course, the nonfree flashplugin package is needed:
- flashplugin-nonfree
With all these packages the game runs like a charm.
$ export LD_LIBRARY_PATH=/emul/ia32-linux/usr/lib
$ ./Machinarium
The only snag is I have wasted a weekend.
Happy Machinarium.
Tuesday, February 2. 2010
OpenSSO Reverse Proxy Extension (Part III)
This is the last entry about OpenSSO reverse proxy extension. In the first one the reverse proxy was compiled and one of its demo application was installed inside a tomcat container. This demo just logged a hardcoded user and password into a basic auth protected web page. In the second entry a new credential source class was created. The new class retrieved the username and password from OpenSSO token. Then the proxy could silently log any user with an active opensso session into the same basic auth web page. In this third entry the reverse proxy extension is going to proxify a real legacy application instead of the basic authenticated page.
As I have already commented the OpenSSO proxy implementation uses filters to change the information that is flying from the client to the server. But what I did not talk about is that proxy gives to the developers an API to change everything inside the request (change the submitted form, headers and cookies deletion or addition, uri translation,...). This way when a login form is presented to the user the proxy can fulfill it instead of the user and perform the login transparently. In the proxy versioning system there are some contributed filter samples to do this in front of some legacy applications (SjsmeAuthFilter.java for Sun Java System Messaging Express, SjsceAuthFilter.java for Sun Calendar Server and MediaWikiAuthFilter.java for the popular php MediaWiki).
So I decided to install another web server in the KVM Solaris box and the PmWiki application was deployed inside it. PmWiki is a very simple PHP wiki which does not need any mysql installation (plain files are used instead). The wiki was configured to always present a login form (anonymous access is forbidden) and user information was again in the ldap server (OpenSSO and PmWiki share the same users as in previous examples).
Without proxy extension OpenSSO is unable to give PmWiki its SSO functionality without little code modifications. Installing Web Agents inside the container web server had passed user and group information via headers or cookies, but PHP code inside PmWiki would have been needed to retrieve this information and place them. Another traditional solution had been the PHP OpenSSO SDK but, again, some minor coding would have been needed.
Following the proxy way I extended the previous entry solution developing a new PmWikiAuthFilter.java which performs the silent login when no PHPSESSID is in the request. The idea is very simple:
An here is the video. If we access the PmWiki at first place the traditional login form is presented. As in the previous example, if we access directly to the tomcat proxy a exception is thrown (the same credential source class is being used and no valid SSO token is in place). But if we log in OpenSSO and then access proxy... Voila! We are in without any login form and, even better, we cannot log out! Tomcat logs show the proxy is relogin me again and again.
In summary, the proxy extension is nowadays only targeted for developers. It has quite a good api to implement other password sources or other authentication login filters as I have proved it, but no configuration (graphical or file) is possible. So it is quite useless at this time. Performance and throughput are another two good questions. But finally this extension is very promising and it is a real shame Oracle acquisition could stop proxy extension and all this project progress.
have fun!
EDIT: Some weird news have come to the OpenSSO user mailing list. A new site called www.forgerock.com has been launched in February 1 which announces OpenSSO express build 9. Has Oracle abandoned OpenSSO and the other sun products advertised on this web?
As I have already commented the OpenSSO proxy implementation uses filters to change the information that is flying from the client to the server. But what I did not talk about is that proxy gives to the developers an API to change everything inside the request (change the submitted form, headers and cookies deletion or addition, uri translation,...). This way when a login form is presented to the user the proxy can fulfill it instead of the user and perform the login transparently. In the proxy versioning system there are some contributed filter samples to do this in front of some legacy applications (SjsmeAuthFilter.java for Sun Java System Messaging Express, SjsceAuthFilter.java for Sun Calendar Server and MediaWikiAuthFilter.java for the popular php MediaWiki).
So I decided to install another web server in the KVM Solaris box and the PmWiki application was deployed inside it. PmWiki is a very simple PHP wiki which does not need any mysql installation (plain files are used instead). The wiki was configured to always present a login form (anonymous access is forbidden) and user information was again in the ldap server (OpenSSO and PmWiki share the same users as in previous examples).
Without proxy extension OpenSSO is unable to give PmWiki its SSO functionality without little code modifications. Installing Web Agents inside the container web server had passed user and group information via headers or cookies, but PHP code inside PmWiki would have been needed to retrieve this information and place them. Another traditional solution had been the PHP OpenSSO SDK but, again, some minor coding would have been needed.
Following the proxy way I extended the previous entry solution developing a new PmWikiAuthFilter.java which performs the silent login when no PHPSESSID is in the request. The idea is very simple:
- PmWiki is a traditional PHP application so, by default, PHPSESSID is used as the tracking session cookie. As PwWiki has been configured to prevent anonymous access the problem can be simplified: if session is in place user is already logged.
- So PmWiki filter is going to check if the PHPSESSID cookie is in the request, if it is nothing is done but if not a new login form is constructed and sent to wiki application.
- The proxy API is used to construct this whole new request.
- Finally the main Servlet replaces the old HttpBasicAuthFilter with the new PmWikiAuthFilter receiving a PostAuthCredentialSource as its credential source (the same source of the previous entry is used, the one which obtains the username and password from OpenSSO session token).
public class BasicAuthProxy extends SimpleProxyServlet{
@Override
public void init() throws ServletException {
init("http", "192.168.122.11", 80);
addFilter(new PmWikiAuthFilter(
new PostAuthCredentialSource("8uDWeq1Mx/c=")));
}
}
An here is the video. If we access the PmWiki at first place the traditional login form is presented. As in the previous example, if we access directly to the tomcat proxy a exception is thrown (the same credential source class is being used and no valid SSO token is in place). But if we log in OpenSSO and then access proxy... Voila! We are in without any login form and, even better, we cannot log out! Tomcat logs show the proxy is relogin me again and again.
In summary, the proxy extension is nowadays only targeted for developers. It has quite a good api to implement other password sources or other authentication login filters as I have proved it, but no configuration (graphical or file) is possible. So it is quite useless at this time. Performance and throughput are another two good questions. But finally this extension is very promising and it is a real shame Oracle acquisition could stop proxy extension and all this project progress.
have fun!
EDIT: Some weird news have come to the OpenSSO user mailing list. A new site called www.forgerock.com has been launched in February 1 which announces OpenSSO express build 9. Has Oracle abandoned OpenSSO and the other sun products advertised on this web?
(Page 1 of 1, totaling 2 entries)
Comments