App Security

App Security is a new way to handle security for Apps. Instead of using classic ACL-based security via Exalead CloudView, Apps administrators are able to define security rules based on user logins and/or security tokens and Exalead CloudView queries. Note that both security types can coexist: ACLs and App Security rules will both be applied in this case.

This page discusses:

Instead of relying on document ACLs for determining if a given user has the right to see a given document, App Security lets administrators define security rules based on user logins and/or security tokens and Exalead CloudView queries.

It can also restrict access to attributes (metas), facets, prefix handlers and application features: this is the Level of Detail configuration.

This also enables deployments where ACLs are hard to fetch (for example, SmarTeam) or non-indexable (for example, some ENOVIA instances).

How it works?

When App Security is enabled, OnePart works like this:

  • A user only sees documents that he or she is allowed to see according to the rules defined in the App Security configuration.

  • These rules are defined by a set of Exalead CloudView queries.

  • For every query that the user types, the App Security module appends the user query AND the query resulting form the applicative security rules.

  • If a user is part of multiple groups, all of the restricting queries will be joined with a OR.

    • example of the resulting index query: userQuery AND (queryFromRule1 OR queryFromRule2 etc.)

  • The Level of Detail modifies the search logic at query time to remove any attributes (metas), facets or prefix handlers the user is not supposed to see.

  • If a user is part of multiple groups and has multiple level of details, all of the levels of detail will be applied, hence all the attributes (metas) defined in each level of detail will be removed.

App Security configuration

App Security configuration is defined by the following:

  • a boolean enabled: set to true if OnePart is to use App Security and false to keep using classic Exalead CloudView security.

  • a boolean keepCloudviewSecurity: by default, it is disabled therefore, the Exalead CloudView ACL-based security is ignored. If set to true, both the APP security and ACL-based security are applied.

  • a string defaultQuery: if App Security is enabled, and a user logs in and does not belong to any group.

  • example of the resulting index query: userQuery AND defaultQuery

  • a string defaultLevelOfDetail, ID of the level of detail in the configuration to apply to users that do not belong to any group.

  • a list of groups

  • a list of levels of detail

What are groups?

An App Security group is made of:

  • a name that is its id

  • a list of logins and/or a list of security tokens - these define the users in the group

  • a query that is the restricting query applied to all users of this group

  • a levelOfDetail that is the Id of the level of detail to apply to users of that group

A level of detail is made of directives which can only be DenyDirectives in the current version.

What are directives?

A directive has a document matching condition which must be a MEL expression. In this case, the directive will only be applied on documents that match the given expression. See Example 5. A MEL Expression must start with ${ and end with }. For more information on MEL syntax, please refer to the Exalead CloudView documentation.

A directive has a list of:

  • Attributes (metas)

  • Facet

  • PrefixHandler

How to use it?

App Security is based on a configuration defined in the DATADIR\config\AppSecurity.xml file.

  • You do not need to define any groups for the App Security to work (but in this case, only the default query is applied).

  • An empty level of detail (no directives) means users with this level of detail can have access to anything in a document.

  • It is possible to use metas and facets defined in the Elastic Data Model (see the OnePart Reference Guide) in your DenyDirectives, and also in your document matching conditions.

  • You can also use custom MEL functions in your document matching conditions, provided they are properly deployed in your Mashup Builder application.

To enable App Security

  1. Edit the DATADIR\config\AppSecurity.xml file.
  2. Change the enabled property to true.
  3. Edit the configuration. See examples below.
    1. You do not need to define any groups for the App Security to work (but in this case, only the default query is applied).
  4. In the Administration Console at http://<HOSTNAME>:<BASEPORT+1>/admin, click CTRL + Apply to force and apply configuration.
  5. (IMPORTANT) Restart the searchserver.
  6. This step needs to be done each time the configuration is modified.

Limitations

Even when App Security is enabled and can hide some results from some users, this filtering is not applied to suggestions.

  • In practice, John can have V5371012.CATPart suggested to him even though he is prevented from seeing it in the search results by applicative security. However, if he selects this suggest query, he indeed gets no results. Should you need to work around this behavior, you must disable the suggest feature: see the OnePart Installation Guide: Troubleshooting.

  • Queries are not optimized: the original queries will be executed entirely before the restricting queries are applied.

  • Only simple declarative logic can work; you cannot declare "any user NOT in a group" except via the default query mechanism.

  • If you want a user "DOMAIN\login" to be found by the App Security, you must declare the login as such in the configuration. Note that <Login login="login"/> will not match "DOMAIN\login".

  • Deny directives on facets will not be applied when a document condition is matched.

  • For Level of Detail:

    • Only the download feature can be removed for the OnePart application using the attribute feature_download

    • In the Table and Compare view, even if a user does not have access to a meta and it is mandatory, the column/line associated will appear (but will be empty).

Example 1- admins only

By default, users see nothing and only the admin can see all documents. 

