|
|||||||||||||||
|
MOD_BUT
MOD_BUT is an Apache 2.x Entry Server component. It helps you build up secure, e-commerce infrastructure by adding pre-authentication to your applications. MOD_BUT in its current version 2.9 brings SSO and per-user defined access control to MOD_BUT protected backend applications. Please learn the full power of MOD_BUT via demonstration page. A step-by-step guide in how to use the demonstration page is written within the provided PDF document.
Backend systems can authenticate users again (if desired) once the user is authenticated at mod_but, or trust the pre-autheticated user from mod_but. User identity is delegated via cookie to the backend application. This cookie is nevers seen between the Internet client and the reverse-proxy. This information is only wired between mod_but and the backend applications. Backend sessions (e.g. jsessionid from a Tomcat java application) is not seen at the Internet client. The mod_but session store (cookie store) hides backend sessions within the shared-memory based cookie store. Backend sessions are only wired between mod_but and the backend application. If one wants to have a backend cookie directly wired to the client, because some Java Scripts are requiring the existance of the cookie (e.g. language=en), one can configure mod_but to transparently wire so-called "free cookies" between the Internet client and the backend application. The login application notifies mod_but via Set-Cookie response headers about login status. However - mod_but does not accept such LOGIN=ok messages from any backend application (this is not safe). Instead, one can configure authorative URL's allowed setting such important messages to mod_but. The login service is something unspecific to mod_but. In this demo environment, the login service authenticates against an OpenLDAP directory. If a successfule ldap bind() works, a user is marked as "authenticated". Afterwards, the login service notifies mod_but via previous discussed LOGON=ok message (cookie). If multiple backend applications use the same cookie name, we have introduced backend LOCATION_ID's for their separation. Having the same cookie name for different backend application is supported by mod_but. Deletion of backend cookies from the cookie store is supported too. Once the login servcies sends a LOGIN=ok message, mod_but will generate a new mod_but session and stores the already existing backend-cookies into the new session store. This is important for being safe against session fixation attacks. If the user is authenticated successfully, the login server can inform mod_but about backend applications the user is authorized to request. This is important, because we do not want to have mod_but authenticated users being able requesting (attacking) all backend sessions. The user is only allowed for his/her authorized backend systems. If the user clicks on the logout button, the current MOD_BUT session will be destroyed and saved into "history" sessions, where they reside for the next 8 hours. With such a historized session, neither the browser's back button or other techique will give the user access to his applications again if not prevously successfully authenticated. Our current project team is developing a delegated login service. Such a delegated login servcie will help implementing SSO (single-sign-on). Once the user is successfully authenticated at mod_but, the delegated login service will automatically login the user into his authorized backend sessions. This is really a nice feature we are looking forward having it. Once it is in place, multiple logins is not required any more. That's fun! Client certificate based authentication is not implemented yet, event the basic structs and techniques are available. If this is realized, mod_but wil be released with a new version. Please try out the DEMO here if interested. More details can be found in the following PDF: |
