Knowledge Management

Get Involved. Join the Conversation.

Topic

    Cosimo Galasso
    Segregate KA access through APIAnswered
    Topic posted October 29, 2019 by Cosimo GalassoGold Medal: 3,500+ Points, tagged Knowledge Advanced 
    28 Views, 4 Comments
    Title:
    Segregate KA access through API
    Summary:
    I'm looking for a way to segregate KA access using the Rest API.
    Content:

    Hello Experts

    We are planning to use KA and give access to it's functionality to different groups of people through the KA Rest API.

    I read the KA documentation and I find out that this can be possibly done using views.

    I have an OSvC site with 9 different interfaces with the same locale/language, so I created 9 different views.

    Now my question is the following:

    Is it possible to give access to each group of user only to a specific interface/view through the REST API?

    I have tried to create separate Console Users and give access to each Console User to a specific view, but when a use the REST API (authenticating as a Console User) and query for Content i can see the Content of each View, not only the one associate with the Console User.

    CG

    Best Comment

    James Carstairs

    Sorry, I should have included this in the above.  I will amend this and make this clearer.

    This view access you highlight is for authoring purposes only.  It has nothing to do with the viewing of articles in the Customer Portal or Agent Desktop Search.  You will still need to secure your content by user group.

    (sorry for some reason the comment was duplicated so I deleted it and it deleted both!!! :-)  added back in )

    Comment

     

    • Cosimo Galasso

      Thanks for your support

      I would like to restrict both the authoring and the search, and possibly I would like to share the same Content Type and don't duplicate it for each group of users.

      I have found out that the Console User can be given explicit access to a view (see the attached image).

      So I was expecting that this will control the access to the articles based the association between the Console User and the View, both for the authoring and searching. If not what this association is used for?

      So as you mentioned it does not work as I was thinking, and the only way is to play with content type for the authoring and the user group for the searching?

      CG

       

    • James Carstairs

      You can achieve what you want with the correct setup/configuration and an understanding of how interfaces work.

      REST API works off 2 authentications

      1 - the REST API user (controls access to the apis - not content)

      2 - the ACTUAL user performing the action (controls access to the content)

      Each of these are setup differently, but neither is given explicit access to an interface as this is inherited based on the ACTUAL users access and the content itself.

      If you are restricting authoring you do this by controlling access to the content_types and the views.

      If you are restricting search/browse you do this by controlling access with user groups (web roles for customers) and these are associated to users and to content.

      Anything not secured by a user group will be visible across all interfaces (eg. it's public) depending on how the query is issued.  Keep in mind an interface also has a locale associated to it so don't forget to take that into consideration in your actions.

      Completely separately, and nothing to do with knowledge advanced, you can control access to an interface with id address range access/blocking (and a few other methods).  From what you are asking I don't think this is what you will need to do, but it's an option if tighter security is required.

    • James Carstairs

      Sorry, I should have included this in the above.  I will amend this and make this clearer.

      This view access you highlight is for authoring purposes only.  It has nothing to do with the viewing of articles in the Customer Portal or Agent Desktop Search.  You will still need to secure your content by user group.

      (sorry for some reason the comment was duplicated so I deleted it and it deleted both!!! :-)  added back in )

    • Anthony Smith

      You may have already considered this, but incase you haven't - by restricting access to content based on interface you may be removing opportunities to single-source content, whether it's the same piece of content that applies to 2 or more interfaces, or the interfaces share part of the content and the rest of the content is conditional.

      From experience, even if the interfaces relate to separate branches of the organisation - by managing content in silos you usually end up with a decent amount of duplication and the standard of content/writing will vary greatly. We normally approach this by looking at the content processes, even such basics as "search for content before creating new" make a big difference, if you combine that with continuous improvement you might find that by having your writers across all content will help with the content accuracy, consistency and low amount of duplication.