TV Tamlinux PDF

Installing Tivoli Access Manager on Linux
Getting started
Skill Level: Introductory Olivier Antibi (oantibi@fr.ibm.com) E-business Architect IBM Jean-Paul Chobert (chobert@fr.ibm.com) E-business Architect IBM James Webster (websteja@us.ibm.com) Technical Consultant IBM
08 Aug 2003 Linux is quickly becoming a dominant platform for e-business and enterprise applications. The recent release of IBM Tivoli Access Manager 4.1 Fixpack 2 recognized this fact by adding support for Linux on the Intel platform. In this tutorial, you'll learn how to install and configure IBM Tivoli Access Manager 4.1 on Linux. You'll also walk through some simple steps that will test your installation, including the creation of a WebSEAL junction.
Section 1. Before you start

About this tutorial
With the release of IBM Tivoli Access Manager (TAM) Fixpack 2 in May 2003, enterprise security has become possible using TAM for e-business on the Linux platform running on Intel-compatible hardware. This tutorial will help security
Installing Tivoli Access Manager on Linux Copyright IBM Corporation 2003. All rights reserved. Trademarks Page 1 of 30
developerWorks
ibm.com/developerWorks
integrators and developers quickly get started using IBM Tivoli Access Manager on Linux. This tutorial provides tips for the installation process in a standard scenario. Also included are some verification tests that will help you ensure that the installation is running fine. This tutorial assumes that you are familiar with Tivoli Access Manager for e-business. You should also have a basic familiarity with the Linux platform. Refer to Resources for related material.
Software and hardware requirements

The following table illustrates the availability of various Tivoli Access Manager components for different distributions of Linux. Yes indicates support that existed prior to the release of Fixpack 2 (FP2), while New indicates support that is new with Fixpack 2.
Component Supported on Red Hat Supported on SuSE Linux 7.x Intel? Linux Enterprise Server 8 Intel? Yes New No New New New No New No No No No Supported on SuSE Linux Enterprise Server 7 and 8 zSeries? Yes Yes No Yes No Yes (IBM HTTP 1.3.19) No No
Base client (PDRTE, PDJrte, PDAuthADK) Base Server (PDMgrd, PDAcld) Web Portal Manager WebSEAL
Plug-in for Edge Server Yes (7.1 and later) Plug-in for Web Server AM for WAS AM for WLS No Yes (7.2 and later) Yes (7.2 and later)
TAM version 4.1 FP2 delivers major support for Red Hat and SuSE Linux on Intel hardware, allowing you to run the policy server and WebSEAL with the required runtime. That support is demonstrated in this tutorial. The sample platform is a 1.4 GHz Pentium 4 system with 512 MB of RAM running Red Hat Linux 7.3. This represents a sufficient developer workstation. For the recommended hardware, check the Tivoli Access Manager 4.1 Base Installation Guide.
Tivoli Access Manager and WebSEAL

developerWorks
Single sign-on (SSO) functionality is a key base requirement for e-business implementations. IBM Tivoli Access Manager offers robust and flexible SSO support and secure customer session management. By providing highly available and centralized authorization services, Tivoli Access Manager for e-business enables you to better manage and secure your business-critical distributed information, while ensuring that you can meet the time-to-market, flexibility, and scalability requirements that today's on-demand world requires. The IBM Tivoli Access Manager for e-business reverse proxy WebSEAL server is placed between Internet users and your intranet. It enables secure, policy-based, and highly available transactions. The Tivoli WebSEAL server typically resides between two firewalls, creating a semi-protected network commonly referred to as a demilitarized zone, or DMZ. All other servers can then be placed behind the inner firewall inside the more secure corporate network. This configuration prohibits unauthorized users from directly connecting to servers within the corporate network, as the figure below illustrates.
Let's take a closer look at some of the components illustrated here:
Installing Tivoli Access Manager on Linux Copyright IBM Corporation 2003. All rights reserved.
Trademarks Page 3 of 30
developerWorks
Policy server: Manages the object space database. WebSEAL: Runs the reverse proxy server and policy enforcer. User registry: An LDAP server; stores users, groups, and metadata. Web portal manager: Provides Web user administration. Junction: An HTTP or HTTPS connection between a front-end WebSEAL server and a back-end Web application server. Junctions logically combine the Web space of the back-end server with the Web space of the WebSEAL server, resulting in a unified view of the entire Web object space. Information about junctions is provided in Creating and testing a junction . Note that Web server plug-ins offer an alternative to the reverse proxy server. Additional components are available to meet specific requirements: Authorization server: Manages an object space database replica in synchronization with the policy server for remote mode enforcers. Authorization Development Kit: Helps developers build authorization into an application using C (aznAPI) or Java (JAAS and the PdPermission class) APIs. WebSEAL Development Kit: Helps developers build custom authorization methods (CDAS) to complement those available out of the box. Plug-in for IBM Edge Server's caching proxy Plug-in for IBM HTTP Server Plug-in for MS IIS Web server
Section 2. Installing TAM

