How To Secure Access To Technical Content

Among the new features of Fluid Topics version 2.7 release, access control is certainly the trickiest one and it deserves some clarification. Most of our clients are interested in securing access to their content. Some of the motivations and use cases for secure access include:

• Make part of the documentation publicly accessible, while the rest is limited to customers.
• Centrally expose all content related to product support, but restrict access to some content to internal users only, based on fine-grained roles and profiles such as support agents, subject matter experts, field operators, etc.
• Limit access to preview content for upcoming products to partners and resellers.
• Deliver customer-tailored documents: some content may be specific to one customer based on its product configuration.
• Make part of the content —such as training material— accessible on a subscription-based model.

Whether the need is immediate or planned for future implementation, this capability should be part of your checklist when searching for a content delivery solution. In fact, many companies choose Fluid Topics for its incredible flexibility and ability to cope with various situations.

To set up this security mechanism, clients often have to answer many questions and sometimes solve functional and technical issues. Even if Fluid Topics makes it easy, there are two issues that clients must address.

1. Understand the difference between authentication and authorization.

Authentication consists in knowing who the user is, and making sure that he is who he claims to be. This is usually achieved in the login phase with a username or email, plus password. In more demanding environments, this can be accomplished through security devices such as secure cards. To avoid forcing the user to authenticate again, Fluid Topics can connect to SSO systems and check if the user is already authenticated. Fluid Topics also supports out-of-the-box multiple standard SSO protocols —such as SAML, OpenID, OAuth— and can be extended to support proprietary protocols.

Authorization determines the permissions of authenticated users: resources they are authorized to access and features they can use. Access rights are usually modeled by a set of profiles and groups a user belongs to, and user credentials are authorized by obtaining a list of those profiles and groups. Authorization requires organizations to answer essential questions:

• What is our permission model?
• What groups, profiles or roles already exist?
• Where are groups and profiles defined and stored?
• Do groups and profiles match what we are trying to achieve in terms of content access? Or do we need to create new ones?

Example: You want to limit access to some content to your certified partners and resellers.

• Do you have such groups defined? Are you sure that the corresponding users are properly tagged as being part of those groups?
• Where is this information stored? Is it already in the directory used for access control? Or is this information managed in a separate application such as your CRM?

User credentials are usually provided as part of the SSO dialog (through SAML assertions, for example). If the group’s definition and membership exist in an application such as your ERP or CRM that is not connected to your security infrastructure, you will either have to connect these systems or expose them through a Web Service. If the credentials are already defined in the directory used also for authentication, you’re ready to go. This is an issue to investigate with your IT department.

2. Define the relationship between credentials and content attributes.

The groups and roles used for defining user credentials usually don’t match the metadata existing on the content side. This is normal, but still it’s an issue.

Content such as technical documentation is usually written in advance, independently of delivery strategy and regardless of the security mechanisms that may be put in place. This content is usually tagged (type, related product, version, tasks, audience, etc.) with some metadata put inside the content, while other metadata is defined and stored “outside” the content, such as in the CMS.

The decision to include metadata inside —when metadata are content-related and not dependent of the context— or alongside a piece of content, is very important but it is not the subject of this discussion. In both cases, metadata is usually not included in the groups used for defining user credentials, and it’s a good practice not to do so. In some cases, you may find the profiles you want to define for content access may not even exist in your directory.

Imagine that you have 10,000 topics and that you have to tag 20% of them as “partners” because they are accessible to partners. One day, marketing decides to create Silver and Gold Partnership levels. Do you think it make sense to manually modify the tagging of 2,000 topics? And by the way, the group “partner” does not exist. Instead, the CRM holds attributes such as reseller or integrator.

This is a typical situation you can resolve by mapping between the user groups and the existing metadata. Fluid Topics makes it easy to dynamically and flexibly use mapping capabilities, but you must define mapping parameters based on your system.

Remember: securing access to your content will require you to answer two questions:

• What are the existing credentials and how are they made accessible?
• How do the access groups map to the existing content metadata?