Tivoli Security Products A Guide to Tivoli Security Components

Transcription

1 Tivoli Security Products A Guide to July 24, 2002 Acumen Advanced Technologies Inc.

2 Important Note to Users While every effort has been made to ensure the accuracy of all information in this document, Acumen Advanced Technologies Inc. (ACUMEN) assumes no liability to any party for any loss or damage caused by errors or omissions or by statements of any kind in this document, its updates, supplements, or special editions, whether such errors are omissions or statements resulting from negligence, accident, or any other cause. ACUMEN further assumes no liability arising out of the application or use of any product or system described herein; or any liability for incidental or consequential damages arising from the use of this document. ACUMEN disclaims all warranties regarding the information contained herein, whether expressed, implied or statutory, including, but not limited to, implied warranties of merchantability or fitness for a particular purpose. ACUMEN makes no representation that the interconnection of products in the manner described herein will not infringe on existing or future patent rights, nor do the descriptions contained herein imply the granting or license to make, use or sell equipment constructed in accordance with this description. ACUMEN reserves the right to make changes without further notice to any products herein to improve reliability, function, or design. Copyright 2002 Acumen Advanced Technologies Inc. (ACUMEN). No part of this publication may be reproduced or transmitted in any form or by any means (graphic, electronic, electrical, mechanical, or chemical, including photocopying, recording in any medium, taping, by any computer or information storage and retrieval systems, etc.) without prior permission in writing from ACUMEN. 11/26/2002 Copyright Acumen Advanced Technologies Inc. 2

3 TABLE OF CONTENTS 1 OVERVIEW OF SECURITY INFRASTRUCTURE IBM TIVOLI IDENTITY DIRECTOR IDENTITY MANAGEMENT SERVICE Workflow TID Web Application PROVISIONING SERVICE Tivoli User Administration Resource Service Tivoli User Administration Tivoli Security Manager Endpoints INFORMATION SERVICES IBM TIVOLI ACCESS MANAGER CONFIGURATION Configuration Utilities Configuration Files pd.conf ldap.conf ivmgrd.conf ivacld.conf webseald.conf MANAGEMENT PD Admin User/Group Management Junction Management Object Management ACL Management Global Sign-On Management Web Portal Manager WEBSEAL FIGURE 3 WEBSEAL REVERSE PROXY Junctions FIGURE 4 - ACCESS CONTROL LIST EXAMPLE Access Control Access Control Lists(ACLs) Protected Object Policies(POPs) Replication POLICY SERVER Object Space Access Control Lists Protected Object Policies Management of Access Control Authorization Server ACL Management Cache Management Application Programming Interface Replication APPLICATION SERVER PLUG-IN /26/2002 Copyright Acumen Advanced Technologies Inc. 3

4 3.5.1 WebSphere Plug-in Weblogic Plug-in TABLE OF FIGURES FIGURE 1: TIVOLI IDENTITY DIRECTOR COMPONENTS... 8 FIGURE 2 ACCESS MANAGER ADMINISTRATION UTILITIES FIGURE 3 WEBSEAL REVERSE PROXY FIGURE 4 - ACCESS CONTROL LIST EXAMPLE FIGURE 5 ACCESS MANAGER J2EE PLUG-IN /26/2002 Copyright Acumen Advanced Technologies Inc. 4

5 1 Overview of Security Infrastructure The modern Application Security strategy to secure open, client/server, distributed computing systems encompasses the following stages: Implement a local security infrastructure on each strategic system based on the enterprise Security Architecture while leveraging existing enterprise network, database and application security solutions. Evolve an operational level of system assurance, integrity, and trust based on the requirements of the marketplace. Architect an enterprise-wide distributed security solution based on open standards-based technology and port to all strategic systems. Based on this approach, a number of large organizations started their Enterprise Security project. The major effort that was undertaken by this project is to implement a security infrastructure based on the set of requirements developed in relation to the application development strategies. There are number of shrink-wrapped products that provide an end to end solution to business applications. In this paper we provide a brief overview of the technical implementation of IBM Tivoli security products. From a high level perspective, a security system provides the ability to define Principals and their activities. In a security system, a principal is a single identifiable and manageable system actor. Hence the first step is the ability to define Principals through unique identities. The next step for the security system is to provide the ability, automatically or otherwise, to identify the system actors trying to access computational facilities. This feature, usually referred to as Manageability, provides facilities to create, store principal identities, and later on the ability to authenticate a given user identity against the stored identities. Any system actor, such as machines, applications or users that can run a system function could potentially be a principal. In a lot of organizations only users are given the status of a principal. Hence, identification and management, and later on access control, are not extended to include applications, processes or machines. 11/26/2002 Copyright Acumen Advanced Technologies Inc. 5

