The following sections discuss coordination of SiteMinder and Domino authentication.
The DominoUseHeaderForLogin and DominoLookUpHeaderForLogin parameters can be used to identify a Domino user for authentication.
Instructs the Domino Web Agent to pass the SiteMinder header value to the Domino Web Server. The Domino server uses the header data to identify a user in its user directory.
Set this parameter to a header name. For example, if you specify DominoUseHeaderForLogin="HTTP_SM_USER", the Web Agent passes the user’s login name to the Domino server.
Instructs the Domino Web Agent to ask the Domino Web Server if the user requesting access to a resource is unique or ambiguous within the Domino user directory. This check is useful if a user named Jones tries accessing a resource and there are several users named Jones in the user directory. If this parameter is set to no, the Domino Web Agent does no checking with the Domino Web Server.
Default: Yes
SiteMinder provides authentication and authorization functionality; therefore, the Domino session authentication feature is not needed. It should be disabled if the Web Agent is installed.
Under some conditions, having Domino session authentication enabled causes the user session to behave differently. This change in behavior does not affect security on a SiteMinder-enabled site. It reflects the intersection of SiteMinder and Domino session management rules.
To protect Domino view (.nsf) resources with a forms authentication scheme, map the URLs before they are redirected to the forms credential collector.
Follow these steps:
Domino URLS are mapped before redirection to the FCC.
The process of URL normalization modifies URLs from a Domino representation to a URL format used by a typical web browser. The Domino Web Agent relies on the Domino web server APIs to normalize a Domino URL.
During the normalization process, the Domino Server APIs periodically return a URL with a carriage return (0x0D in hex) and/or a line feed character (0x0A in hex) added to the normalized URL. The addition of these characters appears to be related to specific Notes database (.nsf) files and access patterns within these files.
The following example shows a normalized URL with an added carriage return:
If necessary, you can ensure that URLs with Domino resource IDs are not normalized with the following parameter:
Specifies if the SiteMinder Web Agent converts Domino URLs to a URL-friendly name before redirecting them to a Forms Credential Collector.
The MapUrlsForRedirect parameter must also be set to yes for the Domino URLs to be converted.
If the DominoNormalizeUrls parameter is set to no, URLs will not be normalized, even if the MapUrlsForRedirect parameter is set to yes.
Important! If you set the DominoNormalizeUrls parameter to no, you cannot protect individual documents within a Notes database; you can only protect the entire database or subdirectories of the Domino Web server.
Default: Yes
To turn off normalization and ensure that URLs are not altered, set the DominoNormalizeUrls parameter to no.
The Web Agent offers a finer level of granularity for protecting Lotus Notes documents on Domino. The folloiwng parameter controls this protection:
Specifies how a Web Agent handles user requests for protected Lotus Notes documents in a Domino environment. Setting this parameter to yes grants users ReadForm permission only for the requested document.
Default: No
Use the DominoLegacyDocumentSupport parameter to configure the Web Agent to process user-requested actions when accessing Notes documents. This offers a finer granularity of protection on Domino.
Notes documents do not have names. They are saved to the database with a reference to the form used to create them. When a user requests a Notes document, the Domino Web Agent finds the form for that document by converting the request into a URL. This URL includes the original Domino action. If no form is found, then nothing is used.
For example:
"http://server.domain.com/db.nsf?OpenDocument"
in the URL To ensure that the Web Agent performs the user-requested Domino action on the document that is specified in the URL, such as ?OpenDocument or ?EditDocument, set the DominoLegacyDocumentSupport parameter to no.
For example, if the URL request is:
http://www.dominoserver.com/names.nsf/934873094893898778578439588098203985798349?EditDocument
The Domino Agent converts the preceding URL to:
http://www.dominoserver.com/names.nsf/Person?EditDocument
where Person is the name of the form used to create the document identified by the NotesID in the original URL.
To force the Domino Web Agent revert back to its pre-4.6 operation for accessing Notes documents, which means that only the action ?ReadForm is permitted, set this parameter to yes. With the legacy document support enabled, the Domino Agent would convert the URL in the previous example to:
http://www.dominoserver.com/names.nsf/Person?ReadForm
A credential collector is an application within the Web Agent, which gathers user credentials for forms, SSL, and Windows authentication schemes, and for single sign-on across multiple cookie domains. The credentials gathered by the credential collector are based on the type of authentication scheme configured for a particular group of protected resources.
For a Domino Web Agent to act as a credential collector, you have to configure various MIME types, represented as file extensions in the Agent configuration file.
Credential collectors are generally auto-authorized, that is, when you add a file extension to these parameters, they are, by default, included in the IgnoreExt parameter. Domino Server cannot correctly process URLs that include files with these extensions, so the Domino Agent has to ignore these files.
Note: For more information, see the Policy Server documentation.
The Domino Directory is integrated with every Domino server. You can enable LDAP service for the Domino server so that Policy Server can use the Domino Directory to authenticate and authorize users. If you enable Domino’s LDAP service, you do not need to configure a separate user directory for authentication.
To enable LDAP service, see your Domino Server documentation.
The Domino server can represent the same Notes object in different ways. An object can be identified using the name, ReplicaID, UniversalID, and alias.
For the Domino Web Agent to communicate effectively with the Domino server, the Domino Agent processes access requests to Notes resources using only the object name. This enables the SiteMinder policy store to understand the entry.
Expressed as a URL, the access method to any resource would be:
http://host/database.nsf/resource_name?Open
Actions for the Notes database resources should be considered when you create rules. Any resource not specified with an action will default to the action ?Open. The rules that are included in a SiteMinder policy must account for the default action, ?Open, and equivalent actions for ?Open, such as ?OpenDatabase, ?OpenView, ?OpenDocument, ?OpenFrameset.
The Domino Web Agent enables a policy administrator to create one rule for many aliases that point to the same resource. You only need one rule because the Domino Agent converts Domino’s multiple representations of a resource into one URL. This function of the Domino Agent is important to consider when creating rules for SiteMinder policies.
You create realms and rules using the Administrative UI.
Note: For more information, see the Policy Server documentation.
In the following illustration, the URL is a link to Acme’s Domino server, with a Notes database called db1.nsf. This database contains two files: page1 and page2.
Example 1: Protecting one document and all its aliases.
For access to page1 and all its aliases, you create only one rule for the realm db1.nsf. The Domino Agent is able to interpret all the different naming conventions and convert them to a one standard URL format.
For your realms and rules, do the following:
Resource filter: /db1.nsf/
To protect not only page1 but all its aliases, you would configure the following:
Resource filter: /db1.nsf/page1
Resource: *
This * wildcard indicates that any action, such as ?Open, ?EditDocument can be performed on page1 by the users that are bound to the policy.
Example 2: Protecting different documents in the same database.
To protect page2 in the db1.nsf database in addition to page1, you need to create a second rule.
Resource Filter: /db1.nsf/page2
Resource: *
Example 3: Protecting different actions on a single resource
To protect individual actions on a resource, for example, if you wanted only some users to perform the action ?EditDocument and all users to perform the action ?ReadForm, each action would require its own rule for each resource, as follows:
Resource Filter: /db1.nsf/page1
Resource: ?OpenView
Resource Filter: /db1.nsf/page1
Resource: ?EditDocument
You could also use one rule as follows:
Resource Filter: /db1.nsf/page
Resource: ?Open*
Note: In the Resource field, there is no forward slash (/) before ?Open.
Even if there are aliases for this resource, the one rule would protect the original page and all its aliases.
Instead of creating several rules for different actions, you could specify a single rule and use wildcards to cover all actions, for example:
Resource filter: /db1.nsf/page
Resource: ?Open*
With the rule, you are then protecting the resource:
http://www.acme.com/db1.nsf/page*?Open*
Note: If you want a rule to be literal, write a regular expression.
The full log-out feature uses a custom log-out page that you create with the following parameter:
Enables the full log-out function by specifying the URI of a custom web page. This custom web page appears to users after they are successfully logged off. Configure this page so that it cannot be stored in a browser cache. Otherwise, a browser could possibly display a log-out page from its cache without logging the user off. If this situation happens, unauthorized users could possibly have an opportunity to assume control of a session.
Note: When the CookiePath parameter is set, the value of the LogOffUri parameter must point to the same cookie path. For example, if the value of your CookiePath parameter is set to example.com, then your LogOffUri must point to example.com/logoff.html
Default: (all agents except the CA SiteMinder Agent for SharePoint r12.0.3.0) No default
Limits: Multiple URI values permitted. Do not use a fully qualified URL.Use a relative URI.
Example:(all agents except the CA SiteMinder Agent for SharePoint r12.0.3.0) /Web pages/logoff.html
Follow these steps:
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
Important! Some web browsers do not support meta tags. Use a cache-control HTTP header instead.
The full log-out feature is configured.
Use the following guidelines when creating SiteMinder policies for the Domino server:
For $defaultNav, the Domino Agent performs an action of ?OpenDatabase. You do not need to create additional rules for these types of identifiers.
A Domino web server acts as the front end to a WebSphere Application Server by providing a filter plug-in that intercepts requests before forwarding them to the WebSphere server.
Suppose you have resources on your Domino server that you not want to protect with SiteMinder. You can still protect those resources with your Domino server instead. To protect these resources, set the following parameter:
Specifies if the Domino server authenticates requests with a Domino user for resources that only the Domino server (not SiteMinder) protects.
If the value of this parameter is yes, the agent passes the Domino user to the Domino server. The Domino server authenticates the user. If the value of this parameter is no (or the parameter is disabled), the agent does not pass the Domino user to the Domino server. The Domino server does not authenticate the user.
Default: Disabled
Follow these steps:
To use an anonymous SiteMinder authentication scheme with a Domino agent, set the following parameter:
Specifies a value for anonymous users. This value is sent to the Domino server when users access Domino resources that are protected with an anonymous SiteMinder authentication scheme.
Default: No (anonymous authentication scheme not used)
Example: Anonymous (use with anonymous authentication schemes)
The previous parameter applies only when using an anonymous SiteMinder authentication scheme with Domino. Do not change its value for other authentication schemes or server types.
|
Copyright © 2012 CA.
All rights reserved.
|
|