Feedback
Table Of Contents
Microsoft Office SharePoint Server 2007 Integration Overview
Product Architecture
Microsoft Office SharePoint Server 2007 Integration Overview
Microsoft Office SharePoint Server (MOSS) adopts a typical three-tier model with web servers in a De-Militarized Zone (DMZ), application servers in the application tier, and a database server at the database tier where all the data and configuration information is stored. The front-end web servers are IIS web servers that can be network load-balanced to achieve additional performance and fault tolerance (like SharePoint Portal Server 2003). The backend database is a Microsoft SQL Server 2005 (Enterprise or Express Edition) database service and can be clustered.
In the middle, however with MOSS, it is mandatory to have a Shared Service Provider (SSP). SSP is a collection of application servers that provide shared services out to any portals or sites that need them. These services include:
•
Search
•
•
•
•
•
•
Figure 2-1 MOSS 2007 Topology
Figure 2-2 illustrates the integration architecture. The Policy Enforcement Point (PEP) or agent assemblies are installed on the front-ending MOSS IIS servers in the .NET GAC, with configuration files located in the web.config folder or system path of the application. The Cisco Enterprise Policy Manager (EPM) policy store database is ideally co-located on the Microsoft SQL Server 2005 cluster used by MOSS; although it could be hosted on a distinct RDBMS infrastructure such as Oracle 10g or SQL Server 2000/2005 as required. The Cisco Policy Decision Points (PDPs) are hosted on application server clusters such as Tomcat, WebLogic, or WebSphere. MOSS components are installed as normal.
Figure 2-2 CEPM and MOSS 2007 Integration Architecture
End-user or site-administrator managed policies for MOSS resources and the MOSS site-hierarchy is synchronized from MOSS to CEPM via a configurable MOSS feature. Policies can then be administered by corporate security administrators via CEPM administration GUI (PAP). After policies are configured and users make requests for MOSS sites, the PEP is invoked and it makes authorization requests in the form of SOAPified or raw XACML/HTTP(S) messages to the PDP. The PDP can be configured to use external attribute sources in the form of LDAP directories, RDBMS databases, web services, and business logic (encapsulated into Java classes) to obtain additional user and application related information for use in making an authorization decision. After the PDP has processed the request and formulated a response, it sends back a SOAPified or raw XACML/HTTP(S) message to the PEP, encapsulating the authorization decision as well as any preconfigured obligations. The PEP applies the appropriate allow/deny decision to MOSS. Additionally, the PEP acts as a role provider for MOSS, so that all role-management can be abstracted to CEPM.
PDPs may be clustered using the cluster features of the application server that hosts the PDP web application. Alternatively, if the PDPs are hosted in stand-alone Tomcat instances, they may be load-balanced using hardware load-balancers (for example, BigIP F5 and Cisco ArrowPoint). If neither application-server cluster or network load-balancers are employed to load-balance the PDPs, then the PEPs can be configured to use simple round-robin load-balancing of PDPs as required.
The request and response chain and authorization decisions are all audited by the PDP to configured audit databases for reporting purposes.