Before you install
There are a few things you'll need to check before you begin the TAM installation: The Korn shell must be ready. If you haven't done so already, install it
developerWorks
from Red Hat CD number 3. Uninstall any existing LDAP server. Netscape LDAP's server may already be running. If it is, remove the nss-ldap package. In this tutorial, it's assumed that you are working from a clean installation of Linux, and that no other software is installed or running.
TAM release for Linux

The TAM software comes on two CDs or two tar files. These packages are available from the IBM Software Access Catalog (formerly the IBM Software Mall (see Resources). The following table outlines all the components that make up the software, and indicates the Red Hat Package Manager (RPM) files that correspond to each.
Component IBM Java JRE 1.3.1-20 GSKIT 5.0.46 IBM Directory V4.1.1 LDAP client AM Run Time AM Java Run Time Policy Server Authorization Server Authorization Development Kit WebSEAL WebSEAL Development Kit Plug-in Edge Server AM for WAS AM for WebLogic RPMs IBMJava2-JRE-1.3.1-2.0.i386.rpm gsk5bas-5.0-5.46.i386.rpm ldap-clientd-4.1-1.i386.rpm, ldap-dmtjavad-4.1-1.i386.rpm PDRTE-PD-4.1.0-2.i386.rpm PDJrte-PD-4.1.0-2.i386.rpm PDMgr-PD-4.1.0-2.i386.rpm PDAcld-PD-4.1.0-2.i386.rpm PDAuthADK-PD-4.1.0-2.i386.rpm PDWeb-PD-4.1.0-2.i386.rpm PDWebADK-PD-4.1.0-2.i386.rpm PDPlgES-PD-4.1.0-0.i386.rpm PDWAS-PD-4.1.0-2.i386.rpm PDWLS-PD-4.1.0-0.i386.rpm
In this tutorial, IBM Directory Server V4.1.1 is part of the installation. It can be downloaded from the IBM Web site (see Resources).
Component IBM Directory V4.1.1 LDAP server RPMs Ldap-serverd-4.1-1.i386.rpm, Ldap-html_en_US-4.1-1.i386.rpm, Ldap-msg_en_US-4.1-1.i386.rpm
developerWorks
In the following sections, the installation of each of these components is described. This scenario uses a single system installation; however, hints on how to set up a multiple-system configuration are provided.
Installing the Java runtime

In this tutorial, the Java JRE shipped with TAM is used. You can also use the JRE that comes with the equivalent version of WebSphere Application Server. To install the Java JRE: 1. Install the TAM Java JRE RPM. For this and all other RPM packages in this tutorial, you can do this quite easily with the file manager Konqueror by clicking the RPM file. Then, you can check the list of files installed. Update the path in the .bashrc file with the newly installed JRE, as follows:
2.
export PATH=/opt/IBMJava2-131/jre/bin:$PATH
3.
Execute the file to activate the new JRE.
Installing GSKIT
Install the GSKIT RPM now. If you don't, each subsequent software package will attempt to install its own version of the toolkit.
Installing the LDAP client

Install the IBM IDS 4.1.1 LDAP client and Directory Management Tool RPMs.
Installing IBM DB2 7.2.7

DB2 is not part of the TAM CDs, but it comes with IBM Directory Server (IDS). If you intend to run an enterprise application that makes use of entity bean EJBs in WebSphere Application Server version 4 or 5, you may later select the DB2 edition that meets your needs. IDS comes with DB2 Professional Edition, but you'll need Enterprise Edition for EJB container persistence. As you'll see, DB2 UDB Enterprise V7.2 Fixpack 7, which came from WebSphere
developerWorks
Application Server 5 is used. To download trial versions of the latest versions of DB2 UDB or WebSphere Application Server, see Resources. To begin the installation: 1. 2. 3. 4. Run db2setup from a shell. Select your preferred edition of DB2 UDB. Do not select DB2 Administration Server, unless you'll need it later. Do not select Data Warehouse Services.
The db2setup program is illustrated in the figure below.
Installing and configuring the LDAP server

1. 2. Install the IBM IDS LDAP server RPM. Update the .bashrc file with new LDAP environment variables, as follows:
export DB2INSTANCE=ldapdb2 export LD_LIBRARY_PATH=/usr/IBMdb2/V7.1/lib:/usr/ldap/lib:$LD_LIBRARY_PATH
developerWorks
export LD_PRELOAD=/usr/lib/libstdc++-libc6.1-2.so.3
3.
Configure LDAP to create the DB2 instance and the root user with the following command:
ldapxcfg
4.
In the next screen select both options, as illustrated in the figure below.
5.
Create a default database and choose the non UTF-8 character set:
6.
Enter the administrator username and password:
developerWorks
7.
When the progress bar finishes, a message indicating successful completion should appear:
Installing the TAM package

Install the following packages in the order specified here so as to match the dependency chain. 1. 2. 3. 4. 5. PDRTE-PD-4.1.0-2.i386.rpm PDJrte-PD-4.1.0-2.i386.rpm PDMgr-PD-4.1.0-2.i386.rpm PDAcld-PD-4.1.0-2.i386.rpm PDWeb-PD-4.1.0-2.i386.rpm
Installing optional packages

There are a few optional packages that you can install at this point, though they will not be used in this tutorial. Access Manager for WebSphere Application Server (AMWAS) allows enterprise applications running in WebSphere Application Server to have J2EE security authorization delegated to TAM. Authorization and authentication development kits can be setup on Linux as well. However, the PDWPM (Policy Director Web Portal Manager) Web administration interface is not yet supported on Linux.
developerWorks
Section 3. Configuring TAM

Configuring the LDAP server for TAM
You'll need to create two LDAP suffixes. The first is used to store the organization's users and groups. In this example, the following is used:
o=ibm,c=us
You can alter this to match your environment. The second suffix is used by TAM to store metainformation for its own use. For this suffix, you must use the following:
secAuthority=Default
To create these suffixes: 1. 2. Open the file /usr/ldap/etc/slapd32.conf in a text editor. After the line ibm-slapdSuffix: cn=localhost, enter the two new suffixes, but comment the second with a #. The figure below shows the slapd32.conf file.
3.
After restarting LDAP, apply the TAM schema. Run the following command on one line, replacing passw0rd with your own password.
/usr/ldap/bin/ldapmodify -r -c -D cn=root -w passw0rd -f /opt/PolicyDirector/etc/secschema.def
developerWorks
Numerous messages reading modifying entry c=schema will appear. 4. Stop the LDAP server: 1. Get the LDAP process ID with the following command:
cat /etc/slapd.pid
2.
kill -9 xxxx
Kill the process with this command:
where xxxx is the process ID. 5.

slapd
Restart the LDAP server:
You'll know LDAP server has been started when the following two messages are displayed:
Non SSL port initialized to 389. Local UNIX socket name initialized to /tmp/s.slapd
6.
Open the file /usr/ldap/etc/slapd32.conf in a text editor again and uncomment the secAuthority=Default suffix. Remember that the server must be restarted again for the suffix to be picked up by LDAP.
Configuring TAM
Launch the TAM configuration GUI from /opt/PolicyDirector/bin/pdconfig. This will bring up the following screen:
developerWorks
Configure these components in the following order: 1. 2. Enter option 1 for AM Runtime and answer the questions about your host name and port. Configure the policy server. Provide LDAP information as needed. Keep the default value of the policy server port. Make note of the root CA certificate location and name; if you've installed other TAM components on separate machines, you'll need to copy this information to those machines. Configure the authorization server and WebSEAL. At this point, you will be asked if you'd like to add more WebSEAL instances. Only one is used in this tutorial, but keep in mind that this configuration tool can be used to create more instances if needed. When you're done, the main menu display status will show you that all configuration has been successfully completed. Enable the LDAP access control: 1. 2. 3. 4. Open the Directory Management Tool (DMT) in a shell by entering dmt. This launches the DMT GUI. Click Rebind and enter the root user cn=root and its password. Now click on Browse Tree. Select the suffix o=ibm,c=us. Click ACL. A window appears. Fill in all the data.
3.
4.
developerWorks
5.
Click the Owners tab. For Type, select group. In the Distinguished Name field, enter cn=SecurityGroup,secAuthority=Default (see the illustration below):
6.
Click Add, then click OK to exit the DMT.
developerWorks
Section 4. Checking and starting TAM components

Introduction
The remainder of this tutorial verifies that the installation is working properly. In this section, you'll verify and start the installed components. The next section describes an example of a junction on a Web server with an Access Control policy attached (ACL).
Checking installed components

Launch the command pdconfig in the TAM directory. You should see a screen that looks like this:
Ensure that all the components are installed and configured.
Starting the components

You can automate this process so that your chosen configuration is launched when you start up the system on which TAM is installed. However, here we'll launch the components manually in order to better illustrate the process.
developerWorks
Database As your root user may not have the database environment, $DB2INSTANCE, and $PATH set properly in the .bashrc file, you will need to log on as the ldapdb2 user to start the database, as illustrated below.
[root@tam4linux root]# su - ldapdb2 [ldapdb2@tam4linux ldapdb2]$ db2start SQL1063N DB2START processing was successful. [ldapdb2@tam4linux ldapdb2]$ exit
LDAP server Once the database is started, you can start the LDAP server:
[root@tam4linux root]# slapd Cannot open message catalog file slapd.cat. Plugin of type EXTENDEDOP is successfully loaded from libevent.so. Plugin of type EXTENDEDOP is successfully loaded from libtranext.so. Plugin of type PREOPERATION is successfully loaded from libDSP.so. Plugin of type EXTENDEDOP is successfully loaded from libevent.so. Plugin of type EXTENDEDOP is successfully loaded from libtranext.so. Plugin of type AUDIT is successfully loaded from /lib/libldapaudit.so. Plugin of type EXTENDEDOP is successfully loaded from libevent.so. Plugin of type EXTENDEDOP is successfully loaded from libtranext.so. Plugin of type DATABASE is successfully loaded from /lib/libback-rdbm.so. Non-SSL port initialized to 389. Local UNIX socket name initialized to /tmp/s.slapd. [root@tam4linux root]#
Note that the LDAP server checks at startup to see if the database is running; if it is not, it will start it automatically, generating some warning messages in the process. Tivoli Access Manager components Start the Tivoli components with the autostart script, as follows:
[root@tam4linux root]# cd /opt/PolicyDirector/bin [root@tam4linux bin]# pd_start start Starting the: Access Manager Policy Server Starting the: Access Manager Authorization Server Starting the: Access Manager WebSEAL Server [root@tam4linux bin]#
Testing TAM
Now we'll execute some simple tests to check how things are going so far. 1. Start the administrative console pdadmin and list the servers, as follows:
developerWorks
[root@tam4linux root]# pdadmin pdadmin> login Enter User ID: sec_master Enter Password: pdadmin> server list ivacld-tam4linux.ibm.com webseald-tam4linux.ibm.com pdadmin>
As shown, you should see both the authorization server, ivacld-tam4linux.ibm.com, and the WebSEAL reverse proxy, webseald-tam4linux.ibm.com. 2. Create a user called ibmuser1 as follows:
[root@tam4linux root]# pdadmin pdadmin> login Enter User ID: sec_master Enter Password: pdadmin> user create ibmuser1 cn=ibmuser1,o=ibm,c=us ibmuser1 ibmuser1 passw0rd pdadmin> user modify ibmuser1 account-valid yes
3.
To show information about the user you've created:
pdadmin> user show ibmuser1 Login ID: ibmuser1 LDAP DN: cn=ibmuser1,o=ibm,c=us LDAP CN: ibmuser1 LDAP SN: ibmuser1 Description: Is SecUser: yes Is GSO user: no Account valid: yes Password valid: yes Authorization mechanism: Default:LDAP pdadmin>
If these tests work, it's safe to assume that you've correctly installed and configured Tivoli Access Manager (TAM) and IBM Directory Server 4.1.
Configuring WebSEAL
In order to observe the behavior of WebSEAL, use a login form that displays an HTML login page instead of the basic authentication popup window. To do that, you'll need to configure WebSEAL for both HTTP and HTTPS. Note that you should be cautious when doing this as allowing HTTP authentication makes it easy for someone to snoop and alter http header information.
developerWorks
1.
Find webselad.conf in the pdweb directory. Open it and add the following modifications:
# Enable authentication using the Basic Authentication mechanism # One of <http, https, both, none> ba-auth = none # Enable authentication using forms # One of <http, https, both, none> forms-auth = both
2.
Stop and restart WebSEAL:
[root@tam4linux root]# cd /opt/pdweb/ [root@tam4linux pdweb]# cd bin [root@tam4linux bin]# pdweb_start usage: pdweb [start | restart | stop | status] or : pdweb [start | restart | stop ] webseald or instance [root@tam4linux bin]# pdweb_start restart Stopping the: Access Manager WebSEAL Server Starting the: Access Manager WebSEAL Server [root@tam4linux bin]#
Testing WebSEAL
After making the changes, test the new WebSEAL configuration. Access the WebSEAL host on port 80. If you made the changes to webseald.conf outlined on the previous section, you should get this forms-based login window:
developerWorks
Enter the user ID/password combination of the ibmuser1 user created previously. Once you've been authenticated, you will see the WebSEAL banner screen:
developerWorks
Section 5. Creating and testing a junction

Introduction
Now that all of the TAM components are configured and started, you can create a junction to a Web server. With this junction, access to the homepage of the IBM HTTP Server is given to anybody, but access to its documentation is restricted to registered users only. First, you'll read about the installation and configuration process of the new components involved. Then, you'll learn how to create a junction and Access Control Lists (ACL), and how to attach them to existing directories.
Installation and configuration

Installing and configuring the IBM HTTP Server
developerWorks
1.
Open the configuration file http.conf using a text editor:
[root@tam4linux root]# cd /opt/IBMHttpServer/conf/ [root@tam4linux conf]# vi httpd.conf [root@tam4linux conf]#
2.
Find the document root and make note of it -- you'll be needing it later (see Configuring query_contents).
# # DocumentRoot: The directory out of which you will serve your # documents. By default, all requests are taken from this directory, but # symbolic links and aliases may be used to point to other locations. # DocumentRoot "/opt/IBMHttpServer/htdocs/en_US"
3.
Because the WebSEAL default configuration uses port 80, you have to change the port number for the HTTP server:
# Port: The port to which the standalone server listens. For # ports < 1023, you will need httpd to be run as root initially. # Port 81
4.
Start the server:
[root@tam4linux IBMHttpServer]# cd bin [root@tam4linux bin]# pwd /opt/IBMHttpServer/bin [root@tam4linux bin]# apachectl start ./apachectl start: httpd started [root@tam4linux bin]#
Current architecture To browse the current architecture, use a recursive call to object list in the pdadmin console. You'll obtain the full name of the objects that will be used in the ACL attach process.
[root@tam4linux root]# pdadmin pdadmin> login Enter User ID: sec_master Enter Password: pdadmin> object list /Management /WebSEAL pdadmin> object list /WebSEAL /WebSEAL/tam4linux.ibm.com pdadmin> object list /WebSEAL/tam4linux.ibm.com
developerWorks
/WebSEAL/tam4linux.ibm.com/cgi-bin /WebSEAL/tam4linux.ibm.com/icons /WebSEAL/tam4linux.ibm.com/pics /WebSEAL/tam4linux.ibm.com/index.html pdadmin> object list /WebSEAL/tam4linux.ibm.com /WebSEAL/tam4linux.ibm.com/cgi-bin /WebSEAL/tam4linux.ibm.com/icons /WebSEAL/tam4linux.ibm.com/pics /WebSEAL/tam4linux.ibm.com/index.html pdadmin>
Notice the sample host name, tam4linux.ibm.com. Throughout the remainder of this tutorial, substitute this with your own host name.
Creating a Junction
To create a junction, enter the following command on one line:
pdadmin> server task webseald-tam4linux.ibm.com create -t tcp -h tam4linux -p 81 /ibmhttp
Let's look more closely at the components of this command: -t tcp: Defines a TCP/IP junction type -h tam4linux: Defines the host name -p 81: Defines the port number /ibmhttp: Defines the mount point
Configuring query_contents
To browse the junction with the pdadmin tool, use a CGI script, query_contents, to explore the document root. To configure query_contents: 1. Copy the script from the pdweb directory and make it executable by all users:
[root@tam4linux query_contents]# pwd /opt/pdweb/www/lib/query_contents [root@tam4linux query_contents]# ls C query_contents.c query_contents.cfg query_contents.exe query_contents.sh [root@tam4linux query_contents]# cp query_contents.sh /opt/IBMHttpServer/cgi-bin/query_contents [root@tam4linux query_contents]# cd /opt/IBMHttpServer/cgi-bin/ [root@tam4linux cgi-bin]# ls query_contents [root@tam4linux cgi-bin]# chmod 555 query_contents
developerWorks
2.
Edit the CGI file and modify the document root to fit the one you have in your Web server.
# # NOTE: change this panel so that the document root is set correctly # for your installation. # ADD_TO_ROOT= case "$SERVER_SOFTWARE" in WebSEAL*|WAND*) DOCROOTDIR=`pwd` ;; # Apache*) changed to match our server_software *Apache*) # DOCROOTDIR=`pwd`/../htdocs changed to match our document root DOCROOTDIR=`pwd`/../htdocs/en_US
ADD_TO_ROOT="cgi-bin//" ;; CERN*) DOCROOTDIR=/home/www/Web ADD_TO_ROOT="cgi-bin//" ;; *) DOCROOTDIR=/usr/local/html esac
Here's a hint for a quick debug of this script. Add the following line:
echo SERVER_SOFTWARE : $SERVER_SOFTWARE
Then point your browser to the following URL (substitute tam4linux.ibm.com with your host name):
http://tam4linux.ibm.com/cgi-bin/query_contents
This should return HTTP_SERVER/1.3.26 Apache/1.3.26 (Unix). By default, the configuration fails and the document root directory is not well set. To keep the original configuration script, you need to modify the regular expression Apache*, which matches anything beginning with Apache, with *Apache*, which matches anything containing Apache, including IBM_HTTP_SERVER/1.3.26 Apache/1.3.26 (Unix). This change is reflected in the listing above. 3. Check the configuration. Point your browser to the following URL:
http://tam4linux.ibm.com/cgi-bin/query_contents?dirlist=/
developerWorks
Again, substitute tam4linux.ibm.com with your own host name. You should be see a list of the files of the document root directory. If you see a return value other than 100, check out the WebSEAL Admin guide for assistance. Your browser window should look like this:
4. 5.
Don't forget to remove any debug instructions. Finally, compare the list presented in the browser by the CGI script against the list available through the pdadmin console:
pdadmin> object list /WebSEAL/tam4linux.ibm.com/ibmhttp /WebSEAL/tam4linux.ibm.com/ibmhttp/HP-UX.gif /WebSEAL/tam4linux.ibm.com/ibmhttp/HTTP_top_a.gif /WebSEAL/tam4linux.ibm.com/ibmhttp/HTTP_top_b.gif /WebSEAL/tam4linux.ibm.com/ibmhttp/IBMlogosmall.gif /WebSEAL/tam4linux.ibm.com/ibmhttp/OS2.gif /WebSEAL/tam4linux.ibm.com/ibmhttp/Powered_by_a.gif /WebSEAL/tam4linux.ibm.com/ibmhttp/SystemAdmin.gif /WebSEAL/tam4linux.ibm.com/ibmhttp/aixlogo.gif /WebSEAL/tam4linux.ibm.com/ibmhttp/apadminred.html .... ....
As you can see, pdadmin is able to browse the junction.