6 The other major function of a security system is the ability to control principal activities by other principals. This feature, usually referred to as Access Control, provides facilities to other principals to control the activities of other principals at runtime. As the result, both subject and object of access control function must be principals. Security systems provide number of other functions. However, none of the other major functions such as privacy, integrity and non-repudiation is in the domain of requirements that this paper is addressing. Table 1 lists the components of IBM Tivoli security products that are commonly installed and configured. As shown in Table 1 above, the product components cover the two main security functional requirements, Principal Management and Principal Authentication and Authorization. IBM Tivoli Identity Director Version 1.1 is the component that handles the requirement of Principal management. IBM Tivoli Access Manager Version 3.9 is the component that handles the requirement of Principal Authentication and Authorization. The following sections provide a brief overview of the implementation of these products. 11/26/2002 Copyright Acumen Advanced Technologies Inc. 6

7 Security Function Component Function Management of Principals Identification and Control of Principal s Access Tivoli Identity Director Management Server (TIMS) Tivoli User Administration Resource Server (TUARS) Tivoli Management Region (TMR) server Tivoli Management Framework (TMF) Desktop Tivoli Security Manager Tivoli Access Manager Configuration Components Tivoli Access Manager Management Components Tivoli Access Manager WebSEAL Component Tivoli Access Manager Policy Server Component Tivoli Access Manager Authorization Server Tivoli Access Manager Application Server Plug-ins Web-based identity management solution to the Tivoli SecureWay suite of products Is a daemon process accessed by the TIMS component to setup user profiles and assign roles to them. The component that controls and coordinates the managed components within a managed region. It communicates and coordinates with endpoints the required information and updates. Tivoli framework management tool that communicates components within a managed region The main component used for establishing and managing user groups as part of TID. Set of commands and utilities that allow configuration of the Access Manager components into a secure domain. Utilities and to manage the user information, ACLs, and secure resources or objects. The reverse proxy server, which acts as a gateway for HTTP requests. The components that guarantees a consistent user/policy management method. The component in Access Manager that makes authorization decisions. Components that allow easy integration with application server platforms. Table 1: IBM Tivoli Access Manager Product Suite Common Components 11/26/2002 Copyright Acumen Advanced Technologies Inc. 7

8 2 IBM Tivoli Identity Director IBM Tivoli Identity Director (TID) is an identity management product to manage Principals. This product with its multiple components provides the following functions: Browser based UI Provisioning Service HTTP(S) Identity Management Server Work flow TID Web App XML over SSL JServer Daemon Tivoli User Admin TUARS C Daemon Tivoli Mnagement Framework Tivoli Security Mnager PeopleSoft Feed Request Database LDAP SSL(optional) User Profiles Security Profiles Access Manager Policy Server Information Server Directory Repository LDAP SSL(optional) LDAP Connection Conncetion Objects UNIX Endpoint NT Endpoint W2K Endpoint Figure 1: Tivoli Identity Director Components 1. A web based interface for administration of users 2. Ability to delegate user data management among intermediary administrators and users to manage their own data 3. Ability to incorporate business processes (such as an approval chain) 4. An LDAP based directory server for authentication and role authorization 11/26/2002 Copyright Acumen Advanced Technologies Inc. 8

