Integrating K2 with Netegrity SiteMinder

Technical Note
DE0271
November 30, 2005
T
E C H N I C A L
N
O T E
Integrating K2 with Netegrity SiteMinder
Version 6.1
This document describes how to integrate Verity® K2 6.1 with a Netegrity SiteMinder Identity
and Access Management (IAM) system. Such integrations enable K2 to access documents
protected by SiteMinder and use the authentication specified by SiteMinder policies.
Contents
Identity and Access Management Systems .............................................................. 3
Overview of Netegrity SiteMinder Integration....................................................... 3
Single Sign-On Integration.................................................................................. 3
Search and Viewing Integration ......................................................................... 4
Indexing Integration.............................................................................................. 6
Enhancing Performance........................................................................................ 7
Required Configuration ....................................................................................... 8
Configuring Netegrity SiteMinder ............................................................................ 8
Creating a Web Agent for K2 ............................................................................... 8
Adding the K2 Agent to an Agent Group ........................................................ 10
Configuring the Web Agent Configuration Object ....................................... 12
Defining a HEAD Web Agent Rule Action..................................................... 14
Defining the Authentication Scheme............................................................... 17
Integrating the K2 Application................................................................................. 18
EXTENSION_KEY and USER_PARAMS Key................................................ 18
Sample Code ......................................................................................................... 19
Using the Component Framework.................................................................... 21
Managing Expired Sessions ............................................................................... 22
Managing Cross-Site Scripting (XSS) Detection ............................................ 23
November 30, 2005
Part Number DE0271
Copyright 2005 Verity, Inc.
Technical Note
Configuring the K2 System....................................................................................... 27
Configuring a K2 Ticket Server......................................................................... 27
Configuring Basic K2 Ticket Server Settings .......................................... 28
Setting the Login Module............................................................................ 29
Setting the Persistent Store Module .......................................................... 30
Enabling Pre-Authentication in the K2 Ticket Server............................ 30
Attaching a K2 Server or K2 Broker........................................................... 31
Configuring the Gateway ................................................................................... 32
Defining SiteMinder Realms ..................................................................... 34
Defining Authentication Forms ................................................................. 36
Creating a Collection Using the SiteMinder Style Set .................................. 37
Configuring Basic Collection Settings...................................................... 38
Attaching the Collection to a K2 Server.................................................... 39
Configuring the Indexing Job............................................................................ 40
Security ......................................................................................................................... 43
2
Integrating K2 with Netegrity SiteMinder
Technical Note
Identity and Access Management Systems
Identity and Access Management Systems
To manage complex security infrastructures, many companies employ an Identity and Access
Management (IAM) system to centrally control identities and their access to resources. You can
integrate K2 with leading IAM systems, such as Netegrity SiteMinder, enabling users to log into a
Web server with one user name and password and search or browse across all repositories
without re-authenticating to K2.
There are two types of security systems with which you can integrate K2:
„
vendor-based—A vendor-based system uses a third-party IAM tool to administer and enforce
user access to resources. Examples of these are Netegrity SiteMinder, Oblix, and Tivoli. K2
supports integration with Netegrity SiteMinder. This document describes integration with this
type of security setup. Other vendor-based IAM integrations can be implemented through
Verity Professional Services. This document describes integration with this type of security
setup.
„
standard—A standard system secures documents by requiring authentication on the
repository in which they are stored. This is typically accomplished using the standard security
features of the Web server and JSP or ASPx code. An example is an IIS server with Integrated
Windows Authentication (challenge/response). For information on integrating K2 with this
type of security setup, contact Verity Professional Services.
Overview of Netegrity SiteMinder Integration
Verity developed the SiteMinder/K2 integration in partnership with Netegrity. The joint solution
enables K2 to index, search, and view content on a Web server based on SiteMinder’s
authorization policies. K2 supports integrations with SiteMinder versions 5.5 and 6.0. A
SiteMinder integration with K2 involves three components:
„
Single sign-on integration. See “Single Sign-On Integration” on page 3.
„
Search and viewing integration. See “Search and Viewing Integration” on page 4.
„
Indexing integration. See “Indexing Integration” on page 6.
Single Sign-On Integration
When a K2 application and a K2 Ticket Server are integrated with SiteMinder, the authentication
necessary to log into K2 is supplied by SiteMinder and propagated to various K2 components.
When a user attempts to access a Web site protected by SiteMinder, a SiteMinder Web Agent
challenges the user for credentials and authenticates the credentials. The Agent then creates a
session cookie named SMSESSION in the user’s browser, and inserts an encrypted token
containing an ID that uniquely identifies the user in SiteMinder. When the user requests access to
K2, the K2 application retrieves the SMSESSION cookie and user ID from the user’s request, and
passes them to the K2 Ticket Server. K2 accepts the user as authenticated, and issues a K2 ticket
without challenging the user for credentials. This process is called single sign-on.
Integrating K2 with Netegrity SiteMinder
3
Technical Note
Overview of Netegrity SiteMinder Integration
Those same credentials are also used by a Verity gateway to satisfy any authentication requests
resulting from search and view requests. The user is not challenged for credentials when required
by the gateway, and the credentials are trusted and not authenticated by the gateway. This
process is called pre-authentication.
Figure 1 Single Sign-on
Note
Single sign-on integration does not allow the user to log into K2
administration automatically. If K2 administration is protected by a K2 Ticket
Server, the administrator must enter a user name and password in the K2
Dashboard and rcadmin regardless of whether single sign-on is enabled.
Search and Viewing Integration
When the Verity HTTP gateway is integrated with SiteMinder, K2 enforces document-level
security based on SiteMinder’s security policies.
Note
Index-level security using SiteMinder group definitions is not supported.
Document-Level Security
K2 observes the underlying security privileges defined by SiteMinder to control whether a
document appears in a results list, and whether a user can retrieve it. If results list filtering is
enabled, the gateway sends an authorization request and SMSESSION cookie to the SiteMinder
Policy Server for each returned result from a user’s search. If the Policy Server denies access, the
result is removed from the results list.
4
Integrating K2 with Netegrity SiteMinder
Technical Note
Overview of Netegrity SiteMinder Integration
Figure 2 Results List Filtering with SiteMinder
Authorization for document viewing occurs in one of two ways, depending on whether
document highlighting is enabled. If document highlighting is not enabled, the K2 application
requests the document directly from the Web server. The Web Agent retrieves the SMSESSION
cookie from the user’s request and approves or denies access to the document based on the
contents of the SMSESSION cookie.
Figure 3 Viewing SiteMinder-Protected Content—Highlighting Disabled
Integrating K2 with Netegrity SiteMinder
5
Technical Note
Overview of Netegrity SiteMinder Integration
If document highlighting is enabled, the HTTP gateway sends an SMSESSION cookie and the
document URL to the Web server’s Agent. The Web Agent allows or denies access to the
document based on the contents of the SMSESSION cookie. The gateway then highlights the
document prior to sending it to the user’s browser.
Figure 4 Viewing SiteMinder-Protected Content—Highlighting Enabled
Indexing Integration
When K2 Spider is integrated with SiteMinder, K2 Spider can index content on a Web server
protected by SiteMinder using either basic or forms authentication. When indexing a repository
protected by forms authentication, K2 Spider downloads the HTML form and inserts the
credential information specified in the indexing job (jobs.ini file). It then submits the form to
the form’s action URL for processing. If the login fails, either the same form is returned, or an
error page defined in the indexing job is generated.
6
Integrating K2 with Netegrity SiteMinder
Technical Note
Overview of Netegrity SiteMinder Integration
Figure 5 Indexing SiteMinder-Protected Content
Enhancing Performance
Results list filtering can place a heavy load on the SiteMinder Policy Server because an
authorization request is sent to the server for every returned result. It is recommended you install
a dedicated Siteminder Policy Server to be used for K2 results list filtering.
Performance may also be improved by restricting the maximum number of documents returned
from a search by setting the maxDocs parameter. When the number of documents is limited, K2
stops the search after the maximum number of documents are found and before the entire
collection is searched.
To set the maximum number of documents returned from a search:
„
Using the VSearch Java API, call the setMaxDocCount method in the VSearch object. See the
VSearch Javadoc.
„
Using the Component Framework, define the maxdocs component. See the Verity Component
Framework Developer Guide.
„
Using the Client C API, set the maxDocs member in the K2SearchNew function. See the Verity
K2 Client Programming Guide.
Integrating K2 with Netegrity SiteMinder
7
Technical Note
Configuring Netegrity SiteMinder
Required Configuration
To integrate Netegrity SiteMinder with K2, you must configure all of the following components:
„
Netegrity SiteMinder. See “Configuring Netegrity SiteMinder” on page 8.
„
The K2 application. See “Integrating the K2 Application” on page 18.
„
The K2 system, including a K2 Ticket Server, the ticket-granting login module (k2lmtg), the
gateway, and K2 Spider. See “Configuring the K2 System” on page 27.
Note
Since a style set must be created specifically for SiteMinder through the
StyleSet Editor, the Verity Business Console must be installed and configured
on the Master Administration Server. Select a Full installation on the Master
Administration Server when installing K2.
Configuring Netegrity SiteMinder
To ensure K2 can access documents protected by SiteMinder, you must configure SiteMinder as
follows:
„
Create a K2 Web Agent. See “Creating a Web Agent for K2” on page 8.
„
Add the K2 Agent to an Agent Group. See “Adding the K2 Agent to an Agent Group” on
page 10.
„
Ensure the Web Agents protecting resources that will be searched by K2 accept cookies from
Custom Agents, and they pass the user variable (SM_USER, HTTP_SM_USER, or sm-user) in
the HTTP header. See “Configuring the Web Agent Configuration Object” on page 12.
„
Define a HEAD rule action for the Web Agent type. See “Defining a HEAD Web Agent Rule
Action” on page 14.
„
Ensure protected realms use a basic or HTML form authentication scheme. See “Defining the
Authentication Scheme” on page 17.
Creating a Web Agent for K2
For results list filtering and viewing, the gateway requires the following information about the
SiteMinder Web Agents protecting repositories:
8
„
Agent name
„
Authentication URL (login form) or credentials for basic authentication
„
Netegrity Policy Server IP address
„
Shared secret
Integrating K2 with Netegrity SiteMinder
Technical Note
Configuring Netegrity SiteMinder
When creating a Web Agent in SiteMinder 5.x and higher, defining a shared secret is optional and
is only available for Web Agents supporting SiteMinder 4.X. Most likely, your existing Agents do
not have shared secrets defined. The simplest way to ensure a shared secret is available to the
gateway is to create a K2 Web Agent with a shared secret specified, and add this Web Agent to the
Agent Groups protecting resources you want K2 to search.
To create a Web Agent for K2, follow these steps:
1. Log into the Netegrity Policy Server.
2. Select the System tab in the SiteMinder Administration window.
3. Click the Agents object in the System Configuration pane.
Figure 6 Agent List
4. From the menu bar, select Edit | Create Agent. The Agent Properties dialog box opens.
Figure 7 Agent Properties Dialog Box
Integrating K2 with Netegrity SiteMinder
9
Technical Note
Configuring Netegrity SiteMinder
5. In the Name field, enter the name of the new Agent. This name is case-insensitive, and must be
7-bit ASCII characters, in the range 32-127.
6. In the Description field, enter a short description of the Agent. This is optional.
7. Select the Support 4.x agents check box. A further set of controls specific to 4.x Agent types
appears in the lower part of the dialog box.
8. In the Agent Type group box, select the SiteMinder option button, and from the drop-down
list, select Web Agent.
9. In the IP Address or Host Name field, enter the IP address or the host name where K2 is
installed.
10.In the Shared Secret field, enter an alphanumeric shared secret that the K2 Agent uses to
decrypt data sent by the Policy Server. The secret must be between 1 and 255 characters in
length and contain no embedded spaces.
11.In the Confirm Secret field, re-enter the shared secret.
12.Click OK to save the changes and return to the SiteMinder Administration window. Your new
Agent is added to the Agent List.
Adding the K2 Agent to an Agent Group
The new K2 Agent must now be added to an Agent group, and the Agent group must be assigned
to the realm that K2 will index. An Agent group is a collection of Agents of the same type
grouped together for common resource protection. By adding the K2 Agent to the Agent group,
the K2 Agent adopts the global policy of the group.
To add the K2 Agent to an Agent group, follow these steps:
1. Click the System tab in the SiteMinder Administration window. If you do not see Agent
Groups listed in the System Configuration pane, click the View menu, and select Agent
Groups.
2. Click the Agent Groups object in the System Configuration pane.
Figure 8 Agent Group List
10
Integrating K2 with Netegrity SiteMinder
Technical Note
Configuring Netegrity SiteMinder
3. Double-click the Agent group to which you want to add the K2 Agent. The Agent Group
Properties dialog box opens.
Figure 9 Agent Group Properties Dialog Box
4. Click Add/Remove. The Available Agents and Groups dialog box opens.
Figure 10 Available Agents and Groups Dialog Box
5. Select the K2 Agent from the Available Members list.
6. Click the Left Arrow to move the K2 Agent to the Current Members list.
7. Click OK. The K2 Agent should be listed in the Group Members group box in the Agent Group
Properties dialog box.
8. Click OK in the Agent Group Properties dialog box.
Integrating K2 with Netegrity SiteMinder
11
Technical Note
Configuring Netegrity SiteMinder
Now you must ensure the Agent group containing the K2 Agent is assigned to the realm(s) that
K2 will index. If a realm’s properties contains an Agent name, replace the Agent name with the
Agent group name:
1. Click the Domain tab in the SiteMinder Administration window.
2. Expand the policy domain, and double-click the realm you want to modify. The Realm
Properties dialog box opens.
Figure 11 Realm Properties Dialog Box
3. In the Resource group box, enter the Agent group name in the Agent field, and click OK.
Configuring the Web Agent Configuration Object
Any Web Agent protecting a resource that will be indexed or searched by K2 must accept
SMSESSION cookies generated by a Custom Agent (the Verity gateway), and include the
SiteMinder user variable in the HTTP header. By default, the user variable is included in the
header, and this setting does not normally need to be changed. Both parameters are defined in an
Agent’s configuration object.
To specify these settings, follow these steps:
1. Click the System tab in the SiteMinder Administration window.
2. Select the Agent Conf Objects object in the System Configuration pane.
12
Integrating K2 with Netegrity SiteMinder
Technical Note
Configuring Netegrity SiteMinder
Figure 12 Agent Configuration Object List
3. In the Agent Conf Object List, double-click the configuration object for the Agent you want to
modify. The Agent Configuration Objects Properties dialog box opens.
Figure 13 Agent Configuration Object Properties Dialog Box
4. In the Agent Configuration Object Properties dialog box, select the parameter
acceptTPCookie. If the value is set to no, click Edit. The Edit Parameter dialog box opens.
Integrating K2 with Netegrity SiteMinder
13
Technical Note
Configuring Netegrity SiteMinder
Figure 14 Edit Parameter Dialog Box
5. In the Edit Parameter dialog box, type yes in the Value field, and click OK.
6. In the Agent Configuration Object Properties dialog box, select the parameter
DisableUserVars.
If the value is set to yes, click Edit, type no in the Value field, and click OK. Otherwise, proceed
to step 7.
7. In the Agent Configuration Object Properties dialog box, click OK.
Defining a HEAD Web Agent Rule Action
K2 Spider uses the HTTP HEAD Web Agent rule action to retrieve information about a document
without actually downloading the document. SiteMinder by default does not allow HEAD
actions, so it must be defined for any Web Agent monitoring a repository that is indexed by K2
Spider. Rule actions are defined in the Agent type and are associated with a realm’s rules. The
default actions are GET, POST, and PUT.
To ensure the Web Agent type includes a HEAD action, follow these steps:
1. Click the System tab in the SiteMinder Administration window. If you do not see Agent Types
listed in the System Configuration pane, click the View menu, and select Agent Types.
2. Click the Agent Types objects in the System Configuration pane.
14
Integrating K2 with Netegrity SiteMinder
Technical Note
Configuring Netegrity SiteMinder
Figure 15 Agent Type List
3. From the Agent Type List, double-click the Web Agent type you want to modify. The Agent
Type Properties dialog box opens.
Figure 16 Agent Type Properties Dialog Box
4. If HEAD is not listed under Actions, then click Create, type HEAD, and click OK.
5. In the Agent Type Properties dialog box, click OK to save the changes and return to the
SiteMinder Administration window.
Next, verify that your policy rule contains the updated list of actions.
Integrating K2 with Netegrity SiteMinder
15
Technical Note
Configuring Netegrity SiteMinder
6. In the SiteMinder Administration window, click the Domains tab.
Figure 17 List of Rules and Realms
7. Expand the Domain object and click Realms to show the rules applied to each realm. A realm is
a Netegrity Policy Server object that identifies a group of resources. Realms typically define a
directory or folder and possibly its subdirectories.
8. To enable the HEAD action in a rule, double-click the rule. The Rule Properties dialog opens.
Figure 18 Rule Properties
9. Select HEAD in the Web Agent Action list. Click OK.
16
Integrating K2 with Netegrity SiteMinder
Technical Note
Configuring Netegrity SiteMinder
Defining the Authentication Scheme
SiteMinder supports a variety of authentication schemes; however, K2 only supports basic (user
name/password) authentication and HTML forms-based authentication. Authentication schemes
are assigned to realms. When a user tries to access a resource in a realm, the authentication
scheme of the realm determines the credentials that a user must supply in order to access the
resource. Any realm that will be accessed by K2 must use one of the supported schemes.
To change the authentication scheme of a realm, follow these steps:
1. Click the Domains tab in the SiteMinder Administration window.
2. Expand the Domain object and double-click the realm you want to modify. The Realm
Properties dialog box opens.
Figure 19 Realm Properties Dialog Box
3. From the Authentication Scheme drop-down list, select an authentication scheme that uses the
Basic Template or HTML Form Template authentication scheme type. Click OK.
Integrating K2 with Netegrity SiteMinder
17
Technical Note
Integrating the K2 Application
Integrating the K2 Application
A typical non-single sign-on K2 application includes a JSP/ASPx page with a form that gathers
user credentials and subsequently calls K2 APIs that login the user. In a SiteMinder single sign-on
system, the K2 application must retrieve the SMSESSION cookie, and the user ID variable from
the HTTP headers and pass them to the K2 credentials. The single sign-on login process is as
follows:
1. The SiteMinder Web Agent challenges the user for credentials.
2. The SiteMinder Web Agent sends the credentials to the SiteMinder Policy Server.
3. The Policy Server returns authorization to the Web Agent.
4. The Web Agent creates an SMSESSION cookie on the client’s browser. This cookie contains
SMSESSION which is the session ID for the user’s session, and SM_USER which is the user’s ID.
5. The K2 application retrieves the SMSESSION and SM_USER from the Web header and passes
them to the K2 credentials.
6. The K2 application passes the credential information to the K2 Ticket Server.
Note
The K2 Ticket Server does not authenticate the user against the SiteMinder
Policy Server.
7. The Ticket Granting Login module (k2lmtg) issues a ticket and passes the ticket to the K2
application.
8. The K2 ticket is kept in memory until the ticket expires.
With SiteMinder, the K2 application must retrieve the following user variables from the Web
header, and pass them to the K2 credentials:
Table 1
SiteMinder User Variables
Environment
User variable
Session variable
Windows ASPx
HTTP_SM_USER
SMSESSION
Windows JSP
SM_USER
SMSESSION
Unix platform
sm-user
SMSESSION
The user variable is passed through the USERNAME_KEY, and the session variable is passed either
through the EXTENSION_KEY or the USER_PARAMS key.
EXTENSION_KEY and USER_PARAMS Key
The EXTENSION_KEY and USER_PARAMS key contain extended user data in the form of name/
value pairs enabling pre-authenticated access into the gateway. With pre-authentication
enabled, the gateway does not authenticate the user, but simply validates the SMSESSION cookie.
When the SMSESSION cookie is passed through the EXTENSION_KEY or USER_PARAMS keys
pre-authentication mode must be enabled in the K2 Ticket Server and the gateway. See “Enabling
Pre-Authentication in the K2 Ticket Server” on page 30 and “Configuring the Gateway” on
page 32.
18
Integrating K2 with Netegrity SiteMinder
Technical Note
Integrating the K2 Application
You would typically use the EXTENSION_KEY to pass user data when the collections you are
searching have pre-authentication enabled, are protected by SiteMinder, and access HTTP
repositories only. You would typically use the USER_PARAMS key when the collections you are
searching have pre-authentication enabled, are protected by SiteMinder, and access different
types of repositories, such as Documentum, Lotus Notes, and HTTP.
To set the EXTENSION_KEY, define the key name as SMESESSION, and the value of SMSESSION
using the VSearch.setExtensionCredential (String_key, String_value) method.
See the VSearch Javadoc for more information.
To set the USER_PARAMS key, use the VSearch.addUserParamCredential(userParams)
method. See the VSearch Javadoc for more information. The format of the USER_PARAMS key is
as follows:
USER_PARAMS=$$name:smsession_value1\tsmsession_value2$$
where,
name is the gateway-specific key. For the HTTP gateway, the key is HTTP_NETG.
value is the data entry for the key
\t is a separator for multiple values
Sample Code
<%@ page import="java.net.*" %>
<%@ page import="com.verity.search.*" %>
String serverSpec="localhost:9948";
VSearch vs = new VSearch();
vs.setServerSpec(serverSpec);
//Retrieve the header information passed after authenticating to the JSP
page:
String sm_user=null;
String smsession=null;
String sm_user = request.getHeader("SM_USER");
String smsession = request.getHeader("smsession_value");
//Alternatively, you can retrieve the cookie using
request.getHeader(“cookie”), and process the cookie until you reach
SMSESSION and its value.
//Set k2UserName and pass SMSESSION. The following example uses the
USER_PARAMS key:
String userParams=null;
vs.setK2UserName(sm_user);
userParams = "$$HTTP_NETG:" + smsession + "$$";
vs.addUserParamCredential(userParams);
sess.putValue("user",sm_user);
ticket = vs.k2Login();
Integrating K2 with Netegrity SiteMinder
19
Technical Note
Integrating the K2 Application
//Set k2UserName and pass SMSESSION. The following example uses the
EXTENSION_KEY:
String extensionKeyname=null;
String extensionKeyvalue=null;
extensionKeyname= "SMSESSION";
extensionKeyvalue = smsession_value;
vs.setExtensionCredential(extensionKeyname, extensionKeyvalue);
vs.setK2UserName(sm_user)
ticket = vs.k2Login();
//Put the ticket as the session variable:
sess.putValue("ticket", ticket);
You can also retrieve the header information and set the credentials through the Login APIs
provided by the remote context. For example:
<%@ page import="java.util.*" %>
<%@ page import="com.verity.search.*" %>
<%@ page import="java.net.*" %>
<%@ page import="com.verity.rpc.*" %>
String
String
String
String
String
String
serverSpec="localhost:9948";
sm_user=null;
smsession=null;
extensionKeyname=null;
extensionKeyvalue=null;
userParams=null;
String sm_user = request.getHeader("SM_USER");
String smsession = request.getHeader("smsession_value");
RemoteContext ctx = new RemoteContext();
ctx.setServerSpec(serverSpec);
AuthenticationProperties props = new AuthenticationProperties();
//Set username and pass SMSESSION. The following example uses the
USER_PARAMS key:
userParams = "$$HTTP_NETG:" + smsession + "$$";
props.setUserParam(userParams);
Ticket g_objTicket = ctx.login("sm_user",null,props);
ticket=g_objTicket.toString();
//Set username and pass SMSESSION. The following example uses the
EXTENSION_KEY:
extensionKeyname="SMSESSION";
extensionKeyvalue=smsession_value;
props.setExtensionCredential (extensionKeyname, extensionKeyvalue);
Ticket g_objTicket = ctx.login("sm_user",null,props);
ticket=g_objTicket.toString();
20
Integrating K2 with Netegrity SiteMinder
Technical Note
Integrating the K2 Application
Using the Component Framework
To set credential information using the Component Framework, follow these steps:
1. Before the login component is drawn, set AutoLogin to TRUE through the application
config.xml or the setParam() method in the VComponents API. For example:
components.setParam("loginBox","AutoLogin","true");
2. Forward the SM_USER and SMSESSION to the login component page and pass the SM_USER
and SMSESSION to the EXTENSION_KEY or USER_PARAMS key through the setParam()
method of the VComponents API.
The following example passes the credential information through the EXTENSION_KEY:
java.util.Properties p = new java.util.Properties();
p.put("key","SMSESSION");
p.put("value","smsession_value");
components.setParam("loginBox","ExtensionKey",p);
The following example passes the credential information through the USER_PARAMS key:
java.util.Properties p = new java.util.Properties();
String userParams= "$$HTTP_NETG:" + smsession + "$$";
components.setParam("loginBox","UserParamCredential",userParams);
3. Draw the Login component. If the login is successful, the component redirects the browser to
the refer page. If the login fails, the component is drawn with an error message.
4. The K2 application passes the credential information to the K2 Ticket Server which, using the
Ticket Granting Login module (k2lmtg), issues a ticket and passes the ticket to the K2
application. The K2 ticket is kept in memory until the ticket expires.
For more information on the Component Framework, see the Verity Component Framework
Developer Guide.
Sample Code Using the Component Framework
//Set the AutoLogin option to TRUE through either the application
config.xml or the setParam() method of the VComponents API.
//To set AutoLogin in the application config.xml:
<LoginComponent Name="loginBox" Xsl="loginBox.xsl">
<DefaultReferPage>index.jsp</DefaultReferPage>
<AutoLogin> true </AutoLogin>
<IgnoreRequestRefer>true</IgnoreRequestRefer>
<MaximumRetries>3</MaximumRetries>
</LoginComponent>
Integrating K2 with Netegrity SiteMinder
21
Technical Note
Integrating the K2 Application
//To set AutoLogin using the setParam() method of the VComponents API in
the JSP page:
<%@ page import="com.verity.component.VComponents" %>
<%@ page import="java.util.*" %>
<%@ page import="java.net.*" %>
<% VComponents components = VComponents.getInstance(pageContext,
"search");%>
<%=components.draw("logoffButton")%>
<%
components.setParam("loginBox","AutoLogin","true");
components.setParam("loginBox","User","sm_user");
//Set SMSESSION through either the EXTENSION_KEY or the
USERPARAMS key:
java.util.Properties p = new java.util.Properties();
//Set SMSESSION through the EXTENSION_KEY:
p.put("key","SMSESSION");
p.put("value"," smsession_value");
components.setParam("loginBox","ExtensionKey",p);
//Set SMSESSION through the USERPARAMS key:
String userParams= "$$HTTP_NETG:" + smsession + "$$";
components.setParam("loginBox","UserParamCredential",userParams);
String loginStr = components.draw("loginButton");
%>
Managing Expired Sessions
To manage an expired session, call the checkK2Ticket method in VSearch to check whether
the ticket issued by K2 Ticket Server is still valid. If the ticket is not valid, call the k2Login
method to re-issue the login request to get a new ticket.
If the SMSESSION cookie expires, but the K2 ticket is valid, a search request returns a message
indicating the user is invalid, and requests gateway credentials. To handle this situation, the JSP/
ASPx code should log out the user, re-issue a new login, retrieve a new K2 ticket, and re-send the
search request. The new login credentials would contain a new valid SMSESSION cookie
retrieved from the Web headers.
22
Integrating K2 with Netegrity SiteMinder
Technical Note
Integrating the K2 Application
Managing Cross-Site Scripting (XSS) Detection
Netegrity SiteMinder has a feature intended to prevent malicious users from submitting Cross
Site Scripting (XSS) attacks through Web applications. When XSS checking (referred to as CSS
checking in SiteMinder) is enabled, the Web Agent will not accept a Verity Query Language
(VQL) search containing escaped and unescaped versions of characters that are defined in the
BadUrlChars field of the Web Agent’s configuration object. If these characters are found,
SiteMinder blocks the request and sends an “HTTP 403 ACCESS FORBIDDEN” message to the
Web Agent.
To prevent VQL queries from being blocked by the XSS feature in SiteMinder, you must include
the following functionality in the K2 Search page:
„
Within the K2 application, create a JavaScript function that encodes suspicious characters for
an arbitrary string. See “JavaScript Function to Encode Characters” on page 24.
„
Within the K2 search form, add an onSubmit event handler that calls the JavaScript function
with input field(s). See “Search Submit Form” on page 24.
„
Create a decoding function in the language of your server side platform that decodes the
encoded characters. See “Decoding Query Parameter Values” on page 26.
„
For each encoded request parameter, call the decode function before using its value.
„
Create an encoding function that encodes the query string within a composed viewing URL.
See “Encoding Query Text within Viewing URL” on page 26.
„
Create a decoding function that decodes the query text before viewing, for example in
VVStreamer.java. See “Decoding Query Text before Viewing” on page 26.
You can encode some or all non-alphanumeric characters. The example in the next section
encodes only selected characters.
Integrating K2 with Netegrity SiteMinder
23
Technical Note
Integrating the K2 Application
Sample Code
JavaScript Function to Encode Characters
The encode function accepts any form and an array of input names to encode. It defines an
encoding similar to entity encoding (see encodestr function). Entity coding is not used because
in entity coding, the ampersand is a reserved character for query parameters.
function encode(form,inputnames) {
for (var i=0; i<inputnames.length; i++) {
var input = match(form,inputnames[i]);
if (input != null) {
var origval = input.value;
input.value = encodestr(origval);
//alert(origval+' enc='+input.value);
}
}
return true;
}
function encodestr(s) {
s = ('' + s).replace(/&/g,'!am;');
s = s.replace(/</g,'!lt!');
s = s.replace(/>/g,'!gt!');
s = s.replace(/"/g,'!dq!');
s = s.replace(/;/g,'!sc!');
s = s.replace(/'/g,'!sq!');
return s;
}
function match (form,inputname) {
for (var i = 0; i < form.length; i++){
if (form.elements[i].name == inputname) {
return form.elements[i];
}
}
return null;
}
function doSubmit(form,inputnames) {
if (collcheck()) {
return encode(form,inputnames);
}
return false;
}
Search Submit Form
<form name="echo" METHOD="GET" ACTION="search.jsp"
onSubmit="return doSumbit(this,new Array('QueryText','LastQuery'));">
24
Integrating K2 with Netegrity SiteMinder
Technical Note
Integrating the K2 Application
The XSSUtil class
package com.verity.partnerint.util;
public class XSSUtil {
static String items[][]={
{"!sc!",";"},
{"!lt!","<"},
{"!gt!",">"},
{"!sq!","'"},
{"!dq!","\""},
{"!am!","&"}
};
public static String decode(String s) {
StringBuffer sb = new StringBuffer(s);
for (int i = 0; i < items.length; i++) {
int idx;
do {
idx = indexOf(sb.toString(), items[i][0]);
if (idx == -1)
break;
sb.replace(idx, idx + 4, items[i][1]);
} while (true);
}
return sb.toString();
}
public static String encode(String s) {
StringBuffer sb = new StringBuffer(s);
for (int i = 0; i < items.length; i++) {
int idx;
do {
idx = indexOf(sb.toString(), items[i][1]);
if (idx == -1)
break;
sb.replace(idx, idx + 1, items[i][0]);
} while (true);
}
return sb.toString();
}
//JDK 1.3 does not have this method for StringBuffer. It is replicated
here
static int indexOf(String s,String item) {
for (int i=0;i<s.length();i++) {
String sub=s.substring(i);
if (sub.startsWith(item))
return i;
}
return -1;
}
Integrating K2 with Netegrity SiteMinder
25
Technical Note
Integrating the K2 Application
public static void main (String[] args) {
System.out.println("in="+args[0]);
String dec=XSSUtil.decode(args[0]);
String encdec=XSSUtil.encode(dec);
System.out.println("decode="+dec);
System.out.println("re-encoding="+encdec);
}
}
Decoding Query Parameter Values
String queryText=request.getParameter("QueryText");
if(queryText == null){
queryText = "";
} else {
queryText = XSSUtil.decode(queryText);
}
// last query is the saved queryof last time before refine query.
String lastQuery = request.getParameter("LastQuery");
if(lastQuery == null){
lastQuery = "";
} else { //XSS
lastQuery = XSSUtil.decode(lastQuery);
} //XSS
Encoding Query Text within Viewing URL
viewingURL = req.getContextPath() + "/jsp/view.jsp?k2dockey=" +
MbEncoder.encode(doc.field("K2DocKey"),jenc) + "&serverSpec=" +
ksearch.serverSpec + "&querytext=" +
MbEncoder.encode(XSSUtil.encode(ksearch.allQuery),jenc);
Decoding Query Text before Viewing
String queryText=request.getParameter("querytext");
queryText = XSSUtil.decode(queryText);
26
Integrating K2 with Netegrity SiteMinder
Technical Note
Configuring the K2 System
Configuring the K2 System
To enable a full integration with Netegrity SiteMinder, the following K2 components must be
configured:
„
The K2 Ticket Server must be configured to accept an authenticated user ID from SiteMinder
as trusted or “pre-authenticated.” It therefore does not perform any authentication itself. See
“Configuring a K2 Ticket Server” on page 27.
„
A style set must be created specifically for SiteMinder, and must include the following
configuration:
…
Define the SiteMinder-secured realms, their associated Policy Server, and Web Agents. A
realm is a Netegrity Policy Server object that identifies a group of resources. Realms typically
define a directory or folder and possibly its subdirectories. In K2 terms, a SiteMinder realm
is a repository. See “Configuring the Gateway” on page 32.
…
Accept pre-authenticated credentials. See “Configuring the Gateway” on page 32.
…
If forms authentication is enabled on a SiteMinder realm, the SiteMinder realm and the
authentication form used to protect the site must be defined in the style set. See “Defining
SiteMinder Realms” on page 34 and “Defining Authentication Forms” on page 36.
„
A collection must be created using the new SiteMinder style set. See “Creating a Collection
Using the SiteMinder Style Set” on page 37.
„
If basic authentication is used to protect a SiteMinder realm, the user name and password
must be defined in the indexing job. See “Configuring the Indexing Job” on page 40.
„
If forms authentication is used to protect a SiteMinder realm, the indexing job must enable the
authentication form (defined in the SiteMinder style set), and define the values K2 Spider will
use when the Crawler encounters a redirect to the form. See “Configuring the Indexing Job” on
page 40.
Configuring a K2 Ticket Server
To enable single sign-on with SiteMinder in the K2 system, you must add a K2 Ticket Server with
the following configuration:
„
Enable the K2 Ticket-Granting login module (k2lmtg). The Ticket-Granting login module
grants a ticket based on the user name only; it assumes the user is already authenticated, and
creates a ticket for any user name entered.
„
Enable the use of login credentials to authenticate to the repository.
„
Enable pre-authentication mode.
„
Attach the K2 Server or K2 Broker that is managing search requests for SiteMinder-protected
repositories to the new K2 Ticket Server.
Note
The K2 Ticket Server used for SiteMinder uses the K2 Ticket Granting login
module which is not secure. Do not use this K2 Ticket Server to protect K2
administration. Protect K2 administration with a K2 Ticket Server that uses a
more secure login module.
Integrating K2 with Netegrity SiteMinder
27
Technical Note
Configuring the K2 System
You can use the K2 Dashboard or the rcadmin command-line tool to configure the K2 Ticket
Server. The procedure below demonstrates the configuration through the K2 Dashboard. For
more information on rcadmin, see the Verity K2 rcadmin Guide.
To add a K2 Ticket Server to be used for single sign-on, follow these steps:
1. In the tree at the left-hand side of the K2 Dashboard, select the K2 Ticket Servers folder. The K2
Dashboard displays the K2 Ticket Server Summary page.
2. Select the Add a K2 Ticket Server action.
3. If there is more than one Administration Server in your K2 system, select the Administration
Server on which the K2 Ticket Server will reside.
4. Click Continue. The K2 Dashboard displays the first step for adding a K2 Ticket Server to the
system:
Figure 20 Adding a K2 Ticket Server—Basic Settings
Configuring Basic K2 Ticket Server Settings
To configure basic settings for the new K2 Ticket Server, follow these steps:
1. In the Service Alias field, enter a unique identifier for the K2 Ticket Server.
2. In the Description field, enter a brief description of the K2 Ticket Server. This entry is optional.
3. In the Port field, enter the port number for the K2 Ticket Server.
4. Click Next. The K2 Dashboard displays the second step for adding a K2 Ticket Server to the
system:
28
Integrating K2 with Netegrity SiteMinder
Technical Note
Configuring the K2 System
Figure 21 Adding a K2 Ticket Server—Selecting the User-Defined Login Module
Setting the Login Module
To enable pre-authentication mode with SiteMinder, you must use the Ticket-Granting login
module (k2lmtg). The Ticket-Granting module grants a ticket based on the user name only; it
assumes the user is already authenticated, and creates a ticket for any user name entered.
To configure the K2 Ticket Server for pre-authentication with the Ticket-Granting login module,
follow these steps:
1. Select User-Defined from the Login Module type list box.
2. Enter k2lmtg in the Dynamic Library Name field. This is the name of the dynamic library
containing the K2 Ticket-Granting login module. The libraries are stored in the following
directory:
installDir/k2_6/k2/_platform/bin
where installDir is the pathname of the Verity installation directory (for example, usr/
verity/ on UNIX, or C:\Program Files\Verity on Windows).
Name/Value pairs are not required for k2lmtg because the module issues a ticket for any user
name.
3. Click Next. The K2 Dashboard displays the third step for adding a K2 Ticket Server to the
system:
Integrating K2 with Netegrity SiteMinder
29
Technical Note
Configuring the K2 System
Figure 22 Adding a K2 Ticket Server—Configuring the Persistent Store Module
Setting the Persistent Store Module
The K2 Ticket Server requires a persistent store module (PSM) to operate. To set the persistent store
module, follow these steps:
1. Select File and Memory from the Persistent Store Module type list box.
2. Select the Override Default Storage File Path check box if you store your cstore.psm file
outside the default location of data/services/ticket, where data is the directory
specified during installation.
3. If you are overriding the default path, identify the cstore.psm location in the Path field.
4. Click Finish. K2 displays the new K2 Ticket Server’s detail page.
Enabling Pre-Authentication in the K2 Ticket Server
Next, configure the K2 Ticket Server to accept an authenticated user ID from SiteMinder as
trusted or pre-authenticated.
1. Select the Edit Properties action on the new K2 Ticket Server’s detail page.
30
Integrating K2 with Netegrity SiteMinder
Technical Note
Configuring the K2 System
Figure 23 Adding a K2 Ticket Server—Enabling Pre-authentication
2. On the General tab, select the Use Login Credentials check box. This specifies that the K2
Ticket Server will try to authenticate the user to the repository using the login credentials. This
way you are not prompted separately by the gateway for credentials.
3. On the General tab, select the Enable Pre Authentication check box. Enabling this check box,
adds a pre-authentication key (PREAUTH_KEY) to the login credentials. This informs the
gateway the user name is pre-authenticated.
4. If the SMSESSION cookie was passed to the login credentials through the EXTENSION_KEY,
select the Filter External USER_PARAM check box. This prevents authentication data passed
into the login credentials through the USER_PARAMS key from being passed into K2.
If the SMESSION cookie was passed through the USER_PARAMS key, ensure the Filter External
USER_PARAM check box is not selected.
5. Click Modify.
Attaching a K2 Server or K2 Broker
Next, attach the K2 Server or K2 Broker that is managing search requests for
SiteMinder-protected repositories to the new K2 Ticket Server.
1. Select the Manage K2 Broker/K2 Server Security action on the SiteMinder K2 Ticket Server’s
detail page. The K2 Dashboard displays a list of K2 Brokers or Servers that you can attach to the
Ticket Server.
Integrating K2 with Netegrity SiteMinder
31
Technical Note
Configuring the K2 System
Figure 24 Adding a K2 Ticket Server—Attaching the K2 Ticket Server
2. Select the K2 Servers or K2 Brokers option button, depending on the service you want to attach
to the Ticket Server.
3. In the list box, select the K2 Broker or Server you want to attach to the K2 Ticket Server. The K2
Dashboard displays the configured service.
4. Click Modify.
5. Perform a full restart on the K2 Server/K2 Broker and K2 Ticket Server.
Configuring the Gateway
To support results list filtering, document viewing, and indexing based on SiteMinder
authorization policies, you must create a new style set specifically for SiteMinder collections. The
new style set must include the following changes:
„
Define the SiteMinder-secured realms, their associated Policy Server, and Web Agents, and
enable pre-authentication. See “Defining SiteMinder Realms” on page 34.
„
If required, define authentication forms used by SiteMinder-protected resources. See
“Defining Authentication Forms” on page 36.
To create the SiteMinder style set, use the K2 Dashboard and the StyleSet Editor.
1. In the tree at the left-hand side of the K2 Dashboard, select the Collections folder. The K2
Dashboard displays the Collection Summary page.
2. Select the Manage Style Sets action. The K2 Dashboard lists the existing style sets in your
system.
When the K2 Dashboard displays the following message, you must prepare the StyleSet Editor
web application:
Note
32
If this message is not displayed, proceed to step 3.
Integrating K2 with Netegrity SiteMinder
Technical Note
Configuring the K2 System
a. Select the Verity Business Console Initialization page link in the notification message at the
top of the page. The Verity Business Console opens in a new browser window.
b. Select a K2 Server or K2 Broker to be used by the Business Console. Click Finish.
c. Click Exit, and close the Business Console browser window.
d. In the K2 Dashboard, click Go to Manage Style Sets.
3. Click Create. The K2 Dashboard displays the following:
Figure 25 Creating a Style Set—Basic Settings
4. In the Style Set Alias field, enter a name used to identify the new style set in the K2 Dashboard.
5. In the Description field, enter a brief description of the new style set. This entry is optional.
6. From the Gateway Type drop-down list, select HTTP Gateway.
7. Select the Clone Existing Style check box.
8. From the Style Set Alias drop-down list, select Def_HTTP_Secure.
9. Click Continue. The K2 Dashboard launches the StyleSet Editor.
In the StyleSet Editor, you must define the realms protected by SiteMinder and any
authentication forms protecting the resources.
Integrating K2 with Netegrity SiteMinder
33
Technical Note
Configuring the K2 System
Defining SiteMinder Realms
In the gateway, you must define each SiteMinder-protected realm (repository) that will be
indexed by K2. The definition includes the Web Agent, the Policy Server securing the realm, and
the SiteMinder authentication URL used to log into the realm.
1. In the StyleSet Editor, click the Defining SiteMinder Security Module Settings tab.
Figure 26 Creating a Style Set—Defining SiteMinder Security Module Settings Tab
2. In the SiteMinder Repository List, click the + button. The fields in the SiteMinder Repository
Definition section become active.
3. In the Agent Name field, enter the name of the SiteMinder K2 Web Agent protecting the realm.
K2 uses the K2 Web Agent to communicate with the Policy Server. See “Creating a Web Agent
for K2” on page 8.
4. In the Policy Server IP field, enter the IP address of the primary Policy Server protecting the
realm.
5. In the Shared Secret field, enter the shared secret that the K2 Agent uses to decrypt data sent
by the Policy Server. In the Confirm Shared Secret field, re-enter the text string. See “Creating
a Web Agent for K2” on page 8.
6. In the Authentication URL field, enter the URL of the SiteMinder login page for this realm.
7. In the URL Pattern(s) field, enter the URL patterns to those documents that are protected by the
Web Agent. In Figure 26, all pages matching the URL http://fox.verity.com/finance/
.* are protected by the finance_agent.
34
Integrating K2 with Netegrity SiteMinder
Technical Note
Configuring the K2 System
The URL patterns must be fully qualified, as in http://hostx.domain.ext, and the host
name must match what is specified in the starting points. For example, a URL pattern of
http://fox.verity.com/finance/.* for single sign on must be matched by http://
fox.verity.com/finance/ in a starting point.
8. Click Advanced to set parameters that define connections between the Web Agent (trusted
host) and the Policy Server.
Figure 27 Creating a Style Set—SiteMinder Repository Definition Advanced Properties
9. In the Initial number of connections field, enter the number of TCP/IP connections the Web
Agent opens when the Web server starts and a new connection is required. The value is defined
by the MinSocketsPerPort setting in the Host Configuration Object. The default is 3.
10.In the Maximum number of connections field, enter the maximum number of TCP/IP
connections that can be opened between the Web Agent and the Policy Server.
If the Web Agent receives more requests than the number specified in this field, then the
overflow requests are placed in a queue. To handle a heavier load of requests, increase this
value. The value is defined by the MaxSocketsPerPort setting in the Host Configuration
Object. The default is 10.
11.In the Connection increment field, enter the number of TCP/IP connections that are opened
between the Web Agent and the Policy Server when demand increases and more connections
are required. The value is defined by the NewSocketStep setting in the Host Configuration
Object. The default is 1.
12.In the Authorization server port field, enter the port number of the Authorization Server in the
SiteMinder Policy Server. The default is 44443.
13.In the Authentication server port, enter the port number of the Authentication Server in the
SiteMinder Policy Server. The default is 44442.
14.In the Accounting server port, enter the port number of the Accounting Server in the
SiteMinder Policy Server. The default is 44441.
15.In the Connection time out field, enter the number of seconds that the Web Agent should wait
before deciding a Policy Server is unavailable. If the Policy Server is busy due to heavy traffic or
a slow network connection, you may want to increase this value. The value is defined by the
RequestTimeout setting in the Host Configuration Object. The default is 75.
16.Click OK in the Advanced Properties dialog.
17.Repeat steps 1 through 16 for additional realms as required.
Integrating K2 with Netegrity SiteMinder
35
Technical Note
Configuring the K2 System
Defining Authentication Forms
If a SiteMinder resource is protected by an authentication form, the form—its login URL,
submission URL, form fields, and so on—must be defined in the HTTP gateway. The form must
then be enabled for a specific indexing job (see “Configuring the Indexing Job” on page 40).
1. In the StyleSet Editor, click the Defining Authentication Form Settings tab.
Figure 28 Creating a Style Set—Defining Authentication Form Settings Tab
2. In the Forms List section, click the + button. The fields in the Form Definition section become
active.
3. In the Alias field, enter a unique identifier for the authentication form. This is used by K2 to
identify the form in the K2 system.
4. In the Description field, enter a brief description of the form. This entry is optional.
5. In the Login URL field, enter the URL of the login page containing the authentication form. For
example, http://fox.verity.com/finance/login.jsp.
6. Click Extract Fields to parse the login page, and populate the Action URL, Error URL,
Character set, and Field Name fields automatically.
Note
36
If the form contains Javascript, the Action URL field will not be extracted
automatically. In this case, enter the value manually.
Integrating K2 with Netegrity SiteMinder
Technical Note
Configuring the K2 System
7. In the URL Patterns field, enter the URL patterns to those documents that are protected by the
login page. In Figure 28, all pages matching the URL http://fox.verity.com/finance/
.* are protected by the form http://fox.verity.com/finance/login.jsp.
The URL patterns must be fully qualified, as in http://hostx.domain.ext, and the host
name must match what is specified in the starting points. For example, a URL pattern of
http://fox.verity.com/finance/.* for forms-based authentication must be matched
by http://fox.verity.com/finance/ in a starting point.
8. In the Action URL field, enter the URL of the page used to process the form. This entry is
optional. For example, http://fox.verity.com/finance/submit.jsp.
9. In the Error URL field, enter the URL of the page to which the K2 Spider is redirected when
authentication fails. This entry is optional. For example, http://www.fox.com/finance/
error.jsp.
10.In the Character Set field, enter the character set of the login page. This must be entered in
US-ASCII format, such as ISO_8859-1. See http://www.iana.org/assignments/character-sets
for a complete list of supported character sets. This entry is optional.
11.Select the GET method check box to specify that a GET submission method is used to submit
credentials to the form. By default, a POST method is used.
12.Select the Enable for Search and View check box to call this login form when a user searches
the collection and views a document from the collection. If this is not enabled, the login form is
only used when indexing the collection.
13.In the Field Name fields, enter the authentication parameters used in the form. For example,
username (user name), pword (password), or mmname (mother’s maiden name). The
password value is encrypted in K2.
A maximum of three fields, in addition to user name and password fields, can be defined for a
form.
14.In the Description field, enter a description of each field. This entry is optional. It is displayed
in the K2 Dashboard when assigning the form to an indexing job.
15.In the Default field, enter a default value for each field. This is the initial setting when
assigning the form to an indexing job.
16.Repeat steps 1 to 15 for additional forms as required.
17.Click OK on the Defining Authentication Form Settings tab.
Creating a Collection Using the SiteMinder Style Set
Next, create a collection of SiteMinder documents using the new style set.
1. In the tree at the left-hand side of the K2 Dashboard, select the Collections folder. The K2
Dashboard displays the Collection summary page.
2. Select the Add a Collection action.
3. If there is more than one Administration Server in your K2 system, select the Administration
Server on which the collection will reside.
Integrating K2 with Netegrity SiteMinder
37
Technical Note
Configuring the K2 System
4. Click Continue. The K2 Dashboard displays the first step for adding a collection to the system:
Figure 29 Adding Collection—Basic Settings
Configuring Basic Collection Settings
To configure basic settings for the new collection, follow these steps:
1. In the Index Alias field, enter a unique identifier for the new collection.
2. In the Description field, enter a brief description of the new collection. This entry is optional.
3. Click Next. The K2 Dashboard displays the second step for adding a collection to the system:
Figure 30 Adding a Collection—Selecting a Style Set
4. In the Gateway Type field, select HTTP Gateway.
5. In the Style Set field, select the alias of the SiteMinder style set created earlier.
6. In the Locale field, optionally select a locale if you do not want the collection to use the default
selection. When the Multilanguage locale is selected, you can also select the default language
used by VDK from the VDK Default Session Language field.
7. Select the Secure option button. This indicates the security level for searching and viewing the
collection.
38
Integrating K2 with Netegrity SiteMinder
Technical Note
Configuring the K2 System
8. Click Next. The K2 Dashboard displays the third step for adding a collection to the system:
Figure 31 Adding a Collection—Attaching the Collection
Attaching the Collection to a K2 Server
Next, attach the new collection to the K2 Server that is managing search requests for
SiteMinder-protected repositories.
1. From the K2 Servers list, select the K2 Server to which you want to attach the collection. The
selected Server and associated threads are listed in the Configured K2 Servers section.
2. Click Next. The K2 Dashboard displays the fourth step for adding a collection to the system.
Figure 32 Adding a Collection—Indexing
3. Select the Proceed to Indexing check box, and click Finish. The Add an Indexing Job action
page appears.
Integrating K2 with Netegrity SiteMinder
39
Technical Note
Configuring the K2 System
Figure 33 Adding a Job—Configuring the Indexing Job
You will now configure the indexing job for the SiteMinder collection. This requires you to
specify indexing starting points, and, either define credentials for basic authentication or enable
the appropriate login form for the job.
Configuring the Indexing Job
When K2 Spider indexes a SiteMinder realm protected by forms authentication, it must
download the HTML authentication form, insert credentials into the form, and submit the form
to the SiteMinder Agent for authentication. To enable this process, the form must first be defined
in the HTTP gateway (“Defining Authentication Forms” on page 36), and enabled for the
SiteMinder indexing job. Finally, the values required to complete the form must be defined in the
indexing job. K2 Spider will use these values when the Crawler encounters a redirect to the form.
If the SiteMinder realm is protected by basic authentication, the user name and password used to
access the site must be defined in the indexing job.
40
Integrating K2 with Netegrity SiteMinder
Technical Note
Configuring the K2 System
To configure the indexing job for basic or forms authentication, follow these steps:
1. On the General tab, click Add to add starting points from which K2 Spider will begin crawling.
The K2 Dashboard displays the Add Starting Points dialog:
Figure 34 Adding a Job—Adding Starting Points
2. Enter the starting point(s) for the collection. You can paste multiple starting points from
another file. Each starting point must exist on a separate line.
The URL patterns specified in the StyleSet Editor for the SiteMinder realm and the
authentication form must match the specified starting point. For example, the URL pattern
http://fox.verity.com/finance/.* for single sign on or forms-based authentication
must be matched by http://fox.verity.com/finance/ in a starting point.
3. If the starting point is a Web site protected by basic authentication, enter a valid user name and
password for the secure URL. The K2 Dashboard automatically creates a file called
vgwhttp.auth that contains the credentials.
By default, the domain from each secure starting point is used for the realm in the HTTP
header. If your Web server requires a specific realm for authentication, you can override the
default by entering a value in the Realm field.
4. Click Add.
5. Select the Authentication tab.
If the starting point is a Web site protected by basic authentication and has single sign-on
enabled, the Authentication tab displays the Agent names and URL patterns defined in the
SiteMinder Security Module Settings in the style set.
Integrating K2 with Netegrity SiteMinder
41
Technical Note
Configuring the K2 System
Figure 35 Adding a Job—Basic Authentication
If the starting point is a Web site protected by forms authentication and has single sign-on
enabled, the Authentication tab lists the Agent names and URL patterns defined in the
SiteMinder Security Module Settings, and the authentication forms defined in the style set.
Figure 36 Adding a Job—Selecting Authentication Forms
42
Integrating K2 with Netegrity SiteMinder
Technical Note
Security
6. Select an authentication form to be used by the job to access the SiteMinder Web site. The
authentication information defined in the style set is listed in the Authentication Form Fields
section.
7. In the Job Value field for each form field (for example, username, pword, and so on), enter the
value K2 Spider will enter when the Crawler encounters a redirect to this form.
8. Repeat steps 6 and 7 for any additional forms you want to enable for the job.
9. Complete any additional job fields as required and as described in the Verity K2 Dashboard
Administrator Guide.
10.Click Create. The K2 Dashboard creates the indexing job and displays its detail page.
11.To run the job, select the Start/Stop Job action in the job detail page.
Security
In pre-authentication mode, all the data required to access the K2 system is contained in the login
credentials. Therefore, a user only requires a valid user ID to access secure data. To minimize the
risk of a security breach, the following configurations are recommended:
„
Using standard security tools and practices, secure the Web server on which the K2 application
runs.
„
Enable trusted clients (IP Filtering) on the K2 services that have pre-authentication enabled.
See Verity K2 Dashboard Administrator Guide.
„
If you are passing the SMSESSION cookie through the EXTENSION_KEY, prevent any
authentication data passed into the login credentials through the USER_PARAMS key from
being passed to K2. See “Enabling Pre-Authentication in the K2 Ticket Server” on page 30.
Integrating K2 with Netegrity SiteMinder
43
Technical Note
Security
44
Integrating K2 with Netegrity SiteMinder