developerWorks
Creating the access control list

Use the following commands to create the public ACL that gives free access to all the files of the junction.
pdadmin> acl create Public pdadmin> acl modify Public set any-other Trx pdadmin> acl modify Public set unauthenticated Trx pdadmin> acl attach /WebSEAL/tam4linux.ibm.com/ibmhttp Public pdadmin> acl show Public ACL Name: Public Description: Entries: User sec_master TcmdbsvaBl Unauthenticated Trx Any-other Trx
Notice that you are giving unauthenticated people and any others the right to T(raverse), r(ead), and e(xecute) on any objects. Next, use the following commands to create the restricted ACL to restricts the access to the files below the manual directory to only authenticated users.
pdadmin> acl create Restricted pdadmin> acl modify Restricted set any-other Trx pdadmin> acl modify Restricted set unauthenticated T pdadmin> acl attach /WebSEAL/tam4linux.ibm.com/ibmhttp/manual Restricted pdadmin> acl show Restricted ACL Name: Restricted Description: Entries: User sec_master TcmdbsvaBl Any-other Trx Unauthenticated T
Notice that you are allowing the unauthenticated to only traverse this directory (to reach another allowed area, for example), but not to read or execute any objects. Note: A WebSEAL ACL should ALWAYS contain the core entries for groups iv-admin and webseal-servers, and user sec_master. While what we have will work for demo purposes, in a real world environment attaching WebSEAL ACLS's without the core entries can be a mess. The core entries should always be present in a WebSEAL ACL. To synchronize the policy server and WebSEAL:
pdadmin> server replicate pdadmin>
developerWorks
A simple test
To verify the good behavior of the junction with the ACL policy, let's first access the junction. As usual, you'll need to change tam4linux.ibm.com in the URL on this panel with your own host name. Note that no authentication is required to access the junction.
Click View Documentation to access the manuals. When you do, you'll get a popup login window, as illustrated below. The login panel appears because basic authentication has been selected in the WebSEAL configuration file. (Cf. configuring webSEAL).
developerWorks
Clicking the documentation link will access http://tam4linux.ibm.com/ibmhttp/manual/ibm/manual.html. Since we attached our ACL to the URL ../ibmhttp/manual, WebSEAL intercepts it as needing authentication. After you've connected and authenticated, until a new session is initiated you can access the manual and use the single sign-on functionality to browse the entire site without authenticating again.
developerWorks
Section 6. Summary
Linux is becoming a dominant platform for e-business and enterprise applications. Tivoli Access Manager solutions for Linux (zSeries and Intel architectures) provide the following benefits: An integrated security management platform that delivers a single security model across the e-business infrastructure: Web servers, Java 2 Platform, Enterprise Edition (J2EE) Application Servers, CRM, ERP, and SCM with RACF integration. A highly secure Linux kernel module provided by Access Manager for Operating Systems (AMOS) that secures the underlying Linux platform with a complete role-based access control and Web-based Linux administration across the Linux enterprise. Web single sign-on across the e-business infrastructure. A single security model across multiple Web application servers.
developerWorks
We hope this tutorial has been helpful for systems integrators looking to get a jump start on this newly supported platform.
developerWorks
Resources
Learn Check out the IBM Red Paper IBM Tivoli Access Manager for e-Business . Read the IBM developer domain tutorial, Secure your Web resources integrating WebSphere and Tivoli Access Manager . Learn more about Tivoli Access Manager from the Tivoli product page. Read the IBM Redbook, Enterprise Security Architecture using IBM Tivoli Security Solutions Stay current with developerWorks technical events and Webcasts. Get products and technologies Download the IBM Directory Server. Download a trial version of IBM WebSphere Application Server. Download a trial version of IBM DB2 Universal Database. Build your next development project with IBM trial software, available for download directly from developerWorks. Discuss Participate in the discussion forum for this content. Exchange knowledge with others in the Tivoli forums.
About the authors