<AppSecurityConfiguration enabled="true" defaultQuery="NOT #all" defaultLevelOfDetail="0" 
xmlns="exa:com.exalead.apps.appsec" keepCloudviewSecurity="false">
        <Group name="admin" query="#all" levelOfDetail="0">
                <Login login="app-admin"/>
        </Group>
		<LevelsOfDetail>
    	    <LevelOfDetail id="0" name="Allow all"/>
	    </LevelsOfDetail>
 </AppSecurityConfiguration>

Example 2 - By default, users see all documents but can't download

By default, users see all documents but can't download them; only the admin user can. 

<AppSecurityConfiguration enabled="true" defaultQuery="#all" defaultLevelOfDetail="1" 
xmlns="exa:com.exalead.apps.appsec" keepCloudviewSecurity="false">
		<Groups>
	        <Group name="admin" query="#all" levelOfDetail="0">
                <Login login="app-admin"/>
    	    </Group>
		</Groups>
		<LevelsOfDetail>
    	    <LevelOfDetail id="0" name="Allow all"/>
			<LevelOfDetail id="1" name="Download deny">
				<DenyDirective>
					<Attribute id="feature_download"/>
				</DenyDirective>
			</LevelOfDetail>
	    </LevelsOfDetail>
</AppSecurityConfiguration>

Example 3 - multiple users and groups

By default, users see .txt files, user1 and user2 can see everything, and users in the group onepart can see all documents from project onepart without seeing the project attribute and facet: 

<AppSecurityConfiguration enabled="true" defaultQuery="file_extension:txt" 
defaultLevelOfDetail="0" xmlns="exa:com.exalead.apps.appsec" keepCloudviewSecurity="false">
		<Groups>
	      <Group name="all" query="#all" levelOfDetail="0">
                <Login login="user1"/>
                <Login login="user2"/>
    	  </Group>
			<Group name="onepart" query="project:onepart" levelOfDetail="1">
				<SecurityToken token="group:onepart"/>
			</Group>
		</Groups>
		<LevelsOfDetail>
    	    <LevelOfDetail id="0" name="Allow all"/>
			<LevelOfDetail id="1" name="Project deny">
				<DenyDirective>
					<Attribute id="project"/>
            	    <Facet id="project"/>
				</DenyDirective>
			</LevelOfDetail>
	    </LevelsOfDetail>
</AppSecurityConfiguration>

Example 4 - all users except testers group

Users can see everything, except users from the group testers, which cannot see documents tagged as confidential and see the authors on documents or even search by author: 

<AppSecurityConfiguration enabled="true" defaultQuery="#all" defaultLevelOfDetail="0" 
xmlns="exa:com.exalead.apps.appsec" keepCloudviewSecurity="false">
     <Group name="testers" query="NOT tag:confidential" levelOfDetail="1">
										<SecurityToken token="group:testers"/>
     </Group>
		<LevelsOfDetail>
			<LevelOfDetail id="0" name="Allow all"/>
			<LevelOfDetail id="1" name="deny author">
				<DenyDirective>
	           <Attribute id="author"/>
            <Attribute id="best_author"/>
            <Facet id="best_author"/>
        	   <PrefixHandler id="author"/>
    	       <PrefixHandler id="document_best_author"/>
	    </DenyDirective>
			</LevelOfDetail/>
	 </LevelsOfDetail>
</AppSecurityConfiguration>

Example 5 - user1 can download any document, except a SolidWorks document

Example on using a document matching condition.user1 can see all documents, but cannot download documents whose family contains ‘solidworks’.

<AppSecurityConfiguration enabled="true" defaultQuery="#all" defaultLevelOfDetail="0" 
xmlns="exa:com.exalead.apps.appsec" keepCloudviewSecurity="false">
     <Group name="user1" query="#all" levelOfDetail="1">
		 								<Login login="user1"/>
     </Group>
  <LevelsOfDetail>
 		<LevelOfDetail id="0" name="Allow all"/>
		 <LevelOfDetail id="1" name="no SW download">
          <DenyDirective documentMatchingCondition="${str:contains(entry.metas['opfamily]
','solidworks')}">
               <Attribute id="feature_download"/>
          </DenyDirective>
		 </LevelOfDetail/>
	 </LevelsOfDetail>
</AppSecurityConfiguration>

Example 6 - Using prefix handlers in your queries with spaces between the terms

This is a simple example when your restricting query uses a prefix handler that matches on a phrase with spaces in it. Here, user1 cannot see documents with project "Very confidential". 

<AppSecurityConfiguration enabled="true" defaultQuery="#all" defaultLevelOfDetail="0" 
xmlns="exa:com.exalead.apps.appsec" keepCloudviewSecurity="false">
    <Group name="interns" query="NOT project:&quot;Very confidential&quot;">
					 	<Login login="user1"/>
    </Group>
        <LevelsOfDetail>
 		<LevelOfDetail id="0" name="Allow all"/>
	 </LevelsOfDetail>
</AppSecurityConfiguration>