9 5. Ability to create and manage user profiles 6. Ability to create and manage security profiles 7. Ability to synchronize the user and security profiles to manageable endpoints These capabilities are provided through collaboration of number of other Tivoli Products: 1. Tivoli Management Framework (TMF) 2. Tivoli Managed Region server (TMR) 3. Tivoli User Administration Request Server (TUARS) 4. Tivoli User Administration (TUA) 5. Tivoli Security Management (TSM) The collection of the above services is referred to as Tivoli Provisioning Service. As the result, the Tivoli Identity Director product is comprised of three classes of services: 1. Tivoli Identity Management Service, which contains the Web interface to manage to perform administrative functions on users, and a workflow engine that executes business specific processes applicable on the certain administrative functions. 2. Tivoli Provisioning Services, which includes 5 servers and services listed above. 3. An LDAP directory server, which acts as a repository for the user data Figure 1 illustrates the components in a TID installation. This section provides a brief overview of these components. 2.1 Identity Management Service The Identity Management (TIM) service is referred to that component of TID that contains a Web user interface for administration of identities as well as a workflow engine to execute business rules attached to certain administration functions. The following sections provide a brief overview of these features Workflow This feature allows the flexibility to incorporate business specific rules with TID functions, enabling TID to perform its functions based on a set of business specific rules. The TID functions that could be tailored by this feature are: User Registration It enables administrators to configure a set of approvers that are notified in a specified order to approve or reject a pending registration. 11/26/2002 Copyright Acumen Advanced Technologies Inc. 9

10 Approval Administrators approve or reject pending user requests in a set order. Workflow enables administrators to route user requests to the proper approvers. Self-Care This feature enables users to manage their own user data. Workflow routes Self-Care requests to the proper administrators for approval. Workflow provides these flexibilities through facilities called Business Processes (BP) and Business Process Objects (BPO). A BP is a logical grouping of related activities. BPOs are Java classes that implement service methods, which could be simple (one class) or complex (a container of other BPOs). A BP is a collection of BPOs by one of the tasks listed above (Registration, Approval or Self-Care). The Workflow engine provides three BPs to perform these functions out of the box TID Web Application The Web allows users access administrative roles and Self-Care tasks from a standard Web browser. Tasks are the functions TID users can perform depending on their level of authority. Using this interface, users of TID can manage identity data. In managing identity data, TID distinguishes between three types of users: Security Administrators, who setup security policy Identity manager administrators, who manage user identities and their access to company resources All other employees, or users, who manage their own data The identity data can be split into two main categories: User Data and Security Data. User data is a collection of data items such as user name and group information. Security data is a collection of data items that defines user access to the secure resource in an enterprise. User data is kept within User Profile and security data is kept in Security Profile. The TIM service uses two other services TUA and TSM to create user and security profiles respectively and use these components to synchronize this information to defined endpoints, including LDAP and Access Manager Policy Server. 2.2 Provisioning Service The Provisioning Service is a collection of other services. These services are: Tivoli User Administration Resource Service (TUARS) Tivoli User Administration (TUA) Tivoli Security 11/26/2002 Copyright Acumen Advanced Technologies Inc. 10

11 These services along with TIM are part of Tivoli Management Framework (TMF), and collectively along with the managed endpoints make a Tivoli Managed Region (TMR). This section provides a brief overview of these services Tivoli User Administration Resource Service TUARS is daemon service that ties TID applications to the Provisiong Service, and runs the Provisioning Services machine. This daemon started automatically whenever the TMF oserv is started, a daemon that communicates with the TIM Web Interface and a daemon that interfaces with TUA and TMS. As described above, using TID, users create User Profiles and Security Profiles. These profiles are in fact created and maintained not by TID but by two other services, i.e. TUA and TSM respectively. Hence, TID requires communication with these two services during its operation. This communication from the Web Interface is provided through the TUARS daemons Tivoli User Administration TUA enables user management through user records, which are contained in user profiles. A TIM administrator manages user identities, user account data using these profiles. Once a user profile is created or modified, accounts for supported endpoint types (such as UNIX or NT) can be created from that profile. This information is then coordinated with the designated endpoints. Since TID identity profiles are kept within LDAP, the LDAP endpoint is specifically important. As long as an account create in TUA is not populated to LDAP, a user with that account cannot login Tivoli Security Manager Tivoli Security Manager provides a common interface to the native security systems of variety of operating systems. This tool provides an integrated facility for administering diverse systems and applications in a policy-oriented fashion. Tivoli Security Manager provides the following features: It allows for implementation of a security policy across an enterprise using a role-based security model. Roles correspond to job functions. User can define which users have a given role and assign or restrict resources based on that role. It increases the availability and integrity of systems by enforcing centrally managed security. Users can define many wide-ranging characteristics, such as password policy, resource access permissions, and group membership within a single product. As you add new roles, groups, or resources, they are immediately available throughout the application. 11/26/2002 Copyright Acumen Advanced Technologies Inc. 11