Olivier Antibi Olivier Antibi was an honors graduate from ENSEEIHT in France before joining the e-business architect team. He began his career as a developer and later as an analyst. Presently focused on IBM Tivoli products, he provides enablement education and consulting to IBM Business Partners. You can reach Olivier at oantibi@fr.ibm.com.
Jean-Paul Chobert Jean-Paul Chobert is an e-business architect with IBM Developer Relations. He has 21 years of software development experience.
developerWorks
Jean-Paul previously worked for Thomson CSF and Alcatel. He works in IBM for the strategic alliance partner program, doing consulting, mentoring, coding, and teaching. He is IBM IT Specialist certified and product certified in IBM Tivoli Access Manager, WebSphere MQ, WebSphere Application Server, WebSphere Commerce, WebSphere Studio, and e-Business Designer. He graduated from Ecole Nationale Superieure des Telecommunications, Paris, France.
James Webster James Webster is a technical consultant for security products in the Ready for Tivoli Integration program. He is a certified Tivoli Access Manager consultant. James has a degree in computer science from Texas A&M University. Contact him at websteja@us.ibm.com.

TV Tamlinux PDF

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

TV Tamlinux PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Installing Tivoli Access Manager on Linux

Section 1. Before you start

Software and hardware requirements

Tivoli Access Manager and WebSEAL

