Shared Authentication

Shared authentication is the second area to address when dealing with interoperability at the presentation tier . Although some third-party implementations cover shared authentication and Single Sign-On, presentation-tier authentication on the whole tends to be specific to the platform. For example, if an organization selects a third-party implementation for handling Web authentication on the JSP tier, it typically will have to select the same implementation from the same vendor to achieve a similar level of authentication on the ASP.NET tier ” and this doesn't guarantee that the authenticated session will work across both platforms. More often than not, in a heterogeneous environment, the user finds himself having to log in again when moving between ASP.NET and JSP pages.

When developing a custom solution, one way to achieve shared authentication is to extend the shared session component covered in the previous section. The shared session component provides a way to exchange authentication data between the two platforms' presentation tiers by using the shared session. But before we can do that, we need to agree on the method of authentication. We can use a Forms Authentication solution in ASP.NET to develop a custom solution.

Note

ASP.NET allows the developer to select one of three types of authentication for securing Web applications: Windows Authentication, Passport Authentication, and Forms Authentication. Forms Authentication allows you to apply page-level authentication to a Web application in ASP.NET and automatically redirects the user to a login page if certain credentials haven't been supplied. Once authenticated, the user is automatically redirected to the original page she requested . You configure Forms Authentication by modifying the web.config file for each Web application. Forms Authentication is flexible enough to secure individual pages, allowing you to set different permissions for each user.

To see this in action, let's enable Forms Authentication for both the .NET and Java platforms using the sample code. Returning to the previous example, open the web.config file in the .NET version of the shared session state test client. This can be found in the Web directory of the sample application (C:\Interoperability\Samples\Advanced\Presentation\dotNET\Web).

Within this file, locate the < authorization > section toward the end, uncomment the < !--deny users="?"/ -- > line, and save the file. (To uncomment a line in XML, remove the leading [ !-- ] and trailing [ -- ] symbols. Doing so would make the previous line < deny users="?"/ >.) After this change is made, save the file and close it. You don't need to rebuild the .NET solution because this file is automatically loaded at run time. A copy of how this file should look can be found in the C:\Interoperability\Samples\Advanced\Presentation\Authentication\dotNET\Web directory.

The authentication and authorization sections within the web.config file enable Forms Authentication security for the ASP.NET side of the sample application. To enable Forms Authentication on the J2EE tier, edit the web.xml file found in the Web\WEB-INF subdirectory of the Java directory. Locate the FormsAuthenticationEnabled parameter, and change the value from false to true :

 <filter> ...     </init-param>      <init-param>          <param-name>FormsAuthenticationEnabled</param-name>          <param-value>true</param-value>      </init-param> </filter> 

Again, for validation, a copy of how this web.xml file should look can be found in the C:\Interoperability\Samples\Advanced\Presentation\Authentication\Java\Web\WEB-XML directory. After changing this value and saving the file, rebuild the solution and redeploy to the J2EE server using the package and deploy targets, respectively. The forms authentication component for the J2EE tier is an additional piece of sample code that can be found in the SharedSessionFilter.java file.