12 It allows users to use, through its integration with the Tivoli Management Framework on which it runs, distributed client/server architecture, diverse platform support, and built-in services such as encryption, policy, profile management, and subscription. It features a user interface consistent with other Tivoli applications. It limits the days and times users can log in or access system resources. Users can allow users to log in or access resources at all times, or restrict these items to specified days and time ranges. It produces a security audit trail. Users can audit any combination of login and access successes and failures. The application also protects the audit logs from unauthorized modifications. If Tivoli Enterprise Console (TEC) is installed, users can forward audit messages for processing and correlation. It protects a wide variety of resources across varying system types Endpoints The following Endpoints are supported by the Provisioning Services LDAP Connection Endpoint UNIX Endpoint NT Endpoint W2K Endpoint PeopleSoft Feed Policy Server Endpoint 2.3 Information Services The Information Services bundle includes the IBM SecureWay Directory (the LDAP directory), DB2 Extended Edition (the Request Database), and the IBM HTTP Server. The HTTP server acts as the LDAP Server and stores user information in the LDAP directory. 11/26/2002 Copyright Acumen Advanced Technologies Inc. 12

13 3 IBM Tivoli Access Manager The Access Manager is the product to perform enforcement of access control for Principals. Principals, whose identity and roles are defined using TID, their actions are controlled and enforced at runtime using the Access Manager product. The current version of Access Manager for e-business is version 3.9. This section provides a brief overview of the Access Manager installation and configuration. 3.1 Configuration Every component of Access Manager needs to be configured into the secure domain upon installation. Configuration ensures that different components of Access Manager can locate each other on the network, and that they can communicate with each other in a secure manner if SSL communication is required. Configuration can also be used for performance fine-tuning and improvement. Components initial configuration must be performed using the Access Manager provided utility named «pdconfig.exe». This utility writes its configuration info into Access Manager configuration text files (.conf files), as well as the operating system (e.g. Windows registry). Further fine configuration can be done by manual modification of the configuration files described in below Configuration Utilities This GUI based utility leads the users interactively through the configuration process. The utility enforces the user to configure the components in a predefined order, since configuring each component requires knowledge of the configuration info of other components already installed and configured. For example Access Manager Policy Server must be configured before any WebSEAL instance is configured. The utility should only be used after the LDAP user registry is installed and configured, since during configuration of the Policy Server, LDAP related information such as the LDAP server s host and port number are required. 11/26/2002 Copyright Acumen Advanced Technologies Inc. 13

14 The general configuration order enforced by the pdconfig utility is as follows: Access Manager Runtime Access Manager Policy Server Access Manager WebSEAL Access Manager Authorization Server Web Portal Manager Configuration Files These are text files that are read each time an Access Manager server starts running. The configuration files are modified by both the pdconfig utility and manual editing. This section briefly describes the major configuration files pd.conf This file contains entries that specify general configuration information needed by Access Manager including the location of SSL key store used by Access Manager components during an SSL handshake, the SSL session time-out value, and SSL key store password expiry time ldap.conf This file contains LDAP related configuration entries that specify the LDAP server s host name, SSL and non-ssl port numbers, SSL key store location and password (if an SSL LDAP communication is required), as well as the host name of LDAP replicas in case a master/replica LDAP setup is being used for performance enhancement purposes. Since there can be only one master LDAP server in a secure domain, there is only one ldap.conf file per domain ivmgrd.conf This file is used by Access Manager Policy Server to communicate with other Access Manager components. The entries in this file include the location of the ldap.conf file, location of the authorization database (acld) the Policy Server should maintain, and the DN and password that Policy Server should use to authenticate itself to LDAP. Since there can be only one Policy Server instance in a secure domain, there is only one ivmgrd.conf file per domain ivacld.conf This file is used by an instance of the Authorization Server. The entries in this file include the location and port number of the Policy Server, the DN and password that Authorization Server uses to bind to LDAP, the external plug-in services the 11/26/2002 Copyright Acumen Advanced Technologies Inc. 14

