Idea Details

Federated Search by Role Tenancy Permissions

Last activity 10 days ago
Anon Anon's profile image
09-03-2015 07:03 PM

Currently the search results returned by the federated search adapter will filter results from sharepoint based on the contacts tenant (including public results also).

 

This differs from EBR search functionality in a number of ways:

 

1] Generally access to data in SDM is based on the tenant read permissions associated with the contacts active role and not the contacts tenant. In a multi tenanted system agents will have multiple roles or roles with permissions to view multiple tenants so they can manage the creation of tickets for a number of customers. Where federated search restricts these users to tenants associated with their contacts tenant this restricts their ability to make use of tenanted knowledge when dealing with end users.

2] Knowledge can be further restricted by group membership - federated search does not filter based on this additional permission constraint and therefore the user will have results returned only to find they do not have the permissions to view when they click on the  link.

 

This functionality should be enhanced to make it more usable by implementing similar access controls for knowledge and other objects types as is found in standard SDM search functionality.


Comments

01-11-2018 12:29 PM

Dear Community,

 

We would like to know if anyone has looked into and/or tried the new Research Tool feature that was delivered with xFlow. 

 

The Research Tool provides an alternate method to search for information across internet/intranet sites to help resolve a ticket. This feature does not require any adaptor/connector configuration - only the install of the browser add-in. With the way this feature works, permissions/security access to a website (Sharepoint or others) will then be handled directly by that application/network security configuration. Additionally, the Research Tool allows user to easily navigate a variety of knowledge sources and capture information (URL, text, screenshot) to be included in the resolution process for the ticket.

 

We look forward to your feedback.

 

Regards,

Carol Piccus

11-08-2015 09:09 PM

Hi,

 

I would like to comment in operational point of view.

We have not been able to provide Knowledge Search function in Japanese after upgrading our SDM to 12.9, as the federated search result for attachments does not include tenancy information and treated them as Public.

 

Actions to solve the issue would be very much appreciated.

10-02-2015 01:36 PM

Hi Russell,

 

You did a fine job of blowing way past my technical depth with your response.

 

I will have to take this back to the folks that have a deeper understanding of how the crawler works to get a better understanding of the impact of the use case that you are describing.

-Dale

10-02-2015 01:24 PM

Dale, Thanks for the reply - it is much appreciated and I can see where you are coming from. To be honest I am less worried about the application of the group based rules against the search results because the security permissions will stop users from accessing the detail. The main issue we have is that the federated search does allow documents to be filtered based on the CASDMTENANT managed schema property relating to the crawled data. The issue is that it is filtering based on the currently logged in users tenant instead of using the tenant read rules applied to the users current role. This means that where we have desk staff in the service provider tenant, all they can see is the knowledge for the service provider tenant and not the customers. So this poses us with a problem. Do we duplicate all customer knowledge in the SP tenant? Given that you are already filtering on the CASDMTENANT then it shouldn't be that difficult to extend this to filter on the tenants readable by the active role the user is currently using.

 

Given that CA removed the ability to use multi-language search with the removal of the FAST-ESP integration and that the combination of Crawler Surface and Federated Search was intended to help fill the gap in the functionality as a result of removing the FAST-ESP option then I would expect it to operate in a similar way. I guess the other option might be to look at custom adapters but I am not sure where the tenancy filter is being finally applied. CA backend or Search Adapter. For other data sources I assume the CASDMTENANT property is not specified (i.e. is blank in the index) and therefore the content is considered to be public and would be returned in any search results where applicable. This is also true if the crawled property has not been mapped to a managed one.

10-02-2015 01:10 PM

While I agree with the intent of enhancing the federated search, I am a bit concerned about the practicality of some of the suggestions. Essentially, the federated search provides search results across several different search engines, each with their own independent security models. Attempting to apply the SDM security definitions to the result sets of those external repositories would require some pretty broad assumptions about how elements like groups and tenants would map to these external systems. That would probably cause filtering out items that might otherwise be available to the user in the context of the external system. We can look into this, but to me it feels like this is one of those areas that we could sink a lot of time and energy and only come out with a marginal improvement.

-Dale