Security in the publication library
Security in the publication library functions the same way. The structure of a Hyper.Net publication, however, puts a new spin on the security issue. To be specific, a Hyper.Net publication is a collection of document renditions in various formats. Each rendition is represented by one or more Topics. Each Topic is represented as a SharePoint folder. The Topic itself is represented by topic.aspx within the Topic folder. This means:
| |
· |
For any given topic, security is handled by SharePoint at the point of entry to the Topic: topic.aspx
|
| |
· |
SharePoint’s security model functions with the topic.aspx document in the Topic folder the same way it functions for any other document (including inheritance)
|
| |
· |
To create special permissions for any given publication, you need to edit the permissions (using the standard SharePoint approach) for every topic.aspx document in every Topic folder in every renditions belonging to the publication.
|
Your response to the last bullet might be: “That’s clearly the correct approach in SharePoint, but it would be a crazy amount of work and is therefore a load of nonsense. It’s an unworkable solution.”
Indeed, if you tried doing this by hand or tried to maintain it programmatically, you would be right. Hyper.Net, however, will take care of this for you as an integrated part of the transformation process—and the solution is graceful.
To implement reader security for publications, follow these steps:
| |
|
|
|
Step
|
|
1
|
Go to a desired content type in your document library and create a new property with the information type Person or Group. Here we've created a property named MyPublicationReaders. Further down on the page, we've selected a group for the property and have entered a description:
|
|
2
|
Locate the file WssFieldMapping.xml in your HyperNet folder on the file system of your Hyper.Net Transformation Server (for example, c:\Program \Files\HyperNet) and open it in a text editor or in Visual Studio.
|
|
3
|
Locate the entry for Publication_Readers. Modify it as follows and save the file:
<Publication_Readers DmsFieldname="MyPublicationReaders"/>
|
| |
|
|
Note
|
Remember that the changes will not take effect until you actually check-in a document with your security property populated and allow it to publish via Hyper.Net.
The only way to change the security access for a Hyper.Net publication using this approach is to modify the property's value on the document profile in the document library and allow the document to re-publish. We recommend enabling check-in/check-out and versioning for content types when you are using security properties, as this creates an audit trail that allows your organization to track changes to access privileges.
|
Hyper.Net will now automatically map the rights defined for the property on the document profile in the document library into the permissions for all topics of all renditions associated with the document's publication. These rights will thus be immediately in effect within the publication library. Specifically:
| |
· |
Users and groups who were not defined in the property when the document was saved in the document library will not be able to see the publication or any of its renditions in the publication.
|
| |
· |
Neither the publication nor any of its components will be visible in any views or navigation elements
|
| |
· |
SharePoint will prevent the document from being selected for usage by any unauthorized end-user
|
To modify publication reader security, a document author need only modify the property on the document profile in the document library. Hyper.Net will automatically update the new security settings in the publication during the transformation process.
If you need to implement specialized security settings, the following tips may be helpful:
| |
· |
When Hyper.Net publishes permissions into Topics in the publication library, it performs these steps for each Topic:
|
| |
o |
Delete all persons and groups who do not have full access
|
| |
o |
Retain all persons and groups who have full access (example: Administrators)
|
| |
o |
Delete all other inherited persons and groups
|
| |
o |
Insert all persons and groups defined by the field-mapped security field (example: MyPublicationReaders)
|
| |
· |
You can control the inheritance of persons and groups having full access by adding them or removing them from the inheritance hierarchy in the publication library.
|
| |
· |
You can programmatically compute the value of MyPublicationReaders at the time the document is saved. The computation could, for example, look up valid values for the property (allowing you to hide the property from authors) or could automatically add specific users to the property's value. This is a useful technique when you wish to eliminate full access from the inheritance hierarchy in the publication library but still allow full access based on document, content type, category and the like.
|