15 Authorization Server should load upon start-up, as well as other logging and performance tuning (e.g. threading) related settings. There can be multiple Authorization Servers per secure domain, therefore there can be one ivacld.conf file local to each installation of the Authorization Server webseald.conf This file is used by an instance of WebSEAL. The entries include LDAP related info such as the DN and password of the WebSEAL instance, junction related info such as the authentication scheme to be used (Basic, Form, Certificate, ) and how to handle dynamically generated URLs coming from the back-end servers, performance related settings such as user credentials caching and time-out, number of WebSEALs internal working threads, etc. There can be multiple WebSEAL Servers per secure domain; therefore there can be one webseald.conf file local to each installation of the WebSEAL. 3.2 Management Access Manager provides two utilities to manage the user information, the Access Control Lists (ACLs), and the secure resources or objects in Policy Server s object space. These utilities are the command console based pdadmin and the web interface based «Web Portal Manager». Master Authorization Database (POPs + ACLs) Maintains Management Server (pdmgrd) Administration API Replicates Maintains Management Console (pdadmin) Web Portal Manager Reads Policy Info. Replicated Authorization Database (POPs + ACLs) User Registry (UserID + PWD) Authorization Authorization Server Authorization Server (pdacld) Server (pdacld) (pdacld) Figure 2 Access Manager Administration Utilities 11/26/2002 Copyright Acumen Advanced Technologies Inc. 15

16 3.2.1 PD Admin pdadmin is a command line utility that can be used by authorized users (login required), to perform a set of management actions. The following sets of commands are available in pdadmin User/Group Management These commands can be used to: Create and delete users and groups in the LDAP registry. Import users and groups created by other means into Access Manager Modify a users attributes such a password and group memberships Display a user s info such as group memberships Junction Management These commands can be used to create junctions between an instance of the WebSEAL server and a Web Server. WebSEAL uses the junction information and the options specified in it in order to redirect the original user request to the back-end Web Server Object Management These commands can be used to create/modify custom objects in Access Manager s object space which represent an external resource to be protected. For example, an object called /Web/Servlet/BankServlet can be created to represent a Servlet called BankServlet. By attaching appropriate ACLs to the object an external entity can make authorization calls via the AZN API against the defined object to decide whether an identity is allowed to access the Servlet or not ACL Management These commands are used to: Create ACLs. Attach an ACL to a WebSEAL junction or a custom object in the object space. Add or remove user/group entries to/from the ACLs. Define each user s permissions on each object or junction Global Sign-On Management These commands are useful in conjunction with WebSEAL junctions to provide a user s different credentials/passwords specific to particular back-end application servers. 11/26/2002 Copyright Acumen Advanced Technologies Inc. 16

17 Using these commands a resource credential can be created/deleted/modified for a defined resource i.e. a back-end server, that the GSO enabled junction can use to retrieve the credential specific to the application being requested by the user at the moment Web Portal Manager Web Portal Manager is an application with a web interface that supports a subset of the commands that pdadmin provides. WPM needs WebSphere and the DB2 Database Manager as software prerequisites so it can be installed and configured. 3.3 WebSEAL LDAP User Registry Junctions' Object space Application/Web Server 1 3 Authorizes User 2 Authenticates User Application/Web Server 2 1 Client Request WebSEAL 4 Redirects Request Application/Web Server 3 Client Browser... Application/Web Server n Browser - WebSEAL (HTTP/HTTPS) WebSEAL - Back-End Server Junction (HTTP/HTTPS) Figure 3 WebSEAL Reverse Proxy 11/26/2002 Copyright Acumen Advanced Technologies Inc. 17