Within a new instance of Microsoft Internet Explorer, open the ASP.NET shared session state sample that was shown in the previous section ( http://localhost/SharedSessionStateClient/StockDisplay.aspx ). You might notice that the shared session state registration still occurs. (If you're quick, you can see the redirect from ASP.NET to the Register.jsp page and back again.) This time, however, a login screen is displayed.

This login screen (login.aspx), shown in Figure 12.24, is an automatic redirect from the ASP.NET Forms Authentication service that you enabled by changing the web.config file earlier. For this example, the username and password have been hard-coded. (The username is testuser, and the password is StrongPassword.) Enter these and click the Login button. You'll be redirected to the original shared session state sample page as before. Figure 12.25 depicts this page.

Figure 12.24: Using forms authentication to display a login.aspx page for ASP.NET.

Figure 12.25: Authentication also applies for the Servlet hosted within the ASP.NET page.

You can also see how to protect both JSP and Servlets by using this same mechanism. By making the earlier change to the web.xml file, you protected the Servlet that's being hosted within the ASP.NET page. Because you've already logged in, you cannot detect this (because you aren't asked again for the Servlet authentication details). However, if you close the current Internet Explorer window so that the nonpersistent cookies holding the regular Session ID are no longer available, and if you instead use the http://localhost:8080/SharedSessionStateClient/StockDisplay URL to call up the Servlet running individually, you can detect this protection of the Servlet.

This Servlet is also protected by the Forms Authentication mechanism that we employed in ASP.NET. This mechanism will work for any JSP or Servlet that's hosted through this site.

Using Shared Authentication

This example shows how ASP.NET Forms Authentication, combined with the shared session concepts presented in the previous section, can be used to protect JSP and Servlets. This works whether the JSP and Servlets are hosted within an ASP.NET page or hosted individually on the J2EE application server.

This technique lends itself to a number of benefits when deploying applications. For example, organizations running both J2EE applications and introducing .NET applications in-house are likely to face the challenge of using two presentation solutions to authenticate incoming users (even if the store for holding the user credentials is the same). By using and extending the Forms Authentication technique shown here, a unified way of authenticating against the Web tier can be achieved ”for both J2EE and .NET applications. This can enable users to navigate between pages hosted on a J2EE or .NET system and to authenticate themselves only once to perform this navigation.

How the Shared Authentication Solution Works

The shared authentication solution by no means fits all presentation-tier authentication issues. As with the shared session state example shown earlier in the chapter, this sample was written to show a potential solution for a very difficult interoperability problem. Taking this sample to the production stage would require additional development and a careful implementation strategy. That said, the underlying concepts for how the shared authentication sample works are similar to (and indeed based upon) the shared session mechanisms discussed earlier in this chapter.

The first configuration step to enable this shared authentication sample is to prevent the regular Forms Authentication mechanism from intercepting this Register.aspx file. If the Register.aspx file gets intercepted, this will interrupt and cause conflict in the shared session registration process. If this happens, our shared session will not be set up ”and because we need the shared session to work in order to enable shared authentication, this results in a Catch-22! To stop Forms Authentication from trapping the Register.aspx file, security restrictions are removed from this file in the web.config file. This is done by placing the following section between the configuration elements in web.config for the ASP.NET tier:

 <location path="Register.aspx">     <system.web>         <authorization>             <allow users="*" />         </authorization>     </system.web> </location> 

To enable forms authentication to display a prompt when credentials aren't found, a login.aspx file is used. This login page was displayed the first time the sample was run. When the user clicks the Login button, the following code is executed:

 if ((UserEdit.Text == "testuser") &&      (PasswordEdit.Text == "StrongPassword")) {     SharedSession SSession = new SharedSession(Session.SessionID);     SSession.Add("SharedAuthentication","true");     SSession.Add("Username",UserEdit.Text);     FormsAuthentication.RedirectFromLoginPage(UserEdit.Text,false); } 

First, the username and password are checked to see whether they're correct. (In a production system, these might be a found via a lookup to a database, Microsoft Active Directory directory service, or another Lightweight Directory Access Protocol directory.) For this example, however, we simply have the username and password hard-coded into the method. If they're valid, you write a token into the shared session, which allows the J2EE tier to confirm that this session has been authenticated.

You also write the username into the shared session by way of a simple token. This allows the J2EE tier to reference the username of the logged-in user. You could also include other information, which ”as you can imagine ”would require some kind of encryption if running in a production system. However, this technique has the potential to offer integration with some kind of authorization system to validate which parts of the application a user may access.

The code on the J2EE tier that reads when this value (token) exists in shared session and performs the redirection to the login page is located in the SharedSessionStateFilter.java class. The redirection that the code implements shows how the J2EE tier checks for the token in the shared session. If the token isn't present, a redirect to the login page is executed. The code that enables this follows :

 String _formsLoginURI      = filterConfig.getInitParameter("FormsAuthenticationLoginURL"); String _enabled      = filterConfig.getInitParameter("FormsAuthenticationEnabled"); if (_enabled.equals("true")) {     try     {         DAO _dao = new DAO();         String authenticated              = _dao.getObjectXML(req.getSession().getId(),                 "SharedAuthentication");         if (!(authenticated.equals("true")))         {             ((HttpServletResponse)response).sendRedirect(                 _formsLoginURI);         }     }     catch (Exception e)     {         try         {                 ((HttpServletResponse)response).sendRedirect(                 _formsLoginURI+"?ReturnUrl="+sb.toString());         }         catch (Exception e2)         {             e2.printStackTrace();         }     } } 

First, the filter reads two values from the web.xml file: the URL of the login.aspx page on the ASP.NET tier, and a value that indicates whether authentication will be checked for this session. Assuming that authentication will be checked, the filter performs a database lookup for the existing session to check whether an entry for SharedAuthentication exists with a value of true . If such a value doesn't exist (because it's not set to true or the key isn't present in the shared session), the user is redirected to the login URL in the web.xml file. The ?ReturnURL request parameter is appended to the redirect so that when the user enters the correct username and password, he's redirected to the original page on the J2EE tier. If the value does exist (in other words, if this session has already been authenticated), processing passes through the filter code and the requested JSP or Servlet is processed normally.