Hi,
I am doing a project that uses Acegi in the Web container level, so that Acegi becomes complementary to J2EE container based security model. The goal is Web applications can use J2EE security features such as Form authentication, role based access control together with Acegi enabled security features with minimum changes.
Here I introduce how Single Sing-On (SSO) can be done on the Web container level by extending the J2EE FORM based authentication.
I am doing a project that uses Acegi in the Web container level, so that Acegi becomes complementary to J2EE container based security model. The goal is Web applications can use J2EE security features such as Form authentication, role based access control together with Acegi enabled security features with minimum changes.
Here I introduce how Single Sing-On (SSO) can be done on the Web container level by extending the J2EE FORM based authentication.
- Problem to solve:
To achieve SSO in a Web application, we need to cover two use cases:
Use Case 1. A HTTP request without a valid SSO token needs to be redirected to the common login page, once the authentication is succeeded, a SSO token is issued to the corresponding Web client. The Web client is then redirected back to the original Web container. The Web container tries to validate the SSO token and recreate the authentication context from the SSO token as explained in scenario 2 below. After that the "original HTTP request" is processed. Notice it is the "original HTTP request" that should be processed. For example, if the Web client asks for https://x.x.x.x/worldHistoryByYear/2006. The HTTP response content being returned to the Web client after successful authentication should be https://x.x.x.x/worldHistoryByYear/2006, not the index.jsp file for https://x.x.x.x
Use Case 2. A HTTP request with a valid SSO token tries to access a Web container. The Web container detects there is no valid session id for the Web client. The Web container tries to validate the SSO token and recreate the authentication context from the SSO token. The Web container creates a new session for the Web client, then the "HTTP request" is processed.
Use Case 1. A HTTP request without a valid SSO token needs to be redirected to the common login page, once the authentication is succeeded, a SSO token is issued to the corresponding Web client. The Web client is then redirected back to the original Web container. The Web container tries to validate the SSO token and recreate the authentication context from the SSO token as explained in scenario 2 below. After that the "original HTTP request" is processed. Notice it is the "original HTTP request" that should be processed. For example, if the Web client asks for https://x.x.x.x/worldHistoryByYear/2006. The HTTP response content being returned to the Web client after successful authentication should be https://x.x.x.x/worldHistoryByYear/2006, not the index.jsp file for https://x.x.x.x
Use Case 2. A HTTP request with a valid SSO token tries to access a Web container. The Web container detects there is no valid session id for the Web client. The Web container tries to validate the SSO token and recreate the authentication context from the SSO token. The Web container creates a new session for the Web client, then the "HTTP request" is processed.
- Existing CAS-ACEGI based SSO solution: WAR designers have to add/modify ACEGI and CAS specific filters and other Spring bean stuff in their web.xml and Spring application context file. In short, all the WAR files must be ACEGI enabled even if they just want to achieve SSO.
- Goal of container based SSO solution:
- WAR files designed for normal J2EE enviroment can be deployed into the Web container and SSO is enabled automatically for the WAR files by default.
- Decouple the specific SSO technologies being used from WAR files. For example, we should be able to switch from CAS to JOSSO without affecting the
- How the container based SSO extends the J2EE form authentication:
J2EE FORM authentication is a passive authentication model very similar to the above scenario 1. The difference is in SSO mode, the login page is typically provides by an external servlet that take the original Web container's URL as some kind of "goto" query string parameter.
Here is roughly how J2EE form authentication works (based on Tomcat source code):
1. An unauthenticated HTTP request tries to access a protected resource.
2. The FORM authenticator saves the "original HTTP request".
3. The FORM authenticator redirects the Web client to the login page.
4. When the login page is submitted, the FORM authenticator uses a special filter to intercept HTTP request for URL /j_security_check?j_username=someName&j_password=anyPasword.
5. If the given user name and password are correct. The FORM authenticator restores the "original HTTP request" so that it can be processed after authentication.
To extend the FORM authentication work flow for container based SSO, the following steps are required.
1. In web.xml, point the FORM login page to a special servlet "loginProxy". This is the only change required for WAR files. Notice if you are using Tomcat like me, you can modify the generic web.xml on the container level, then you don't need to touch each individual WAR file as long as they don't override the generic web.xml settings.
2. The logic of the "loginProxy" servlet goes like this:
Cheers
Jin
Here is roughly how J2EE form authentication works (based on Tomcat source code):
1. An unauthenticated HTTP request tries to access a protected resource.
2. The FORM authenticator saves the "original HTTP request".
3. The FORM authenticator redirects the Web client to the login page.
4. When the login page is submitted, the FORM authenticator uses a special filter to intercept HTTP request for URL /j_security_check?j_username=someName&j_password=anyPasword.
5. If the given user name and password are correct. The FORM authenticator restores the "original HTTP request" so that it can be processed after authentication.
To extend the FORM authentication work flow for container based SSO, the following steps are required.
1. In web.xml, point the FORM login page to a special servlet "loginProxy". This is the only change required for WAR files. Notice if you are using Tomcat like me, you can modify the generic web.xml on the container level, then you don't need to touch each individual WAR file as long as they don't override the generic web.xml settings.
2. The logic of the "loginProxy" servlet goes like this:
- If
the current HTTP request contains the SSO token, redirect to j_security_check?j_username=x&j_password=x. Notice the value of the user name and password are not important in this case. We just give some dummy values here.
- If the current HTTP request does NOT contains the SSO token, redirect to the central SSO token issuer's login page. The URL of the central login page should be configurable. For example like this, "https://ssoIssuer.com/loginServlet?goto=" the value of the "goto" parameter is "current base URL" + "current httpRequest.getContextPath() + "/j_security_check?j_username=x&j_password=x", notice the " /j_security_check?j_username=x&j_password=x" is critical to make sure the original HTTP request saved by the FORM authenticator is being processed after authentication
- On the Web container, a authentication provider must be provided so that:
- If the current HTTP request contains the SSO token, ignore user name and password submitted to j_security_check, (In this case it is going to be dummy value x and x anyway) in stead, validate the SSO token, recreate the authentication context using the SSO token.
- If the current HTTP request does NOT contain the SSO token, authenticate using the user name and password submitted to j_security_check just like normal authentication provider does.
- Here is the chance that Acegi Web container adaptor can kick in and help decouple the SSO solution with actual SSO technologies being used. In my case I use the JBoss adaptor to config a SsoAuthenticationProvider. Different SSO technologies
can provide different SsoAuthenticationProvider, if you want to do CAS this way, you need a CasSsoAuthenticationProvider.
Jin
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Home: http://acegisecurity.org Acegisecurity-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