18 Access Manager s WebSEAL is a Reverse Proxy Web Server, which acts as a gateway and redirects the http requests coming from the browser or another web server to a back-end server. WebSEAL is capable of authenticating the user against the LDAP registry, and also checking user authorization to access the requested resource against ACLs attached to the junction, if any. If authentication/authorization fails for the current user request, WebSEAL returns an error page to the user browser, denying access to the requested resource; otherwise WebSEAL redirects the request to the back-end server by modifying the incoming URL based on the information stored in the corresponding junction. Based on the junction configuration WebSEAL can use different methods in terms of session management and user credentials transfer. Figure 3 shows a schematic view of how WebSEAL acts as a gateway and authentication engine Junctions A junction is a logical mapping of a name to a location (host name port number). WebSEAL uses the location of the server specified in the junction to translate the URL sent by the client browser into one to be sent to the back-end server. In doing so, WebSEAL acts as an agent impersonating the actual application client. The URL sent to WebSEAL by clients must include the junction name in it so that URL translation can be done correctly by WebSEAL. For example if a junction is defined as follows: /JCT1 Type : tcp Host : WKS20 Port : 8080 assuming WebSEAL runs on host websealhost port websealport, if the user types g.jsp, upon successful user authentication, WebSEAL will translate the URL into: and send it to the back-end server listening on port 8080 on a workstation named wks20. Besides the URL mapping information, a junction can be configured in a way to tell WebSEAL how to interact with the back-end server in terms of actual user authentication, session management, cookies, etc. A junction can be configure to perform the following: Send actual client s credentials in http basic authentication headers. Send actual client s credentials in http custom headers. 11/26/2002 Copyright Acumen Advanced Technologies Inc. 18

19 Perform dynamic URL translation. This is useful when returning the back-end server s response to the client browser, and the back-end server has generated dynamic URLs relative to its own web space. Use the GSO database in LDAP to provide the back-end server with its specific user password. Use SSL to communicate with the back-end server. This is particularly useful to prevent from the authentication HTTP headers being sent in clear text format. Point to multiple back-end servers, which are replicas of each other. This option instructs WebSEAL to perform load balancing on the back-end servers. Send session cookies to back-end portal servers so the portal can perform single sign-on to its application servers. Junction information is stored in the file system using XML format. WebSEAL reads the junction info from the junction database by loading and parsing the junction XML when it encounters the junction name in the URL. runserver.exe ACL attached to Resource ACL USER Michael lrwx ACL Entries USER Jimmy lr-x USER Lisa lr-- GROUP Sales l--x Figure 4 - Access Control List Example 11/26/2002 Copyright Acumen Advanced Technologies Inc. 19

20 3.3.2 Access Control A junction is a special type of object in Access Manager object space, therefore like any other object, access control policies can be attached to junctions as well. Access control policies in Access Manager have two possible forms: ACL (Access Control List) and POP (Protected Iobject Policy) Access Control Lists(ACLs) An Access Control List is a simple data structure, which can be implemented in many different ways. Basically an ACL is a collection of entries, each of which defines the privileges of a principal. An ACL can be attached to one or more resources in the secure domain so that when a client requests access to that resource, the authorization process can check the ACL attached to the requested resource to determine whether the principal is allowed access to the resource or not. Figure 4 is an example of an ACL attached to a network file named runserver.exe. According to the first entry in the ACL, an authenticated user named Michael may do the operations list, read, write, and execute (lrwx) on the runserver.exe file. The user authenticated as Jimmy can list, read, and execute the file, but not modify it. A user named John who is not specified in any ACL entry, but who is a member of the Sales group can list and execute the file Protected Object Policies(POPs) POPs are similar to ACLs except the policy they specify is not principal-based. Rather they can specify other attributes regarding access to the protected resource. For example a POP attached to an object can restrict access to that object based on the time-of-day or the client s IP address, so that requests coming from a known set of IP addresses will be blocked by WebSEAL Replication An instance of WebSEAL can handle a certain amount of login traffic. If the number of concurrent user login requests exceeds the limit for one WebSEAL instance users will encounter unreasonably long login times. One way to avoid this situation is to use WebSEAL replication. In this approach two or more WebSEAL instances are installed in the secure domain, and configured to use the same object space including the junctions database. A load balancing system e.g. a hardware loadbalancer can be used behind the replicated WebSEAL servers to direct the incoming user request to the least busy WebSEAL instance. Replicated WebSEAL servers can also be configured to provide fail-over capabilities, so that when a WebSEAL instance fails 11/26/2002 Copyright Acumen Advanced Technologies Inc. 20

