Some connectors do not extract security by default.
For most connectors there are only two things required for security:
It must write the security type to the IDX file.
It must write an ACL for that security type to the IDX file.
An example in an IDX file might be:
#DREFIELD SECURITYTYPE="nt" #DREFIELD AUTONOMYMETADATA="0:U:9uz4+eLj4uD08efs/uLj4fA:G::NU::NG:"
The format of the ACL (in the AUTONOMYMETADATA field above) depends on the security type. A common format of ACL is:
global access flag:U:positive users CSV:G:positive groups CSV:NU:negative users CSV:NG:negatives groups CSV:
In the general case, the global access flag is 0 and a user is granted rights if:
their username appears in the positive users or they are member of a group in the positive groups
their username does not appear in the negative users and they are not a member of any groups in the negative groups.
If the global access flag is 1 then a user is granted rights if:
their username does not appear in the negative users and they are not a member of any groups in the negative groups.
Each of the comma-separated values in the ACL must have each of its terms encrypted . So,
DOMAIN\person1,DOMAIN\person2
becomes:
9uz4+eLj4uD08d3I397Cw5zw,9uz4+eLj4uD08d3I397Cw5/w
Only the values in the comma-separated list are encrypted, and not the commas.
For troubleshooting, you can set EncryptACLEntries to False in the connector to leave the ACLs unencrypted. This allows you check that the metadata that the connector produces has the expected ACL. However, you cannot use this unencrypted security information in the Content component index.
The actual text string that you use for the security type is not important. You must configure a field process in IDOL Server to configure it to recognize the value in the SECURITYTYPE field and apply the correct security type. This process is explained in the next section.
|
|