Contribute permissions vs. network permissions

[ghope]

We are currently implementing Contribute in a website that is highly
centralized, with approximately 50 department-level CT writers and 4 CT
administrators. We thought we had developed a workable deployment scheme, but
are now seeing that the Contribute architecture apparently does not provide the
degree of security we had anticipated.

We have created roles that mirror our organizational and web directory
structure, and populated those roles with writers via connection keys. We have
configured network read/write permissions for our writers in the MMWIP, _mm,
_notes and _bak folders.

After some embarrassing initial trainings, we discovered that we also need to
configure read/write permissions in both the web root and the specific
departmental subdirectories. Suddenly, we find ourselves expanding permissions
on the web server instead of constricting them as we had anticipated. We're
dumbfounded to discover that our content management system requires us to open
the door to rogue editing with Dreamweaver, Frontpage, even Notepad.

We are desparate for suggestions as to how others have addressed this
situation. Below is some relevant info on our deployment. Many thanks to anyone
who can share advice or experiences.

Contribute version: 3.1
Web server: IIS 5
Connection type: LAN

_______________________
Greg Hope
MiraCosta College
One Barnard Drive
Oceanside, CA 92056
E: ghope at miracosta dot edu
T: 760.795.6763
F: 760.795.6723

[Matt Adams]

ghope wrote:

> We are currently implementing Contribute in a website that is highly
> centralized, with approximately 50 department-level CT writers and 4 CT
> administrators. We thought we had developed a workable deployment scheme, but
> are now seeing that the Contribute architecture apparently does not provide the
> degree of security we had anticipated.
>
> We have created roles that mirror our organizational and web directory
> structure, and populated those roles with writers via connection keys. We have
> configured network read/write permissions for our writers in the MMWIP, _mm,
> _notes and _bak folders.
>
> After some embarrassing initial trainings, we discovered that we also need to
> configure read/write permissions in both the web root and the specific
> departmental subdirectories. Suddenly, we find ourselves expanding permissions
> on the web server instead of constricting them as we had anticipated. We're
> dumbfounded to discover that our content management system requires us to open
> the door to rogue editing with Dreamweaver, Frontpage, even Notepad.
>
> We are desparate for suggestions as to how others have addressed this
> situation. Below is some relevant info on our deployment. Many thanks to anyone
> who can share advice or experiences.
>
> Contribute version: 3.1
> Web server: IIS 5
> Connection type: LAN
>
> _______________________
> Greg Hope
> MiraCosta College
> One Barnard Drive
> Oceanside, CA 92056
> E: ghope at miracosta dot edu
> T: 760.795.6763
> F: 760.795.6723
>
> From - Fri

We are looking for the same answer. We are just starting to administer
Contribute 3.11 (with contribute publishing server) at a school, looking
at around 10 users now. We would like to avoid having to give a group
access to everything on our server, and would also like to know some
best practices on ftp access for users. Any suggestions would be
appreciated.

Matt Adams
District Network Specialist
Winnebago Schools

[ghope]

We did get our Contribute system up and running, and have had only a few
hiccups since then. Here are a few details. We're using sFTP, but the same
details apply if you are using FTP. We are using Active Directory, hence the
"AD" below.

Configure end user permissions on web server:
1. Revoke all active directory permissions for end users, except read and
browse.
2. Grant end users read/write/modify/delete permissions on the following
directories: _mm, _bak, _notes.

Create an administrative AD user that will be used by Contribute only:
3. Create an Contribute user with full active directory permissions for the
entire web site.
*** We used long, randomized strings for both the username and password for
this account. The only time you will need to enter these is when you are
creating an administrator connection for yourself or other admins. It's a pain,
but worth the inconvenience.
4. Give the Contribute user FTP permission.

Create the administrator connection in Contribute:
5. Create a new connection in Contribute using the administrator role.
6. Set the connection method as either FTP or sFTP.
7. The FTP (or sFTP) username and password will be those of the Contribute
user created in step 3.

Send connection keys to end users:
8. When using the Connection Key Wizard, select Yes to send your current
connection settings, and check the box to Include my FTP username and password.
*** Connection keys are encrypted, so it is safe to be passing this
username/password via this method.
9. Select the appropriate role, then finish.
10. Address the email to the desired users and send.

We created clones of the Writer role that to match our major subdirectories.
For example, we have a folder at the root named "StudentServices" and therefore
a role with that name. We could have created more granular roles that grant
editing permission at a lower level, but instead opted for fewer roles and to
simply monitor incoming drafts to confirm who they're coming from. This makes
it easier for our end users to share the work load.

Also, we have only four users with publishing permission in Contribute.
Everyone submits their drafts for publication. You may opt for department-level
publishers to reduce the load on your admins.

Hope this helps!