21 during a user session, another live instance can take over the communication to the back-end transparently to the end user. 3.4 Policy Server In order to guarantee a consistent user/policy management method, it is advantageous to make sure all such management operations go through a single channel. Access Manager s Policy Server is one such component. A secure domain that uses Access Manager can have exactly one Policy Server instance installed and running. The Policy Server is the main engine that: Manages users/groups in the LDAP registry. Maintains the master policy database, which contains ACL, POP, and Object Space information. Locates WebSEAL and Authorization Server instances in the domain and notifies them of policy database updates, when they occur. Figure 2 shows how the Policy Server and multiple Authorization Servers work together to make authorization decisions based on the information stored in the policy database Object Space One can think of the Object Space as a directory tree structure each of whose entries represent an actual object outside Access Manager, which needs to be protected by Access Manager. By implementing the Object Space, the Policy Server creates a mapping from resources on remote systems to its internal data structures. The one-to-one correspondence between the actual resources and the entries in the objectspace ensure that Access Manager can always recognize the external resource and secure access to the correct resource. The objectspace tree structure consists of three main branches: WebSEAL used by WebSEAL instances to control access to web objects. Management used by the Policy Server to control access to the Access Manager administrative functions. This part can be used to grant users delegated administration authority. User Defined used by the authorization servers to control access to external (typically non-web) resources. Access control is performed by creating object in the objectspace, and attaching appropriate ACLs to them. An ACL attached to an object specifies the policy as to who can do what on that object. 11/26/2002 Copyright Acumen Advanced Technologies Inc. 21

22 3.4.2 Access Control Lists The Policy Server is the only component that is responsible for creating ACLs and attaching them to resources. Other Access Manager component can read data about ACLs and objects but not modify them directly. ACLs can be attached to any object in the objectspace including WebSEAL and non-webseal objects. Section gives more detailed information about ACLs Protected Object Policies POPs can also be attached to any object. POPs are also maintained by the Policy Server only. Section gives more information about POPs Management of Access Control An administrator can use the pdadmin utility, the Web Portal Manager or the Access Manager APIs to communicate with the Policy Server. Policy Server in turn maintains the policy database by: 1. Creating objects representing resources. 2. Creating ACLs. 3. Creating actions that define privileges to be granted on an object. 4. Attaching an ACL to one or more objects. 5. Adding users and/or groups to an ACL. Except for the user information, which is stored in LDAP, all other entities named above, i.e. objects, ACLs, actions, and object-acl attachments are stored in the policy database whose master version is maintained by the Policy Server. Policy Server can create replicas of the master policy database to be used by the authorization servers to perform access control operations in the secure domain Authorization Server The authorization server is the component in Access Manager that ultimately makes authorization decisions. Unlike the Policy Server, there can be multiple instances of the Authorization Server in a secure domain. The role of an instance of the Authorization Server is to read policy information from a replica of the policy database that is created and maintained by the Policy Server. In other words, the Authorization Server can communicate with the policy database in a read-only mode. Figure 2 shows how multiple Authorization Server instances communicate with the database replicas to make authorization decisions. 11/26/2002 Copyright Acumen Advanced Technologies Inc. 22

23 3.4.5 ACL Management The Authorization Server understands the format of the policy database, so that given an object name, a user name, and the name of the action requested by the user, it can match those information against objects and ACLs in the database, and return a yes/no answer indicating whether the user has access to the requested resource or not. As mentioned before this is a read-only operation, where the actual ACL management is done by the Policy Server only, guaranteeing the integrity of policy data in the secure domain Cache Management An instance of the Authorization Server always communicates with a local policy database replica. Other applications can communicate with an Authorization Server in a local or remote cache mode. In other words, the application and the Authorization Server it uses do not have to be on the same machine in the network, but the Authorization Server and its local database cache are always on the same machine Application Programming Interface Applications can use the authorization API to make access control decisions. Access Manager provides both C and Java versions of the authorization APIs. The API can be used in either local or remote cache mode. In the remote mode, the API calls a remote authorization server to perform authorization decisions on behalf of the application. In the local mode, the API downloads a local replica of the policy database. Therefore, in this mode the application performs all authorization decisions locally instead of across a network, which results in better performance. This mode of operation is not supported by the Java API in the 3.9, version of Access Manager Replication Policy database is replicated by the Policy Server, which already has all the location information about the Authorization Server instances in the domain. However, Access Manager can be configured so that each Authorization Server instance maintains its replica in one of these ways: 1. It can send update requests to the Policy Server at certain intervals of time, to synchronize its replica with the master copy maintained by the Policy Server. 2. It can listen to update notifications sent by the Policy Server whenever an update occurs. 3. A combination of both. 11/26/2002 Copyright Acumen Advanced Technologies Inc. 23

