h2. Restricting Access
LucidWorks consists of [two components|Working With LucidWorks Platform Components]: LWE Core and LWE UI.
Because it provides access to the REST API, direct access to the LWE Core component provides access to all of Solr's capabilities, including adding and removing documents, retrieving stored field values for all documents, and additional LucidWorks-enhanced capabilities such as job scheduling, system status, and indexing file, web, and database sources. The LWE Core component should only be directly HTTP accessible to other components that need access to Solr or REST API interfaces. If you are using a single server installation and don't want to expose Solr or REST API interfaces via the network then you might want to restrict access to LWE Core to localhost only. You can do that by adding the [socket connector's {{host}} attribute for the Jetty container|http://docs.codehaus.org/display/JETTY/Configuring+Connectors#ConfiguringConnectors-ConfigurationOptions].
You can also restrict direct access to LucidWorks components by IP address, or by fronting it with an authenticating firewall. For a production implementation, consider restricting access to the component HTTP ports to only by the application, just as one would do with a typical relational database. If you are using the LucidWorks Platform's built-in search filters or document-level authentication, you *must* prevent access to LucidWorks by any process other than your application in order to prevent circumvention of these features.
{info:title=Implementing SSL}Some of the components can be implemented with SSL. See the chapter [Enabling SSL] for more details.{info}
h2. Restricting Access to LucidWorks User Interfaces
LucidWorks has two built-in authorizations to control user access:
* ADMIN allows users to access any part of the LucidWorks Enterprise UI.
* SEARCH limits users to only the built-in end user search interface.
You can restrict a user's access to specific parts of the application by mapping manually created or LDAP-supplied usernames and/or LDAP-supplied groups to appropriate authorization on the User screen in the Admin UI.
h2. Hiding Documents by Restricting Access
The privileges of the LucidWorks process and the rights that process has to access documents for indexing are crucial to its proper operation. Generally, you want LucidWorks to be able to access all documents within a particular folder or from a particular web site. The built-in LucidWorks crawlers will index any specified document, as long as the LucidWorks process has permissions to do so. After a document has been indexed, all stored fields are accessible through the Solr interface.
That said, documents can be excluded from indexing by leveraging operating system, file, and web-level security capabilities; if the process doesn't have access, it will not index the content.
Some data sources, such as those configured to crawl content in a [database|Create a New JDBC Data Source], [SMB|Create a New SMB Data Source], [SharePoint|Create a New SharePoint Data Source], [S3|Create a New S3 Data Source] or [S3N|Create a New S3N Data Source] servers, credentials need to be supplied for the crawler to access the system. Those credentials determine what documents the crawler has access to.
{scrollbar}
LucidWorks consists of [two components|Working With LucidWorks Platform Components]: LWE Core and LWE UI.
Because it provides access to the REST API, direct access to the LWE Core component provides access to all of Solr's capabilities, including adding and removing documents, retrieving stored field values for all documents, and additional LucidWorks-enhanced capabilities such as job scheduling, system status, and indexing file, web, and database sources. The LWE Core component should only be directly HTTP accessible to other components that need access to Solr or REST API interfaces. If you are using a single server installation and don't want to expose Solr or REST API interfaces via the network then you might want to restrict access to LWE Core to localhost only. You can do that by adding the [socket connector's {{host}} attribute for the Jetty container|http://docs.codehaus.org/display/JETTY/Configuring+Connectors#ConfiguringConnectors-ConfigurationOptions].
You can also restrict direct access to LucidWorks components by IP address, or by fronting it with an authenticating firewall. For a production implementation, consider restricting access to the component HTTP ports to only by the application, just as one would do with a typical relational database. If you are using the LucidWorks Platform's built-in search filters or document-level authentication, you *must* prevent access to LucidWorks by any process other than your application in order to prevent circumvention of these features.
{info:title=Implementing SSL}Some of the components can be implemented with SSL. See the chapter [Enabling SSL] for more details.{info}
h2. Restricting Access to LucidWorks User Interfaces
LucidWorks has two built-in authorizations to control user access:
* ADMIN allows users to access any part of the LucidWorks Enterprise UI.
* SEARCH limits users to only the built-in end user search interface.
You can restrict a user's access to specific parts of the application by mapping manually created or LDAP-supplied usernames and/or LDAP-supplied groups to appropriate authorization on the User screen in the Admin UI.
h2. Hiding Documents by Restricting Access
The privileges of the LucidWorks process and the rights that process has to access documents for indexing are crucial to its proper operation. Generally, you want LucidWorks to be able to access all documents within a particular folder or from a particular web site. The built-in LucidWorks crawlers will index any specified document, as long as the LucidWorks process has permissions to do so. After a document has been indexed, all stored fields are accessible through the Solr interface.
That said, documents can be excluded from indexing by leveraging operating system, file, and web-level security capabilities; if the process doesn't have access, it will not index the content.
Some data sources, such as those configured to crawl content in a [database|Create a New JDBC Data Source], [SMB|Create a New SMB Data Source], [SharePoint|Create a New SharePoint Data Source], [S3|Create a New S3 Data Source] or [S3N|Create a New S3N Data Source] servers, credentials need to be supplied for the crawler to access the system. Those credentials determine what documents the crawler has access to.
{scrollbar}