Access control

From Infoglue 1.3 and forward a lot of things has changed and one of the most important things are the ways in which we now can define access rights on a much more granular level then before. Before 1.3 we had only the possibility to define what roles could have access to what tools and what repositories and that was it. In 1.3 there is a finer access system incorporated which lets you define access to all the old things but also to a number of operations on individual content items and pages etc.

Controlling access to the tools

In InfoGlue you have always had the possibility to restrict access to the different tools in Infoglue. This has not changed but now more and more things are access controlled. As the entire access model circles around interception points and interceptors it is there you do it. The operation is pretty simple. Enter the interception point you want to restrict access to by clicking on one of the registered ones. In 1.3 there should be at least these ones which control the tool access:

In 2.4.6 we have added a easies way to know what points are available. When you create new interception points you can now select all standard points. These include the all new points which controls access to the different areas in the management tool.

To assign access rights click on the tool you wish to restrict and you will see the details:

 

Now you click on the “Access Rights”-button which is marked above. The access control screen will be visible next:

Here you just mark the roles that shall have access to the function and press save. If a role has access a little icon will appear in that columns headline looking like 3 persons. This is to show that you can limit access even more by adding what groups the user also has to be part of. If you click on the icon (grey if not set before and colored otherwise) you will see a list of the groups available and can tick one or many if you wish that to be part of the restriction:

 

Repeat the same procedure for all tools in the same way. Remember that you must reload the tools to see the change if they should affect you.

Controlling access to contents

A very much wanted feature which came in 1.3 is the ability to protect contents both internal and external. Often it is important to be able to restrict which users can manage templates etc and which users are only allowed to operate on press releases etc. This is very important if you want to have a well defined process in the organization. In InfoGlue you can restrict access on a very fine level. You can not only restrict it to content but also who can do what operations on that content and its versions.

In the tools the messages are very clear when you for example try to view a content you do not have access to. It’s not as clear in the deliver part of InfoGlue. On sites the forbidden contents are just removed which can render areas of the page blank instead. This is of course so that the visitors should not be bothered about such things if not needed. Potentially there may be a lot of things not allowed for a particular user on a page and we cannot write messages to him/her about it, can we. Another person may be authorized to view them so it’s more a matter of writing the templates so they don’t fall apart if there is a lack of information.

All access handling is done from the content tool on each content. Enter into the content tool and select a content or a folder you wish to protect in some way. I have chosen to protect the “News items”-folder in the “officestand.com”-repository as an example.

This is how the container looks by default. It is important to understand how the option “Protect content” works. It is marked below and has three options:

No: Overrides any inherited protection and states that this content is not protected.
Yes: Overrides any inherited protection and states that this content is protected.
Inherited: The default option which states that access should be inherited from its parent. So if the parent content (in this case the root content) is protected so becomes this node etc.

 

Now we want to set the property to “Yes” as we want to protect the content folder. Press the “Save”-button to apply the change and you will see a new button called “Access Rights”:

 

When you press the “Access Rights”-button you will see all access rights option a content can have.

 

The things you see in the top (read, write etc) are actually the interception points which have the category suitable. As it is easy to add/delete interception points the options here can be more or fewer than today but that also requires changes in the matching code of course.

The implemented InfoGlue Interception Points are:

• Read – this has to be set for a role if the role should be able to read the content container at all including any of its versions.
• Write – this must be assigned if the role should be able to modify the content container at all.
• Create – must be set if the role should be able to create a child to this content. Only applies to folders really.
• Delete – must be set if the role should be allowed to delete this content.
• Move – must be set if the role should be allowed to move this content. Remember that the place where you wish to move it to can have restrictions which makes it forbidden. For example the role might not have rights to create content in the target folder resulting in an error message.
• SubmitToPublish – must be set if the role should be able to submit the content to publish.
• ChangeAccessRights – essentially restricts which users can enter this screen and modify these settings.
• CreateVersion – decides who can create a new version of a content. Good if you especially don’t want language versions of some kind.

Warning:
A very important thing to remember is that InfoGlue now sees external and internal access about the same way. That is – if you protect a content you do it not only in the tools but also on the extranet, intranet or public site as well. What this means is that if you protect a content you have to set up external users as authorized as well if you still want them to be able to access it. A typical example is that if you have a public site and want ordinary people, who have not logged on anywhere, visiting your website being able to see your protected content you have to give the role “anonymous” read-access. All users who have not authenticated themselves always operate as anonymous.
Controlling access to pages / SiteNodes
As for contents you can protect items in the structure-tool as well both internally and externally. Often it is important to be able to restrict what users can manage what areas of the site in the tools. This is very important if you want to have a well defined process in the organization. In InfoGlue 1.3 you can restrict access on a very fine level. You can not only restrict it to pages/site nodes but also who can do what operations on that page.

Also – as before it is often of interest to be able to restrict access to part of your public website or intranet as well. The typical example is an extranet site you only reach after logging in from the ordinary site.

All access handling is done from the structure tool on each page. Enter into the content tool and select a page you wish to protect in some way. I have chosen to protect the “News page”-site node in the “officestand.com”-repository as an example.

This is how the container looks by default. It is important to understand how the option “Protect site node” works. It is marked below and has three options:

No: Overrides any inherited protection and states that this page is not protected.
Yes: Overrides any inherited protection and states that this page is protected.
Inherited: The default option which states that access should be inherited from its parent. So if the parent page (in this case the root page) is protected - so becomes this node etc.

 

Now we want to set the property to “Yes” as we want to protect the page. Press the “Save”-button to apply the change and you will see a new button called “Access Rights”:

 

When you press the “Access Rights”-button you will see all access rights option a page can have.

 

The things you see in the top (read, write etc) are actually the interception points which have the category suitable. As it is easy to add/delete interception points the options here can be more or fewer than today but that also requires changes in the matching code of course.

The implemented InfoGlue Interception Points for a site node are:

• Read – this has to be set for a role if the role should be able to read the page container at all including any of its versions.
• Write – this must be assigned if the role should be able to modify the site node container at all.
• CreateSiteNode – must be set if the role should be able to create a child to this site node.
• DeleteSiteNode – must be set if the role should be allowed to delete this site node.
• MoveSiteNode – must be set if the role should be allowed to move this site node. Remember that the place where you wish to move it to can have restrictions which makes it forbidden. For example the role might not have rights to create a page in the target folder resulting in an error message.
• SubmitToPublish – must be set if the role should be able to submit the page to publish.
• ChangeAccessRights – essentially restricts which users can enter this screen and modify these settings.
• Publish – Decides who can publish this page.

Warning:
A very important thing to remember is that InfoGlue now sees external and internal access about the same way. That is – if you protect a site node/page you do it not only in the tools but also on the extranet, intranet or public site as well. What this means is that if you protect a page you have to set up external users as authorized as well if you still want them to be able to access it. A typical example is that if you have a public site and want ordinary people, who have not logged on anywhere, visiting your website being able to see your protected page you have to give the role “anonymous” read-access. All users who have not authenticated themselves always operate as anonymous.