24 In any case, the Policy Server can always send notification only and it is up to the Authorization Server to download the new information from the Policy Server. Replication in any way is a matter of configuration and does not require any effort on the administrator s side. 3.5 Application Server Plug-in J2EE compliant application servers retrieve their security related information from the XML deployment descriptors as per the J2EE specifications. However, J2EE does not dictate how an application server must make security decisions as to whether a user requesting access to a secure resource does have the privilege to access the resource or not. Such decisions can be made by the J2EE container or delegated to an external security enforcement entity. AccessManager J2EE Application Server Principal Role Resource Figure 5 Access Manager J2EE plug-in Typically, in a J2EE secure application the deployment descriptor specifies which resources (e.g. Servlets, JSP files, html pages, EJB methods ) are secure, and which roles have which permissions on each resource. Mapping the security roles 11/26/2002 Copyright Acumen Advanced Technologies Inc. 24

25 to actual users or principals is specified in extensions to deployment descriptors. In other words, a J2EE application server implementation knows how to decide whether a user has a given role or not. This part of the access control decision making can either be done internally by the J2EE server or be outsourced via an appropriate plug-in component. Access Manager provides such plug-ins for two well-known application server products. As Figure 5 shows the mapping between the J2EE resources and J2EE roles is handled internally by the application server; whereas mapping of actual principals to roles is handled by an external entity, which is Access Manager in this case. Therefore, the junction point integrating a J2EE server and an external policy server is the J2EE role. Both the application server and the policy server must have the same understanding of what a role means WebSphere Plug-in Access Manager provides a plug-in to integrate the J2EE security requirements between the Policy Server and IBM WebSphere and above. This plug-in is an optional component that ships with Access Manager 3.9. The component includes a utility, which can read the WebSphere deployment descriptors, extract the application and role names, and copy those into Policy Server s object space. Therefore after running the utility there will be a one-to-one correspondence between a role defined in a deployment descriptor and an object in Policy Server s object space. When a user requests access to a resource, e.g. a Servlet, WebSphere decides whether that resource is secure or not. If it finds that the resource is secure, it communicates with Access manager via the plug-in to decide whether the user is authenticated and/or whether they do have the required role. Attaching users or groups to the defined object in Policy Server can be done by Access Manger utilities such as pdadmin independently of the WebSphere application server Weblogic Plug-in BEA Weblogic Server defines the notion of a Security Realm as a logical grouping of identities such as users and groups and the access policies in effect for those identities. A WLS instance utilizes a security realm to make authorization decisions as to whether the current principal has privilege to access the requested resource or not. WLS provides a set of security realms for known domains such as an LDAPRealm for the case where LDAP is used as the user registry, an NTRealm when MS- Windows domain is the user registry, as well as a DBMSRealm for relational database managers. 11/26/2002 Copyright Acumen Advanced Technologies Inc. 25

26 It also supports a customized security realm known as a CustomRealm, which is a defined interface that non-wls entities can implement and set up on a WLS server to be used by the J2EE container within WLS in order to make access control decisions. Access Manager provides such a Custom Realm implementation. Upon installing the WLS plug-in containing the Custom Realm, WLS will communicate with that realm, which in turn knows how to talk to the Access Manager s Policy Server in order to ask authorization questions and return the result to WLS, based on which the user is either granted or denied access to the requested resource. 11/26/2002 Copyright Acumen Advanced Technologies Inc. 26