Sun OTP 2.0 includes Access Manager, Web Server, and Directory Server. Do not deploy any additional web applications under the web server that is co-packaged with Sun OTP 2.0. If you require to deploy additional web applications, deploy it under a different web server.
The following topics are discussed:
This section describes the various methods to secure web applications with Sun OTP. You can configure the web server to use the Policy Agent software. The Policy Agent software helps in restricting access to the server web pages.
The standard way to secure a web application is to install Access Manager's Policy Agent on a web server or an application server, and the agent protects the defined resources on the container. It is necessary to change the configuration file for the Policy Agent. Change the username and password that the agent uses to connect to the Access Manager. For Web Server 6.1 on Solaris, see Updating the Agent Profile Name and the Agent Profile Password in Web Agents in Sun Java System Access Manager Policy Agent 2.2 Guide for Sun Java System Web Server 6.1.
For more information, see Sun Java System Access Manager Policy Agent 2.2 User’s Guide and Sun Java System Access Manager 7.1 documentation collection at http://docs.sun.com/app/docs/coll/1292.2.
Go to the config directory.
cd /etc/opt/SUNWam/agents/es6/config/...instance.../
Edit the AMAgent.properties file.
Create a user name that you will use to log in to Access Manager. For example, com.sun.am.policy.am.username = amAdmin.
Check the settings com.sun.am.naming.url and com.sun.am.policy.am.login.url .
The settings should point to the URLs where the naming service and login pages of Access Manager are available.
Go to the bin directory.
cd /opt/SUNWam/agents/bin
Encrypt the password for the user by using the crypt_util utility. For example, crypt_util secretPassword.
The crypt_util utility is part of the Access Manager installation.
Edit the AMAgent.properties file again to set a password for the user name that you created in Step 3. Use the hash generated by crypt_util. For example, com.sun.am.policy.am.password = XFC3z18nqMEgWbnshtNfwQ==
For more information, see Sun Java System Access Manager Policy Agent 2.2 User’s Guide and Sun Java System Access Manager 7.1 Documentation Collection.
The following code illustrates a JavaServer Page (JSP) with the login and logout functionality. This page has a section that can be viewed only by authenticated users. This code uses the Single Sign On interface of Access Manager.
<%@page contentType="text/html"%> <%@page pageEncoding="UTF-8"%> <%@page import="com.iplanet.sso.*"%> <h1>AuthTest</h1> <p> <a href="http://ipp-node11.czech.sun.com/amserver/UI/Login?org=dc%3Dczech%2C dc%3Dsun%2Cdc%3Dcom&goto=/test.jsp&gotoOnFail=/error.jsp">Login</a> | <a href="http://ipp-node11.czech.sun.com/amserver/UI/Logout? goto=/test.jsp">Logout</a> </p> <% SSOTokenManager ssoManager = SSOTokenManager.getInstance(); SSOToken ssoToken = null; String orgName = ""; boolean ok = false; try{ ssoToken = ssoManager.createSSOToken(request); } catch(Exception e) { out.write("<p>Exception! "+e+"</p>"); } if (ssoToken != null && ssoManager.isValidToken(ssoToken)) { %> <p>Access allowed!</p> <% } else { %> <p>Access denied!</p> <% } %>
In the above code, the login and logout links use the web interface of Access Manager to verify the username and password of users. The remaining part of the code checks if the HTTP request contains a valid SSO token. If a valid SSO token is found, the user is authenticated and access is allowed.
For more details, see the following guides:
There are two types of web applications that can be integrated into Web SSO. They are:
Web applications without any authentication implementation
Web applications with their own authentication implementation
Web applications that do not implement any type of authentication are protected by the Policy Agent software of Access Manager, which is installed on the host web container. For more details about configuring the Policy Agent software, see Configuring Policy Agent. As Access Manager is integrated into Web SSO, you do not have to modify the web application.
The Web SSO implementation is based on cookies and HTTP filters for redirection. To integrate a web application into Web SSO, add a filter that will redirect the user to the core Web SSO application, in case a user is not logged in. The core Web SSO application has to be extended with the authentication module. The authentication module will implement the AuthModule interface and provide the login and logout functionality.
The Web SSO filter is attached to a web application, which is part of a Web SSO. The filter intercepts all HTTP requests. When an unauthenticated HTTP request is recognized, the filter redirects the user to the Web SSO core application. When HTTP request belongs to an authenticated user, the filter does nothing. For filter API details, see package javax.servlet. Also see the source code, for example, src/websso/filter/.
For more information, see Java Platform Enterprise Edition, v 5.0 API Specifications.
For every web application that needs to be integrated with Web SSO, you have to implement the new authentication module. You have to modify the Web SSO core, that is, add and embed the new authentication module into the code.
The authentication module should extend the com.sun.otp.websso.AuthModule abstract class. The following listing illustrates it:
package com.sun.otp.websso.xxx; import com.sun.otp.websso.AuthModule; import com.sun.otp.websso.SunClusterUtils; import com.sun.otp.websso.Util; import com.sun.otp.websso.configuration.ConfigItem; import java.net.HttpURLConnection; import java.net.URL; import javax.servlet.ServletContext; import javax.servlet.http.Cookie; /******************************************************************************* * Authentication module for XXX application. */ public class SpsAuth extends AuthModule { /**************************************************************************/ private static final String XXX_COOKIE = "XXXCookie"; /*************************************************************************** * Creates new instance of authentication module for N1 SPS. * @param config configuration information for this module * @param context servlet context */ public SpsAuth(ConfigItem config, ServletContext context) { super(config, context); log("XXX: "+protocol+", "+server+", "+port); } /*************************************************************************** * Performs login into XXX application. * @param username user's name * @param password user's password * @return array of cookies obtained from Lockhart that should be stored in user's browser */ public Cookie[] login(String username, String password) throws Exception { //connect to XXX application, provide credentials, and return cookies } /*************************************************************************** * Performs logout from XXX application. * @return array of cookies that should be updated (deleted) in user's browser */ public Cookie[] logout() throws Exception { //connect to XXX application, do logout, and return cookies that should be updated/deleted }
For filter API details, see package javax.servlet. Also see source code, for example, src/websso/filter/. For more information, see Java Platform Enterprise Edition, v 5.0 API Specifications.
For hardening the Sun OTP systems, Solaris Security Toolkit (SST) version 4.2 is used. SST is delivered as part of the N1 SPS plug-in. The N1 SPS plug-in contains the SST drivers for hardening and unhardening Sun OTP. As the plug-in is compiled and signed, it cannot be changed easily.
To modify a driver, do the following:
Create a new N1 SPS plug-in, which will inherit plans, components, and drivers from the original plug-in.
Insert your drivers.
Modify the new plug-in to use the drivers you insert.
The above steps will ensure that the plans and components from the original plug-in are reused and invoked with the new SST drivers. For more information, refer to the SST and Sun N1 SPS documentation.