Page tree
Skip to end of metadata
Go to start of metadata

Overview

This page describes AIE's security models and the objects that encapsulate them.

View incoming links.

Content Security Model

Content, ACL and principal processing is encapsulated by the model ContentSecurityModel . When security is enabled, the specified security model implementation enables principal security ingestion, query rewriting, and response rewriting to secure all content. The default Full Content Security Model implementation class is FullSecurityModelImpl .

The following picture is an overview of security generated workflows and components. The blue components represent those new components inserted into workflows.

ContentSecurityDataFlow

FullSecurityModelImpl

The full security implementation, FullSecurityModelImpl  handles principal and ACL ingestion, securing queries and responses. This model is generally used when your ingested files contain file system protections, and you want those protections applied to user searches of the AIE index.

This implementation automatically adds required security schema fields (names prefixed with security.) to the default AIE index. It specifies the ProcessSecureDocument  transformer for the indexer workflow, the SecureQueryTransformer  transformer for the searcherworkflow, and SecureResponseTransformer  for the defaultResponse workflow.

On startup, it ingests a special Anonymous principal used for anonymous handling of unsecured document handling. Whem the feature attribute allowUnsecuredDocuments is set to true, the unsecured documents (documents ingested without any associated ACLs), are viewable by non-authenticated, Anonymous users. The following sample feature configuration shows this property set to true.

<ff:features xmlns:ff="http://www.attivio.com/configuration/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:security="http://www.attivio.com/configuration/features/security" xsi:schemaLocation="http://www.attivio.com/configuration/config http://www.attivio.com/configuration/config.xsd http://www.attivio.com/configuration/features/security http://www.attivio.com/configuration/features/securityFeatures.xsd">
  <security:contentSecurity allowUnsecuredDocuments="true" class="com.attivio.security.model.FullSecurityModelImpl" enabled="true" name="contentSecurityTwo" secureResponseWorkflow="defaultResponseTwo" securedIndex="indexTwo" allowUpdates="false"/>
</ff:features>

The default setting for allowUnsecuredDocuments is false, This setting is recommended for most systems, as it is the most secure.

Using the Empty ACL

The default ACL for any document with no ACLs on it is the Anonymous ACL. To change this default, either feed documents with an empty ACL on them (so that only administrators can see them) using the SecurityUtils.attachAcl(doc, new AttivioAcl()) method, or else add a document transformer which adds this empty ACL to documents without security.acl fields.

FullSecurityModelImpl with Group Associations stored on the Principal

The default FullSecurityModelImpl persists group associations flexibly, by storing them as linking records between Principal users and groups. This eases user aliasing by letting you create alias associations at any point in time. However, for large numbers of user-to-group or group-to-group associations, the persistance can create many table:AIE.prinassociations records in the AIE index.

If the index size is a concern in large principal association deployments (where after-principal-ingestion user aliases are unnecessary), set the persistGroupsWithPrincipal="true" option on the contentSecurity feature before ingesting users and groups. In this mode, direct group associations reside in the index on the principal document rather than in a separate, linked document. In this mode, immediate group associations are required on ingested principals. If user aliases are desired, you must also persist those alias associations on each user's principal.

For example, to create aliases for bruce and batman in this configuration:

AttivioPrincipal bruce = new AttivioPrincipal("gotham","bruce","bruce",AttivioPrincipal.PrincipalType.USER);
AttivioPrincipal batman = new AttivioPrincipal("gotham","batman","batman",AttivioPrincipal.PrincipalType.USER);

bruce.addGroupMembership(new AttivioGroupMembership(bruce.getPrincipalKey(), batman.getPrincipalKey()));
batman.addGroupMembership(new AttivioGroupMembership(batman.getPrincipalKey(), bruce.getPrincipalKey()));

contentFeeder.feed(bruce);
contentFeeder.feed(batman);

FullSecurityModelImpl and ACL integrity with DeleteByQuery

By default, the FullSecurityModelImpl intercepts DeleteByQuery messages and modifies them to include appropriate ACL deletion for each deleted document. If this adversely impacts DeleteByQuery performance, you can disable this by setting the deleteAclsOnDeleteByQuery="false" attribute on the contentSecurity feature. Changing this default creates orphane ACLs which do not compromise security, but grow the index needlessly over time. When using this setting, creating a scheduled connector to periodically delete the orphaned ACLs is recommended.

Supporting updates of document acls

By default allowUpdates is set to false. This provides the best performance for security query evaluation. However, if you need to update ACLs for a document without refeeding the entire document, you can set allowUpdates to true. This will then allow you to use content security apis to update ACLs on a document without refeeding the entire document.

PrincipalSecurityModelImpl

Use this model when only principal data is required for ingestion.

PrincipalAndAclSecurityModelImpl

Use this model when ingesting both principal data and ACLs.  You typically use this model when no query-side filtering is desired, but ACL and principal information is needed.

Custom Security Implementations

If you require a security implementation other than those that come with the AIE Security module, contact Attivio Support.

  • No labels