Use TivoliAccessManager in the Lotus quickrfordomino Environment

Introduction ibmlotus quickr is a team collaboration software that helps you share content, collaborate with teams, and increase the speed of online work. Quickr Security Management Solution uses the IBMTivoliAccessManager-WebSEAL component to implement reverse proxy. Reverse Proxy acts as the contact list for the portal and other Web applications.

Introduction IBM Lotus Quickr is a team collaboration software that helps you share content, collaborate with teams, and speed up online work. Quickr Security Management Solution uses the IBM Tivoli Access Manager-WebSEAL component for reverse proxy, which acts as a joint ticket for the portal and contacts of other Web applications

Introduction

IBM Lotus Quickr is a team collaboration software that helps you share content, collaborate with teams, and increase the speed of online work.

Quickr Security Management Solution uses the IBM Tivoli Access Manager-WebSEAL component to implement reverse proxy, which acts as a single logon point for contacts of portals and other Web applications. Using the reverse proxy, because the authentication logic exists in the Tivoli Access Manager WebSEAL layer, more complex authentication mechanisms can be supported in the future.

IBM Tivoli Access Manager is a powerful and secure centralized policy management solution for e-commerce and distributed applications. IBM Tivoli Access Manager WebSEAL is a high-performance, multi-threaded Web server that applies fine-grained security policies to the protected Web object space of Tivoli Access Manager. WebSEAL can provide a single registration solution and merge backend Web Application Server resources into its security policy.

Back to Top

IBM Tivoli Access Manager and WebSEAL

IBM Tivoli Access Manager is a complete Authorization and network security policy management solution that provides powerful end-to-end protection for geographically dispersed resources on the Intranet and external networks.

At its core, Tivoli Access Manager provides:

1. Authentication Framework

   Tivoli Access Manager provides a wide range of built-in authentication programs and supports external authentication programs.

2. Authorization framework

   Use Tivoli Access Manager to authorize the API to Access the Tivoli Access Manager Authorization Service. This service allows and rejects requests for Protected Resources in the security domain.

IBM Tivoli Access Manager WebSEAL is a resource Manager responsible for managing and protecting Web-based information and resources. WebSEAL is usually used as a reverse Web proxy to receive HTTP/HTTPS requests from a Web browser and deliver content from its own Web server or from the associated back-end Web application server. The request through WebSEAL is evaluated by the Tivoli Access Manager Authorization Service to determine whether to authorize the user to Access the requested resources.

WebSEAL provides the following functions:

• Multiple authentication methods are supported.
• Accept HTTP and HTTPS requests.
• Integrates and protects backend server resources through WebSEAL connection technology.
• Manage fine-grained access control for local and back-end server Web spaces.
• Executed as a reverse Web Proxy-for clients, WebSEAL can be used as a Web server, while for backend servers that are protected by WebSEAL, WebSEAL can be used as a Web browser.
• Provides a single registration function.

Figure 1. Use WebSEAL to protect Web space

Back to Top

Use WebSEAL to protect Quickr Space

When WebSEAL implements Security in the security domain, each Quickr client must provide its identification certificate. Then, the Tivoli Access Manager security policy determines whether the client is allowed to perform operations on the requested resource. Because the access to each Quickr resource in the security domain is controlled by WebSEAL, the authentication and authorization requirements of WebSEAL can provide comprehensive network security.