Let's take a closer look at some of the components illustrated here:

Section 2. Installing TAM

TAM release for Linux

Installing the Java runtime

Execute the file to activate the new JRE.

Installing the LDAP client

Installing IBM DB2 7.2.7

The db2setup program is illustrated in the figure below.

Installing and configuring the LDAP server

export DB2INSTANCE=ldapdb2 export LD_LIBRARY_PATH=/usr/IBMdb2/V7.1/lib:/usr/ldap/lib:$LD_LIBRARY_PATH

Enter the administrator username and password:

Installing the TAM package

Installing optional packages

Section 3. Configuring TAM

/usr/ldap/bin/ldapmodify -r -c -D cn=root -w passw0rd -f /opt/PolicyDirector/etc/secschema.def

Kill the process with this command:

where xxxx is the process ID. 5.

Restart the LDAP server:

Click Add, then click OK to exit the DMT.

Section 4. Checking and starting TAM components

Checking installed components

Ensure that all the components are installed and configured.

Starting the components

To show information about the user you've created:

Stop and restart WebSEAL:

Section 5. Creating and testing a junction

Installation and configuration

Open the configuration file http.conf using a text editor:

[root@tam4linux root]# cd /opt/IBMHttpServer/conf/ [root@tam4linux conf]# vi httpd.conf [root@tam4linux conf]#

Start the server:

ADD_TO_ROOT="cgi-bin//" ;; CERN*) DOCROOTDIR=/home/www/Web ADD_TO_ROOT="cgi-bin//" ;; *) DOCROOTDIR=/usr/local/html esac

As you can see, pdadmin is able to browse the junction.

Creating the access control list

About the authors

S-ar putea să vă placă și

ADD_TO_ROOT="cgi-bin//" ;; CERN) DOCROOTDIR=/home/www/Web ADD_TO_ROOT="cgi-bin//" ;; ) DOCROOTDIR=/usr/local/html esac