This section contains information about the different resources used by the Bentley ProjectWise Connector (for Oracle and ArcGIS).It should help in understanding the security requirements and give some configuration guidance.
The Resources:Connector Workspace PathThis is the location where the workspace information for the Connector is stored. Parts of the software must have read access and others need write access. This is the place where we originally set the path, using the Connector Engine Configuration wizard:
The workspace root directory is the location where the configuration information needed by the Connector will be stored. The specified folder also stores all the workspaces for the current server. As the dialog says, we will often use a network path instead of a local directory. This will have configuration implications since this default root directory will be used by default when the workspaces will be created in the Geospatial Connector Administrator. By using a shared location, the workspaces can be shared among all the Connector users. The Windows operating system is the entity that controls file access so we'll have to make sure that the Windows identity under which the software is running gets granted the required access by Windows. We will also have to make sure we do give the correct grants on the folder.
ProjectWise Orchestration Framework DatabaseSome parts of the Connector software need to access the Orchestration Framework database for read or read-write purposes. This database is configured outside of the Connector's context; normally a Microsoft SQL Server hosted somewhere else. Its authentication method will have an impact on the Connector setup. It can normally be configured to be accessed either using a specific username and password or using Windows Integrated security. This configuration is part of the Orchestration Framework Database Setup and looks like this:
Choosing "Windows integrated security" means that Windows identity, under which the software runs, must be allowed to access the database. Choosing "specific username and password" is the simplest solution as the software will simply pass those credentials to the database and that will work whatever the Windows identity under which the software is running.
Software parts that access the resources:"Services" Web ServiceThis web service hosts some methods that fetch information about workspace files or configuration. It also contains a method that "forwards" commands to the Orchestration Framework. It must be able to read from the Connector Workspace Path and also read from the Orchestration Framework Database. "JobStatus" Web ServiceThis web service contains methods to interact with the Orchestration Framework and control the Connector jobs. It must be able to read and write to the Orchestration Framework Database.Orchestration Framework processorsThe connector software installs its own processors in the Orchestration Framework. These will handle jobs like updating configuration files and extracting and posting information. These will require read and write access to the Connector Workspace Path and obviously also require read-write access to the Orchestration Framework Database. Since they are started, or spawned, by the Orchestration Framework service they inherit their access rights from the account that runs the service.Connector Engine Configuration ProgramThis stand-alone executable is either started from the Geospatial Connector Administrator if the Orchestration Framework configuration has never been done before, and it can also be started manually when changes must be done to the configuration.It requires read-write access to the Connector Workspace Path as well as read-write access to the Orchestration Framework Database.
Windows identity configurationAs you will have seen from the previous sections, the key here is controlling the Windows identity under which each piece of software runs. This is different for every piece.Web ServicesIMPORTANT NOTE: This section assumes that there is no access control on the web services. That is, the web services must be configured to allow anonymous connections. This has always been a requirement for the Connector. Note that the rest of the IIS site can be secured in all cases but the Connector web services must have Anonymous access ON. If IIS must be configured to restrict access to the web services to only certain user accounts, changes will need to be done to the Connector software. No such change is currently planned.Both web services will have similar configuration as they are both hosted by Microsoft's IIS. The web services are asp.net code that runs inside an IIS application pool. By default they run under the Windows identity of the worker processes that the containing application pool launches. These processes are typically named aspnet_wp.exe or w3wp.exe, depending on the actual IIS version. The Windows identity under which they run also varies depending on the IIS version, ASPNET being one of them. However in all cases this identity has fairly restricted rights.There are multiple options to make this work:No impersonationIn this case we leave the IUSR_MachineName account as the account that IIS uses when an anonymous request comes in. Since we are not impersonating, it makes no difference for the web service work. However if the IUSR_MachineName account is disabled this option will not work. No change is required in the web.config file. However, we must manually grant the correct rights to the account that runs the worker processes to the Connector Workspace Path. We must grant read, write, and create rights to that account. That particular account depends on the IIS version so we must refer to the IIS documentation here. Important: The default account which runs the worker processes will not have network access so if you are using a Network share as your Connector Workspace path this solution will not work. Since the software will be running under a machine-local account (ASPNET or other), this option will not work if your Orchestration Framework Database is setup to use Windows Integrated Security and the database runs on a different computer. It is possible that this works when the database is local to the Connector server machine but not guaranteed.Impersonation with username in web.configHere again we leave the IUSR_MachineName account as the account that IIS uses when an anonymous request comes in. It makes no difference for the web service work since we will be impersonating another user. However if the IUSR_MachineName account is disabled this option will not work. We must edit the web.config files of both connector web services to activate impersonation.This must be done by adding a section such as:Note that the username and password are stored in clear text in the web.config file. In some cases this may be unacceptable. It is also possible to get the username and password encrypted in the Windows registry using the Data Protection API (DPAPI) instead of writing them in clear text in the config file. If you choose this option you will have to see the Microsoft documentation on this subject.Whatever Windows identity you choose to configure here must have read, write, create access to the Connector Workspace Path. If the path is a network share that user account must have network access. This is normally taken care of by using an account that is part of the domain. This solution can work in cases where the Orchestration Framework database is configured to use Windows Integrated Security as long as the database server can recognize and accept that Windows Identity.
Impersonation of anonymousHere, we can change the account that is configured in IIS for anonymous logins, or we can leave IUSR_MachineName. We must edit the web.config files of both connector web services to activate impersonation. This must be done by adding a section such as:In this case the web services will be running under the Windows identity that we have entered in the IIS configuration for anonymous logins. It is not necessary that this identity be an administrator of the machine. However it must have read, write; create access to the Connector Workspace Path. If the path is a network share that user account must have network access. This is normally taken care of by using an account that is part of the domain. This solution can work in cases where the Orchestration Framework database is configured to use Windows Integrated Security as long as the database server can recognize and accept that Windows Identity.Orchestration framework processorsThe identity under which the Orchestration Framework runs is configured when you install the Orchestration Framework. All processes started by the Orchestration Framework will inherit this Windows identity. The connector processes require read, write, and create access to the Connector Workspace Path so you must use a Windows identity that has these rights. If the Path is a network share, the Windows identity must have network access rights.If the Orchestration Framework database is configured to use Windows integrated security this must be an account that the database server can recognize and accept.Connector Configuration ProgramSince this program is either started directly or through the Geospatial Connector Administrator, it will run under the Windows Identity of the current Windows interactive session. You must be logged in using an account that has read, write; create access to the Connector Workspace Path. In cases where the Orchestration Framework database is setup to use Windows Integrated security this account must also be recognized and accepted by the database.
Configuring the Connector on Windows Server 2008
With IIS 7 version delivered with Windows 2008 Server Operating System, the default "NetworkService" account would not allow the Connector web service to write the version list to a shared folder. To resolve this, configure the web service's application pool to use a more powerful account, and made the web service impersonate the windows user. To do so, for the account, from:Server Manager->Roles->Web Server->Internet Information Server, in the Connections pane, click on Application Pools - in the Application Pools pane. Right click on "Bentley Connector Operational Services" which is the application pool that contains the OSCWebServices.
Choose Set Application Pool Default. The Application Pool Defaults dialog displays:
Under Process Model group, for Identity, click on ... to get the dialog that allows you to select the Built-in account "LocalSystem", which is a more powerful account:
The Connector Web Services cannot be reached:
Once the server component of the connector has been installed, in IIS (Internet Information Services), make sure the Web Site is running and it has the "OSC/AGC Web Services". The connector web services are accessible from a web browser on the connector server machine at:http://localhost/AGCWebServices/services.asmx (ProjectWise Connector for ArcGIS)
ProjectWise Orchestration Framework Database settings:
Orchestration Framework DB and NT Authentication (Part 1)
Orchestration Framework Database and NT Authentication (Part 2)