iCM security operates in a hierarchical way. That is, if a "parent" item is secured, all items beneath that parent will also be secured. Similarly, if you create nested groups of site users (that is, a group within another group) the child group will have access to everything the parent group can see.
Article Security
In the article tree below, the "My Staff Area" article has been secured. Only users who are members of the groups added to the security tab of that article will be able to access it. This restriction is also inherited by all of the articles beneath the secure article.
Should a user try to access any article in the staff area, they will first be redirected to your site's login article. Once they have logged in they will be redirected back to the content they were trying to access. Then, one of two things will happen. If they are a member of one of the user groups this content is secured to, they will be able to view the article they were trying to access. If they are not a member of a valid user group, they'll receive a warning message and be prevented from seeing any secure content. This warning message can often be content managed - see the documentation for your website for more information.
It is possible to create multiple levels of security. In the screenshot above "Staff Page 1" could be secured to a different security group (if it were it would also have a padlock icon). That would mean a normal staff user would be able to see pages in the staff area, but not "Staff Page 1". To access "Staff Page 1" a user would also have to be a member of whatever group that page was secured to.
When considering article security it is important not to secure your site's login article. If the login article were secured, no one would be able to access it or be able to login.
Media Security
Media security works in a similar way to article security. However, rather than securing individual media items, security is applied to the group a media item is in.
Users attempting to navigate directly to a secure media item, perhaps if they were sent a link to it, would be prompted to log in, then be redirected to the secure item. as with articles, the user will then either be able to see the item, or receive a warning message, depending on whether they are in a valid user group or not.
If an article included secure media items, users would only be able to see the media if they were members of the site user groups the media was secured to. This allows to you create an article that will display different media items (with each item secured to a different group) depending upon the user viewing the article.
Nested User Groups
Site user groups can be nested, one beneath the other.
Users in child groups are able to access all of the content secured to their parent groups. They are, in effect, members of the parent group.
For example, the user TIMG2 above will be able to see all content secured to either the SECURED or EVEN MORE SECURE user groups. The user TIMG will only be able to see content secured to the SECURED group and not anything secured to the EVEN MORE SECURE group.
Users and groups can be added to more than one group, inheriting content access from multiple parents.
This allows you to create highly granular levels of security access, with users in the lower-level groups inheriting access to top-level content.
A Note on the Anonymous User
Every active process in the GOSS Workflow engine must be linked to a user who initiated the process. In the majority of cases this will be a logged-in, registered, website user.
However, there are times when a process may need to be started by a user who is not logged in. The new user registration process is a good example. This means that we need some form of registered user that can handle the requests of site users before they complete the registration process. That user is the "anonymous user".
The anonymous user is set up in a similar way to any other site user in iCM, often a member of a group called PUBLICONLY. The ID of the anonymous user is then added to the Subsite Configuration. Every visitor to the subsite (who is not logged in) is treated as this anonymous user.
The public user group means you can create some interesting security configurations. Securing an article to the PUBLICONLY group would let everyone see it when they are not logged in, but would hide it from users who are logged in. This is most commonly used on the site registration page, where you wouldn't want logged in users to be able to register again.
Share this page