In the Tivoli Access Manager Authorization Model, authorization policies are implemented independently of the mechanism used for user authentication. Users can use public/private keys and security keys, or use custom mechanisms to authenticate their identities. Part of the authentication process involves the creation of creden。 (describing the client identity. Authorization decisions made by an Authorization Service are based on user creden.

The authorization process consists of the following basic components:

• The resource manager is responsible for the requested operations when granting permissions.
• The Authorization Service performs decision-making operations on requests.

Describes the complete authorization process:

Figure 2. Tivoli Access Manager authorization process

Authentication is a method to determine the individual process or entity attempting to log on to the security domain. When both the server and the client require authentication, this exchange process is called mutual authentication.

Figure 3 mutual authentication

Back to Top

Configure SSL in the WebSEAL Integration Environment

The WebSEAL server supports the following two SSL connections:

• HTTPS access requests from clients
• SSL connections for backend servers

As shown in:

Figure 4. SSL connection of the WebSEAL Server

In addition, Tivoli Access Manager supports SSL connections between front-end WebSEAL servers and backend WebSEAL servers.

Configure WebSEAL for HTTPS requests from clients

Client certificate authentication must occur on Secure Socket Layer (SSL) connections. Establish an SSL connection before the certificate authentication process. You can establish an SSL connection when the client attempts to access resources over HTTP. When resources do not require authentication access, the client negotiates an SSL session with the WebSEAL server. When the client and server (WebSEAL) check each other's certificates and accept the validity of the signature permission, establish an SSL session.

To establish an SSL session on a new WebSEAL server, WebSEAL includes a self-signed test server certificate. WebSEAL can provide self-signed certificates to clients. If the client accepts the certificate, an SSL session is established. This test certificate is not applicable to permanent use by WebSEAL servers. Although this test certificate allows WebSEAL to respond to SSL-enabled browser requests, it cannot be verified by the browser. This is because the browser does not contain an appropriate Root CA certificate-that is, when the browser receives any self-signed certificate, but does not have a Root CA certificate for the certificate. Because the private key of this default certificate is included in each WebSEAL distribution, this certificate cannot provide real secure communication.

To ensure secure SSL communication, the WebSEAL administrator must obtain a unique site server certificate from a trusted authentication center (CA. You can useIKeymanThe certificate requests generated by the application will be sent to the CA. You can also useIKeymanTo install and add a new site certificate.

Use the WebSEAL configuration file[Ssl]SectionWebseal-cert-keyfile-label

By setting configuration file entries, You can implement the following control:

• Enable/disable HTTPS access
• Set HTTPS Access Port
• Restrict connections from a specific SSL version
• Set communication timeout parameters for HTTP/HTTPS
• Set Certificate Revocation List (CRL)

Configure SSL connections for backend servers

The SSL connection function is completed based on the WebSEAL connection of the TCP connection. Its additional function is to encrypt the communication between all WebSEAL and the backend server. SSL connections allow secure end-to-end browser transactions to applications. SSL can be used to protect communication from the client to WebSEAL and from WebSEAL to the backend server. When using SSL connections, the backend server must enable HTTPS.

When the client requests resources on the backend server, WebSEAL, as the security server, will execute the request on behalf of the client. The SSL protocol specifies that the server must use the server certificate to provide proof of identity when making a request to the backend server. When WebSEAL receives this certificate from the backend server, it must verify the authenticity by comparing the certificate with the Root CA certificate list in the certificate database.

Tivoli Access Manager is implemented using the IBM Global Security Kit (GSKit) of SSL. It must be used.IKeymanApplication to add the root certificate of the CA. The CA signs the WebSEAL certificate key file (Pdsvr. kdb.

SSL connection example:

Server task web1-webseald-cruz create-t ssl-h sales.tivoli.com/sales

Note:-T sslThe default port 443 is specified.

SSL connections between WebSEAL and WebSEAL

Tivoli Access Manager supports SSL connections between front-end WebSEAL servers and backend WebSEAL servers. Use the create command with the-C option to connect two WebSEAL servers through SSL and provide mutual authentication. For example:

Server task web1-webseald-cruz create-t ssl-C-h serverA/jctA

Mutual authentication takes place under the following two conditions:

• The SSL protocol allows the backend WebSEAL server to pass its server certificate to the front-end WebSEAL server for authentication.
• In the Basic Authentication (BA) header,-COption allows the front-end WebSEAL server to pass its identity information to the backend WebSEAL server.

In addition,-COption can enable the single registration function provided by the-c option.-COption allows Tivoli Access Manager-specific client identity and group member information to be placed in the HTTP header of the request to the backend WebSEAL server. Header parameters include:Iv-user,Iv-groupsAndIv-creds.

WebSEAL-WebSEAL joins must be used in the following environments:

• Join-T sslOr-T sslproxyJoin type.
• The two WebSEAL servers must share the public LDAP registry. It allows the backend WebSEAL server to authenticate the identification information of the front-end WebSEAL server.
• If WebSEAL is used to connect WebSEAL to the backend application server-JConnection options (for connection cookies), the two types of connection cookies created by the two WebSEAL servers may conflict with each other. To prevent this conflict, you must configure the intermediate WebSEAL server to uniquely identify its connection cookie. Only on the intermediate WebSEAL server[Script-filtering]SectionHostname-junction-cookieSet the parameter to"Yes"(The default value is"No").

Back to Top

Integration of Lotus Quickr with Lotus Sametime and Lotus Connections in the WebSEAL Environment

In the Lotus Quickr solution, Lotus Quickr is usually part of the integration service, rather than providing services to users by a single application. At the same time, IBM Tivoli Access Manager can provide unified authentication, authorization, and single sign-on to multiple Web application servers in the background. This chapter describes the integration of WebSEAL and Web server in the typical client environment Lotus Quickr, Lotus Connections, and Lotus Sametime.

Figure 5. topology structure integrated with WebSEAL and Lotus Quickr, Lotus Sametime, and Lotus Connections

After integration, we can implement the following functions on the Lotus Quickr Server:

• The online perception, chat, and online conference functions of the Sametime server.
• The Business Card function of the Connections server.
• On the Connections server, you can place the entry attachment of activities in the location of the Quickr server.
• On the Connections server, you can create standard sites and WIKI for Quickr in Community.

Back to Top

Integration instance of WebSEAL and Lotus Quickr

1. Build a Tivoli Access Manager Server and use an LDAP Server to provide Directory services, such as connecting to the IBM Directory Server.
2. Build a Lotus Domino-based application Lotus Quickr and use the same LDAP server as the TAM server to provide directory services.
3. An LTPA key file is generated from a separate WebSphere Application Server and exported to achieve SSO between Tivoli Access Manager and domino products.
   1. Access a WebSphere Application Server in a browser and enter the Administrator and password, for example:Http://was.yourcompany.com: 9090/admin.
   2. In the left-side Navigation Pane, choose security> authentication> LTPA.
   3. In the key file name field, enter the full path of the key storage file. File write permission.
   4. Click Export key. The file is created with the LTPA key.
   5. Save this key.
4. Create a node Junction for the Lotus Quickr server on the Tivoli Access Manager server.
   1. Start the pdadmin tool on the Tivoli Access Manager server: Start> program> IBM Tivoli Access Manger> administrator command prompt line.
   2. Use the login command to log on to the server pdadmin> Login. Enter the server administrator and password to start registration.
   3. Use the LTPA key generated on the WebSphere Application Server to create a Junction for the Lotus Quickr server. Run the following command on the command line:

      pdadmin> server task default-webseald-[servername] create -t tcp     -h [Lotus Quickr hostname] -p 80 -i -j -A –F [path to LTPA key]     -Z [LTPA key password] /junction

      For example:

      pdadmin> server task default-webseald-TAM.yourcompany.com create -t tcp     -h quickr.yourcompany.com -p 80 -i -j -A -F c:\sso -Z password /quickr

   4. Import common users to the Tivoli Access Manager server. All users are from the LDAP server. Enter the following command in the command line:

      pdadmin > user import [-gsouser] 
            
            
           

      For example:

      pdadmin> user import -gsouser manager10     "cn=manager ,ou=managers,ou=users,o=qdsvt,dc=yourcompany,dc=com"

   5. Make all imported users take effect on the Tivoli Access Manager server. Enter the following command in the command line:

      pdadmin> user modify 
           
             account-valid {yes|no}
           

      For example:

      pdadmin> user modify manager account-valid yes

5. Configure the Lotus Domino application server to implement SSO between the server and the Tivoli Access Manager server.
   1. Create a Web SSO configuration document on the Lotus Domino Application Server. The Web SSO configuration document is a configuration document that is stored in the network domain within the Domino Directory. This document (which should be copied to all servers involved in a logon network domain) will encrypt the participating servers and administrators and contain a shared key for the server to verify the user certificate.
   2. Complete the remaining part of the document as follows:

      Table 1. Web SSO configuration document

      Domain	Operation
      Configuration name	Keep default name LtpaToken
      Organization	Do not enter
      DNSNetwork domain	(Required) enter the DNS domain (for example, yourcompany.com) to which the generated token belongs ). All servers that enable one login must belong to the same DNS network domain.
      DominoServer Name	Enter the name of the server that will participate in one login (for example, quickr/ibm, sametime/ibm ). This document encrypts the members of the document creator, owner and administrator domains, and the servers specified in the Domino server name domain. Groups, wildcards, and WebSphere server names are not allowed in this domain. Only Domino servers can be listed as participating servers in the "server name" field. Note that the domain size should not exceed 64 KB. When this limit is reached (for example, when hundreds of servers are entered), an error message is displayed. If this limit is reached, we recommend that you create multiple Web SSO documents.
      Expiration time (min)	Specifies the time period (in minutes) for which the token is valid ). This time period starts from the time when the token is published. The token is valid only within the specified minute, that is, its expiration time is not based on the idle time. The default value is 30 minutes.

   3. In the "Web SSO configuration" document, click "key ". Select "introduce WebSphere LTPA key ". Browse and select the WebSphere LTPA file and enter the password (specified when the key is generated in WebSphere ).
   4. Use the Domino Administrator, select "application"> "new" from the "file" menu, and select the name of the Quickr server and the name of the new database domcfg. nsf, then select Quickr Server as the template Server for the database, select "show advanced template", select the template "Domino Web Server Configuration", and click confirm to create domcfg. nsf database. After the database is created, open the database, click "add ing", and enter "LotusQuickr/resources" in the name field of the target database. nsf, enter "QuickPlaceLoginForm" in the target form field, save this document, and close domcfg. nsf database.
   5. Restart the Quickr server.
6. Confirm configuration results: Access the Lotus Quickr server through the Tivoli Access Manager server:Https://TAM.yourcompany.com/quickr/lotusquickr, Use the user and password imported by the Tivoli Access Manager server, and authorize the Tivoli Access Manager server to implement SSO with the Lotus Quickr server.