Discuss security requirements after page level permissions
Page level permissions support has been an important addition for Confluence. What additional security requirements are there? What additional support can be added?
Page level permission by list of users or list of groups
Page level permission allows restriction to a single user (myself) or a single administrator defined group. We need the ability to allow a page to be viewed by a user defined list of users and/or groups.
See CONF-3701.
Restrict source view
Even if the user does not have edit capability, the user has the view source capability from the INFO tab. While this is a useful capability, we need to restrict access to viewing the source on some pages. For example, sometimes page source contains passwords.
Search engine indexing
Related to the above, the original page text is used when being indexed into the search engine. It would be nice if there was some way to index the final result of the page instead of the original source. One problem is that pages look different to different people at different times (eg latest news, etc), so how do you determine what is 'current'? If macros could detect that it was the search engine rendering the page, they could blank the data, or provide more data, or just keywords, if appropriate.
Restrict macro use
This is a more difficult one. Some powerful macros are available that provide some very useful content and capabilities. For example, some of the Java scripting , [other scripting], SQL, and [HTML| macros. However, in a lot of cases, these capabilities need to be reserved for trusted users while still allowing untrusted users the ability to view the content created with these macros. How could this be accomplished without making it too complicated to implement and administer?
Allow specific macro capabilities for trusted users
Scenario
Administrator needs to restrict macros that have powerful capabilities to certain trusted users. In some cases, some macro options need to be further restricted while allowing other other options to be used by a broader set of people. For example, the SQL macro allows access to JNDI defined databases in the server and the administrator needs to prevent access to use of some of these data sources while allowing access to others. In this case, the administrator does not want to grant access to the Confluence data source to anyone other than confluence administrators.
Note that the administrator only wants to prevent untrusted users from editing or creating pages that use the resticted cababilities but not prevent any user from viewing data on such pages or from those pages being included in other pages.
Proposal
- Define a property file (or similar) that has keys made of of macro names plus additional qualifiers and corresponding list of users or groups or both. To simplify, a single group could get us started.
- Each protected macro would have to implement checking a common function that validates that the macro usages is on a page that is restricted to the appropriate group or users.
- This ensures that only pages that are edit capable by trusted users can be viewed (have the macro executed)
- Can an untrusted users create a page and then restrict editing to an trusted user?
- This looks like it is restricted in the current implementation (goodness!), otherwise further checks would have to be made to ensure the last modifier was a trusted user
- Example properties
html = confluence-administrators script = trusted-script-writers sql = sql-developers sql.ds.ConfluenceDS = confluence-administrators sql.ds.TestDS = test-team
- HTML macro is only enabled on pages that can be modified by confluence-administrators
- script macro is only enabled on pages that can be modified by trusted-script-writers
- sql macro is only enabled on pages that can be modified by sql-developers
- sql macro using the ConfluenceDS datasource is only enabled on pages that can be modified by confluence-administrators
- sql macro using the TestDS datasource is only enabled on pages that can be modified by test-team
 | Beta implementation An implementation like the above proposal is available with 1.7 release of Scripting and External Content Macros. |
Comments (26)
Nov 21, 2005
Guy Fraser says:
If there was a decorator=searchEngine parameter, it would be easy for macros to ...If there was a decorator=searchEngine parameter, it would be easy for macros to blank out information. It would be especially useful if this was presented when external search engines (such as google) scan the site.
Heartily agree with more flexible macro permissions. It would be nice if there was the ability to restrict macros to certain contexts - eg. a macro could be desirable in pages and blogposts, but not comments or the site welcome message. Another macro might only be desirable in user profiles.
Also, has anyone tested whether macros can be used in page update comments?
Nov 21, 2005
Bob Swift says:
It is not sufficient to have the macro run but not show the data. The running o...It is not sufficient to have the macro run but not show the data. The running of the macro itself could be bad.
Nov 21, 2005
David Peterson [CustomWare] says:
I think a simpler way would be to have macros restricted by space, rather than b...I think a simpler way would be to have macros restricted by space, rather than by user/group. Testing by the user's permissions would be difficult at best, and probably quite inefficient algorithmically. Other than viewing/editing pages, other restrictions are by space, and I think this would be a good place to put macro restrictions also.
Nov 21, 2005
Guy Fraser says:
It would be much simpler from an admin's point of view to have a list of spaces ...It would be much simpler from an admin's point of view to have a list of spaces and contexts and just tick the ones where the macro can be used.
At a later date, the more granular (and complex / processor intensive) users / groups permissions could be added?
Nov 21, 2005
Bob Swift says:
It is not a space problem, it is a data and system access problem. It doesn't m...It is not a space problem, it is a data and system access problem. It doesn't matter what space they are using a macro from, it is the things they can do with SQL, or HTML or java code that needs to be prevented. For instance, enabling the SQL macro allows access to ALL confluence data no matter what Confluence application restrictions are in place! Same for allowing people to write and run any java code on the server!
Nov 21, 2005
David Peterson [CustomWare] says:
Sure - but you can manage that by only allowing those more dangerous macros to b...Sure - but you can manage that by only allowing those more dangerous macros to be run in specific spaces. Spaces which are only editable by people who you trust to use that power.
I just think that checking that all users who have permission to edit a page also have permission to run each particular macro is going to be a) hard to wrap your head around and b) extremely inefficient. IMHO restricting by space is the simpler solution, and still allows enough flexibility to cover 95% of situations.
Any examples to the contrary are most welcome
Nov 21, 2005
Bob Swift says:
Good discussion! What you say is probably true, but, I still need to be able to...Good discussion! What you say is probably true, but, I still need to be able to have dynamic content delivered to all users and restrict who can create and edit that same content. I also need the content to be delivered where it makes most sense - namely, in a page or space that is appropriate for the content. For example, if we dynamically generate a chart reporting on test progress - it needs to be on a page and in a space related to testing along with all the other testing content. So, lets explore the option of having restricted macros able to produce content only if they are on a page in a specific space. For instance, the sql macro can only use the ConfluenceDS data source if it is on a page in a space with id sqlconfluenceds. Only confluence-administrators can edit pages in this space, but other users have view access. In a page in another space, I need to be able to include the contents of the restricted space and have it viewed appropriately. Unfortunately the include macro doesn't work across spaces but I assume that could be fixed. So, this could work. Administratively, its a pain to create multiple spaces and adminstrate the permissions to match where pages may need to be viewed. For instance if I have dynamic content that only people authorized to the TEST space can see, then I need to create a TESTsql space with the same view permissions. And similarly for the XXX product space and the YYY space. Another negative is users of those space will see extra spaces that really aren't needed by them other that to support viewing of this dynamic content.
Nov 21, 2005
Guy Fraser says:
Spaces / Context control would be a useful first step. For example, you'd be abl...Spaces / Context control would be a useful first step. For example, you'd be able to restrict the macros from publically accessible spaces - not perfect (users / groups would still be needed sooner or later), but better than not having any restrictions at all.
Would user/group restrictions be based on adding the macro to a page or viewing it on a page? If they restrict adding it, how would that be implemented?
Picking up on the main post above, being able to remove old versions of pages, attachments and blogposts would also be very desirable (as much if not more than removing access to them). It would allow the removal of old and unwanted informtion thus making the remaining information easier to manage. Search engines should not get to see the page source or any of the revision history IMHO.
If the page/blogpost info tab was actually a page-like CEO, macros could be added to it to completely customise it's display and things like the {show-to} and {hide-from} macros could be used as a simple way of showing additional information or restricting access to bits of the info tab output
Nov 21, 2005
David Peterson [CustomWare] says:
A meta page about pages? I can hear people at Atlassian losing consiousness from...A meta page about pages? I can hear people at Atlassian losing consiousness from here...
However, it could act more like a template/decorator - except that it allows macros in the content. That is, a global (or maybe space-wide) 'page' is editable, and that one page applies to all pages in the server/space...
Not sure whether the time/usefulness ratio is high enough though...
Nov 21, 2005
Guy Fraser says:
Ah, yes, it's always good to make some developers loose conciousness (we so nee...Ah, yes, it's always good to make some developers loose conciousness
(we so need an evil grin smiley adding to Confluence).
As a general concept it would rock IMHO. This would make customisation of key parts of Confluence far easier - just as easy as editing pages.
The left nav theme already allows a page to be included in the left nav bar for customisation so it's not that much of a stretch of the imagination to see this technique being extended to other areas.
Some examples:
Think of having the dashboard as such an entity - not only would you be able to use the dashboard macros all over the place (currently there are limited versions of them for use elsewhere) but the customisation level could be taken to a whole new level without the need to start editing the VM templates. At present the most we can do without resorting to a VM edit is alter the site welcome message.
Imagine things like the Advanced tab and the Pages tab being customisable. Mmmm, tasty goodness!
Anyway, as we're veering wildly off subject here I'll shut up and climb back under my rock in foggy Manchester, UK.
Nov 29, 2005
Daniel Ostermeier says:
We have just had a quick chat internally about this, with the following conclusi...We have just had a quick chat internally about this, with the following conclusions: (these mirror what bob has said in his post above if im not mistaken.)
We are presently considering including some of the management that is available at the global level to the space level. Amongst this would be the ability to manage macros on a per space basis. So, in the context of these comments, if you wanted to restrict access to a macro, then you would do so via the space edit/view permissions. That is, you enable the restricted macro in a space that can only be edited by the authorised users. If you wanted some of this restricted macro content to be available to other spaces, you would need to use the include page functionality.
This appears to be the cleanest / most direct / achievable solution to this problem.
Thoughts?
Nov 29, 2005
David Peterson [CustomWare] says:
This sounds like a reasonable solution to me. +1This sounds like a reasonable solution to me. +1
Nov 29, 2005
Guy Fraser says:
++ Nice idea about the "include" page functionality! That does make it far clean...++ Nice idea about the "include" page functionality! That does make it far cleaner - still easy to use and flexible enough for most needs
Nov 29, 2005
Bob Swift says:
I agree this sounds like the cleanest solution, but it still introduces signific...I agree this sounds like the cleanest solution, but it still introduces significant administrative problems for any sophisticated installation. For example, I have 25 spaces each with separate authorities and with authority management delegated to the space owner. Today, security risk macros are only used in a handful of these spaces but that will increase over time. For each space that I needed to use restricted macros in, I would need to create a new space with view authorities exactly matching the original space and with edit authorities restricted to the trusted users for that space. Then the 2 spaces authorities would have to be maintained, one by the original space owner and the other by a trusted administrator - this is a significant coordination problem. Multiple this by 25 spaces. It gets worse when you think of having trusted users for certain capabilities, but not for others. I will give more users sql capabilities with certain data sources than I will give sql capabilities with more powerful data sources and even fewer users will have access to java scripting capabilities. So the number of spaces multiplies and maintaining authorities across spaces becomes very complex. I theory, I would need 100 spaces to implement the levels discussed above for all spaces.
So, I go back to using page level permissions as a way out of the administration problem. Groups are defined for various trusted capabilities and page content containing restricted capabilities can only be edited by users in trusted groups.
Nov 29, 2005
Guy Fraser says:
Hmmm.. Yes, I can see how the scaling issue would cause a problem. Would it be ...Hmmm.. Yes, I can see how the scaling issue would cause a problem. Would it be possible to create a space for each "security restricted" plugin, then just give people access to that space who you want to be able to use the plugin?
Eg. You could create an SQL group and a JavaScript group, give them edit access in the relevant spaces and then add users to them who you want to be able to use those plugins - that way you could instantly see who can do what
Next logical question - how many users do you have?
Nov 29, 2005
Bob Swift says:
Guy, the problem is that the content viewers must have view access to the space ...Guy, the problem is that the content viewers must have view access to the space that has the security restricted plugin. This is so, even if the include macro is used. The view access must be specific to the content that is being delivered which may be different on a page by page basis. Current page permissions don't give you the granularity to manage this today. Although, here is an idea - allow page permission for a page to specify a space name in addition to users and groups. Specifying a space name on a page would allow anybody with space access rights to access the page. I don't see this as being useful outside of this particular case and I am not sure I even like the idea!
We have about 150 users currently.
Nov 29, 2005
David Peterson [CustomWare] says:
I think the way to approach this is to have macros secure themselves, rather tha...I think the way to approach this is to have macros secure themselves, rather than trying to turn the renderer into the traffic cop.
Take the SQL macro for example. Even if there were page-level permissions saying who can and can't edit a page which contains it, I don't see how that helps to secure data sources. The sql macro is going to have to check a permission database someplace anyway to see if the page editors can access that data to begin with. So, you already have permission checking code in sql macro. I don't see how you could create a page/user/group system within Confluence that would be flexible enough to handle a myriad of 'dangerous' macros and not become insanely complex, both from a developer and user point of view.
Instead, macros should do their own permission checking. Most of my macros already do that. In the case of the sql macro, here is what I would suggest, assuming that Space-level macro disabling is added:
Atlassian could provide a couple of methods to make the user/permission list comparison easier.
Nov 29, 2005
Guy Fraser says:
One other thing that would help a lot - not just for security - would be a stand...One other thing that would help a lot - not just for security - would be a standard mechanism for configuring macros. For example, the {html-tag} macro has whitelists and it would be useful to allow admins to configure the white lists on a space by space basis. The various macros in David's composition plugin would also benefit from a configuration screen - eg. you could create profiles for different styles of deck/card macros. A standardised interface for configuring macros would make it easier for the admins to understand as everything would be done in a similar fashion rather than requiring macro developers to create numerous proprietary alternatives.
Nov 29, 2005
David Peterson [CustomWare] says:
Vote here: CONF-4273Vote here: CONF-4273
Nov 29, 2005
Bob Swift says:
Yes, totally agree. The plugin must do the security check according to its inter...Yes, totally agree. The plugin must do the security check according to its internal information about parameters, etc... In fact, that is what I was intending to do for the sql and scripting macros. What we need from Atlassian is a consistent and recommended way for plugins to implement this and appropriate enabler methods to make it easier and perform well. My research so far indicates the a simple page edit permission by group can work but I don't have an implementation. I think a simple properties file approach is sufficient at least for now.
Jan 15, 2006
Guy Fraser says:
See http://jira.atlassian.com/browse/CONF-5186 - could "Space Channels" help wit...See http://jira.atlassian.com/browse/CONF-5186 - could "Space Channels" help with some of the more granular/scoped security requirements?
Apr 05, 2006
Matthew Smith says:
What about some kind of macro encapsulation? You enable a space with permission...What about some kind of macro encapsulation? You enable a space with permissions to use various macros. Developers create their macros there, then assign them an alias. Then the alias is what you put into the target page's wikimarkup.
so in your space 'HTMLMacroDev' create a page 'MyMacro' that contains:
\{html} do something interesting in here... \{html\}then in the target page in the 'User' space you put;
{secure-macro:space=HTMLMacroDev|name=MyMacro}General users could still delete the macro, but they couldn't edit it.
So if Atlassian provides the ability to enable macros on a per space basis while still allowing rendered content to work across spaces (that is, HTML macro enabled in 'HTMLMacroDev' space, but not 'User' space, but the
That doesn't solve the issue of access to specific datasources in the sql macro, but that should really be handled by the macro anyway. It's really beyond the scope of what Confluence should handle, IMO.
So all you need to worry about is the view permissions across spaces.
You might need a
Apr 05, 2006
Guy Fraser says:
In Confluence 2.2 plugins (and their macro modules, etc) have a "configure" link...In Confluence 2.2 plugins (and their macro modules, etc) have a "configure" link which should allow plugin authors to start implementing per-space security features for macros. I believe that Bob Swift has already added some features like this to the "Scripting and External Content Macros" although settings are not easily editable at present (I think you have to edit a file in the jar).
http://confluence.atlassian.com/display/CONFEXT/Scripting+and+External+Content+Macros
Regarding what you describe above, have you seen David Peterson's "Perimeter Plugin"? It allows content from a secure space to be viewed in another space in a read-only fashion:
http://www.randombits.org/display/CONF/Perimeter+Plugin
Apr 05, 2006
Bob Swift says:
The macro security implementation in the scripting plugin requires a properties ...The macro security implementation in the scripting plugin requires a properties file to be edited and it looks like it would be possible with 2.2 to make the interface nicer. That can be combined with David's {secure-include} macro to do something similar to what you are thinking. Generally speaking it is much harder for content providers to have to worry about multiple pages that are linked together in order to provide a page, but there are times where that would be a better solution as well.
Dec 04, 2006
Jean Marois says:
Has anyone tried assigning an LDAP group? Didn't work for me.Has anyone tried assigning an LDAP group? Didn't work for me.
Dec 05, 2006
Bob Swift says:
I haven't tried that. I will check. Create an SCRP issue please.I haven't tried that. I will check. Create an SCRP issue please.