Citrix MetaFrame Secure Access Manager is, historically speaking, the successor to Citrix NFuse Elite that had Secure Gateway as an additional extension component. Contrary to NFuse Classic, Citrix NFuse Elite could not only map the Program Neighborhood to the Web, but could also present external content that had been linked in. One of the major components of Citrix MetaFrame Secure Access Manager runs on the basis of Windows Server 2003 Internet Information Services. In combination with other components, Citrix MetaFrame Secure Access Manager establishes an environment with scalable access to centralized applications and information. So far its functions outstrip those of Citrix’s Web Interface for MetaFrame XP.
The Citrix MetaFrame Secure Access Manager is based on the ISAPI extensions of Internet Information Services. The Internet Server API (ISAPI) is an application programming interface (API) on a server platform for initiating software services optimized for the Microsoft Windows operating system. ISAPI is an API for developing extensions for Internet Information Services (IIS) and other HTTP services supporting ISAPI.
Citrix MetaFrame Secure Access Manager combines applications and information from all types of different server systems in a common interface. The applications might, of course, also originate in a MetaFrame server farm, but Secure Access Manager does not rely on such applications exclusively. Using Citrix MetaFrame Secure Access Manager, Web applications or static Web content can be made available through a secure connection. Due to its architecture, Secure Access Manager is suitable for small, mid-sized, and large companies. If required, the individual components can be installed on dedicated computers, thus increasing scalability. Some components allow for multiple installation to facilitate load balancing.
The architecture of Secure Access Manager is no simple matter because it includes a large number of components:
A state server manages all access centers, which can be considered the highest administrative units. The state server thus manages all user profiles, session information, and access center configurations. The state server is a flat file system located in the %InstallDir%\CONFIG\STATE SERVER folder. Each Secure Access Manager server farm has only one state server. High availability levels for several state servers can be achieved using Microsoft’s cluster services.
The repository is the database for the Secure Access Manager and is based either on Microsoft SQL Server or Microsoft SQL Server 2000 Desktop Engine (MSDE). This database is used to store the basic data and a copy of the access center configurations as they exist on the state server. The database does not contain any user-specific information. Here, too, availability can be significantly improved by using a cluster solution.
A content delivery service (CDS) manages and generates all access center information, including pages, users, roles, color schemes, and content delivery agents (CDA). The content delivery agents incorporate certain functions that are linked to other functions within the Secure Access Manager to a limited extent or not at all. The CDS receives incoming messages from the user’s Web browser and identifies which pages are being requested by whom. It also checks the user’s authentication. Finally, the page is created and transmitted to the Web browser for display.
An agent server is where the content delivery agents (CDAs), DLLs, and the content delivery service (CDS) are installed. A Secure Access Manager server farm can consist of several load-balanced agent servers. However, there is only one CDS per agent server.
The Web server houses the access center and is therefore the point of access to all information and applications. Each access center is created in the form of a virtual folder. After a new access center has been created and the system has been configured, the access center can be accessed through /
With the help of the index server, users can search documents and Web sites in the intranet and on the Internet. The index server indexes the content and delivers the search results in the form of links to the documents identified. The server assumes the existing security settings, allowing users to see only those documents for which they have read and write access.
Figure 13-8: The architecture of an environment with Secure Access Manager. In addition to the potential of linking up MetaFrame servers, further application servers can also be integrated.
Following is an overview of the communication processes that take place in an environment with a Secure Access Manager when accessed by a user:
The Web browser on the client platform requests, via HTTP, a Web page from the Web server.
The Web server contacts the agent server and requests the page content. If the environment contains more than one agent server, an internal algorithm in the Web server ensures proper load balancing and selects the appropriate agent server.
The agent server contacts the state server and requests the configuration information.
The agent server generates the page with the required CDAs and sends it to the Web server in XML format.
The Web server converts the XML data stream into an HTML document, which is transmitted, via HTTP, to the Web browser on the client platform. The Web browser processes the incoming data stream and makes the resulting page available to the user.
The installation of Citrix MetaFrame Secure Access Manager on Windows Server 2003 requires that certain conditions be met.
The target platforms should have at least 512 megabytes (MB) main memory.
Internet Information Services must be installed using the Windows Server 2003 server configuration wizard, allowing the ASP.NET Web service extension.
.NET Framework 1.0 with Service Pack 2 and Microsoft Data Access Components (MDAC), version 2.7 Refresh, must be installed.
Under the Identity tab in the Application Pool’s Properties dialog box, the service account that is to be used with the Secure Access Manager server farm must be determined. The service account must be in the domain administrator group if the Secure Access Manager is to be installed on more than one server.
All of the preceding prerequisites must be in place before Citrix Secure Access Manager can be installed. All required components can be found on the installation CD containing Citrix Secure Access Manager.
The installation routine is wizard-based and follows the usual procedure. There are only two instances where it is possible to select options that have a major impact on the role of the future server. In the first instance, you are asked to choose whether to install the administration components for Secure Access Manager only, or to install the server components, too. In the second instance, you are given the possibility to join an existing farm or to create a new farm. All other options concern the target folder or service account only.
After the installation, certain settings need to be established before Secure Access Manager can be used on a target platform.
The Host.dll component must be added to the Web services extensions in the Internet Information Services and be allowed. The Host.dll file is located in the \Bin folder in Secure Access Manager’s installation directory.
The ASP.NET v1.0.3705 Web services extension must also be added and enabled manually. The path %SystemDrive%\windows\microsoft.net\framework\v1.0.3705\aspnet_isapi.dll must be entered to provide access to the required files.
If an access center has been created, the Default Application Pool must be linked to its assigned virtual directory.
All components of Citrix MetaFrame Secure Access Manager can be installed on a single server. However, distributing several instances of Secure Access Manager across separate servers is clearly the preferred option. This solution is scalable and more able to adapt to different requirements relating to user extension or processor load. The minimum configuration requires one Web server, two agent servers, one state server, and one database server. When selecting components during the installation process, it is possible to choose which components will be activated. However, the Web server and agent server components are always installed.
In addition to the index server, the Secure Gateway is also available as an optional component on the Secure Access Manager installation CD.
Secure Access Manager is managed in the Access Management Console (AMC). The AMC is a Microsoft Management Console snap-in. Each node within the Access Management Console represents an administrative area. Menus can be displayed or the wizards launched by clicking on the AMC with the right mouse button. This makes the administration of the Secure Access Manager quite easy.
The name of the Secure Access Manager server farm is the same as the name of the state server. The state server is therefore always the primary server in a server farm. On the basis of the server farm name, it is now possible to add or import a new access center. The access center properties facilitate the administration of agent servers, Web servers, and index servers within the server farm.
The main menu entries within an access center are folders. They determine what information is found where and to whom this information will be made available. Web pages that the user may see are allocated to a folder. The CDAs that incorporate the information or application logic in a graphical area are positioned on a Web page. It is also possible to launch several instances of a single CDA on one page. This way, the user can see all the main information at a glance.
The role of the user, too, has a major influence on the personalized presentation of the information and application icons. A role defines a group of users by their function within a company or by the applications, data, and other resources they use. Roles are used to determine the following display features for users:
The default color scheme
The CDAs that a user can add to the current page
The pages a member of a role group can see
With its Developer Network (http://www.citrix.com/cdn), Citrix offers two development environments (software development kits, or SDKs) for generating CDAs. One of the SDKs is suitable for developing scripting CDAs that work on the basis of Microsoft Visual Basic script logic. The other SDK facilitates CDA development with the .NET Framework under Microsoft Visual Studio .NET (Web Forms). However, using these SDKs requires extensive knowledge of programming Web applications.
Generally speaking, Secure Access Manager does not need a MetaFrame XP Presentation Server to work, nor is the latter required for the installation to be successful. However, to provide users with more than just information from different data sources, the Secure Access Manager offers the opportunity to access the published applications of a MetaFrame server farm through a corresponding Program Neighborhood CDA. The appearance of the application links is the same as that of Web Interface for MetaFrame XP. No modifications on the MetaFrame servers are required in this respect. Rather, Secure Access Manager is based on the corresponding existing infrastructure of MetaFrame servers.
Just as with Web Interface for MetaFrame XP, it is also possible to use Secure Gateway for Secure Access Manager to make the communication between the various communication transmission points secure. The main difference is that, with Secure Access Manager, the Web server is usually located in the secure company network and not in the demilitarized zone between the firewalls. Architectures with several demilitarized zones are also possible, but these clearly go beyond the focus of this book.
Figure 13-10: Integrating Secure Gateway in Secure Access Manager.
When a user starts an application from the Program Neighborhood CDA, the procedure is as follows:
The user logs on to the access center. In line with his or her relevant role, the user has permission to use the Program Neighborhood CDA.
When the Program Neighborhood CDA is loading, it asks the MetaFrame server farm to transmit the list of applications the user will have access to.
The user starts an application by selecting the appropriate icon. Using the XML service of a MetaFrame server and the load-balancing mechanism, the Program Neighborhood CDA determines which MetaFrame server to use for executing the application.
The Program Neighborhood CDA contacts the session ticket authority and receives a ticket for the internal server address.
The ticket is positioned in the ICA file for the application start. Next, the server address is replaced by the address of the Secure Gateway in the ICA file.
The ICA file is transmitted to the client.
The ICA client opens an SSL connection to the Secure Gateway. Inside the SSL tunnel, there is a normal ICA connection.
The Secure Gateway contacts the session ticket authority and validates the ticket transmitted by the client via SSL. If the ticket is valid, the Secure Gateway receives the IP address of the relevant MetaFrame server.
The Secure Gateway passes on the ICA connection to the relevant MetaFrame server. The ICA session is now established.
The Program Neighborhood CDA thereby allows published applications to be integrated into the Citrix MetaFrame Secure Access Manager relatively easily. However, it is clear that the Secure Access Manager is not focused on the integration of MetaFrame servers alone, but rather on providing a general portal environment.
The Secure Gateway that comes with the Citrix MetaFrame Secure Access Manager has greater functionality than the Secure Gateway of the Citrix MetaFrame XP Presentation Server. The additional functions pertain in particular to tunneling HTTP data streams.