test

Sun Open Telecommunications Platform 2.0 Developer's Guide

Chapter 8 Using Sun OTP Security Services

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:

Securing Web Applications With Sun OTP

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.

Configuring Policy Agent

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.

ProcedureTo Configure Policy Agent for Web Server 6.1 on Solaris 10 11/06

  1. Go to the config directory.

    cd /etc/opt/SUNWam/agents/es6/config/...instance.../

  2. Edit the AMAgent.properties file.

  3. Create a user name that you will use to log in to Access Manager. For example, com.sun.am.policy.am.username = amAdmin.

  4. 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.

  5. Go to the bin directory.

    cd /opt/SUNWam/agents/bin

  6. Encrypt the password for the user by using the crypt_util utility. For example, crypt_util secretPassword.

    Note –

    The crypt_util utility is part of the Access Manager installation.

  7. 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.

Example of a Protected JSP Page

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:

Integrating Web Applications Into Sun OTP Web SSO Environment

There are two types of web applications that can be integrated into Web SSO. They are:

Web Applications Without Any 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.

Web Applications With Their Own Authentication Implementation

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.

Implementing the Web SSO Filter

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.

Extending Web SSO Core With New Authentication Module

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.

Hardening Sun OTP and Hosted NEP Applications

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:

  1. Create a new N1 SPS plug-in, which will inherit plans, components, and drivers from the original plug-in.

  2. Insert your drivers.

  3. 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.