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?
Comments