Skip to Content
This is in continuation of my two part series about content segmentation according to user profile attributes. In Part One I wrote Filtering Role Content by User Attributes. This part continues to how we achieve content segmentation for content placed in KM repositories. Again a prerequisite will be that the users’ profile attributes have been populated. This Blog will talk about KM content Segmentation based on User Profile Attributes and Meta Data Attributes attached to the documents. In terms of KM object filtering, KM provides KM APIs and the RF Framework to configure the filtering of resources upon request based on the properties of the documents residing in the Repository. This feature is accomplished by a Repository Filter. This repository filter will actually filter the list of the docs shown to the user. If the parameter matches then the user sees the doc, else the doc is removed from the list the user sees. The Repository filter is custom developed and based on the RF Framework and the KM API. You have to use UME API to check for the user profile parameters and then compare with the meta data properties of the KM doc. The Step by step flow is as follows:

  1. The Custom Repository filter is developed and deployed
  2. Meta Data attributes are created in KM and attached to all the relevant documents
  3. Repository filter is applied to the respective repositories
  4. On an incoming user request, the filter intercepts the request and talks to the repository and filters out the documents that do not match the User’s Profile Attributes. ( The filter may get the list from either the repository or the KM cache)
  5. If the attributes do not match then the resource is removed from the resource list which will be shown to the user.

Repository filter: What you have to do is build a Namespace Repository Filter, which will filter the lists of documents sent to the user upon the user visiting the repository. Most of the initial steps have been mentioned in the following weblog by Prakash Singh on implementing a namespace filter. How to create namespace filter for KM. In this web log, I will show some code on how to use the user attributes and meta data properties of KM resources for the same. Prerequisites:

  • Custom Meta Data has been defined in the CM System
  • Portal Objects are created and present with the appropriate meta data.
  • Repository Filters have been created and applied to the repositories
  • The User Profile attributes have been mapped to the UME.
  • Accessing User Profile attributes: Since this is basically a filtering out resources of the resource list shown to the user, we have to get the context from the current resource you can do that like this: “abc = currentResource.getContext();” Once we have the resource context, we need to get the user context to retrieve its properties. you can do that like this with mutable user: IUser user = abc.getUser();
    IUserMaint usermaint = userFact.getMutableUser(abc.getUser().getUMEId());
    The next step would be to retrieve the mentioned properties of the user. ( note we can do this in a string array) String functionAttrs[] = usermaint.getAttribute(<<enter user attribute namespace here>>, <<enter user attribute name here>>); Remember, the namespace is for the custom user profile attribute which you have made available in the datasource xml file. This could be standard ( com.sap.security.core.usermanagement) Accessing meta data properties Now you have retrieved the user’s profile attribute and have access to it. The Next step would be to extract the meta data property of the concerned KM resource. you have to get the property name of the meta data property in context. you can do this through: IPropertyName propNameFunction = new PropertyName(<<enter namespace for custom km metadata>>, <<enter property name of custom KM meta data property>>); e.g for custom namespace: “http://yourcompany” Next , you actually pick up the property value for the property name: IProperty propFunction = currentResource.getProperty(propNameFunction) ; Now you have both the user profile attribute and the cutom meta data property of the current resource. To see if this document is to be made visible by the user you can compare the two properties and then either filter out the doc from the resource list or let it be. To filter the document out you can use the following : workingResourceList = this.predecessorFilter.filter(); IResourceListIterator workingResourcelistIter =workingResourceList.listIterator(); workingResourcelistIter.remove(); Now you know how to retrieve the meta data properties of the KM document, the custom user profile attributes and how to remove a resource from the list. In my next Blog, I will talk about how to publish custom meta data properties for documents and custom user profile attributes.
To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Pran Bhas
    Isnt it a good idea to modify the ACL of the document to be denied to users who are not allowed to see it anyway ..
    (0) 
    1. Shantanu Garg Post author
      Hi Pran,

      I had actually tried to work this out with ACLs but it was not logical at this scenario.

      ACLs are  very good in scenarios when you can easily divide the user population into groups and the content released is intended for these groups. In my earlier blog i had mentioned that how the number of roles can increase if we go down to very very minute level of segmentation.

      Take a scenario of an organisation which has over 50K users. Now take the scenario that these users are segregated not only on the basis of organisational  groups, but  also by further segmentation within those groups.  The content here is released in terms of these smaller segmentations. E.g There is an employee in Mumbai who is of type A, whose function is services, but the status of the this employee is lets say DFX and then there is another employee with all the same attributes but a different status and then so on.

      If this segmentation is based on say, 8 attributes then creating a group according to each combination will increase the groups to a huge unmanagable number. And then Basing ACLs on these combinations would possibly result in adding those rights according to each users, or a hundred different groups. This again would be too much too handle manually and hence maybe one would need a KM service to modify the ACLs. Hence, the above solution works really well in this scenario.

      regards,
      Shantanu

      (0) 
  2. Parag Jain
    Hello Shantanu,

    This is a good workaround. Does the filter work when the repository is accessed via Search, WebFolders or Portal Drive as well ? The concern is that the security that we are trying to simulate using your concept should work in all scenarios.

    Regards,
    Parag.

    (0) 
    1. Shantanu Garg Post author
      Hi Parag,
      This works with all the technologies which uses the repository framework for displaying what you can see from within a repository. For the search example, the list displayed  is based on ACL of a user. I am not sure whether this will work as I have not tested the same, but with some tweaking it should work too.

      regards,
      Shantanu

      (0) 
    2. Shantanu Garg Post author
      Hi Parag,
      This works with all the technologies which uses the repository framework for displaying what you can see from within a repository. For the search example, the list displayed  is based on ACL of a user. I am not sure whether this will work as I have not tested the same, but with some tweaking it should work too.

      regards,
      Shantanu

      (0) 

Leave a Reply