Static Files - Manging Access with Portal Security

This method would require that we create a listener so that the file upload places the file into the correct placement path and a servlet to stream the file when access thru the portal display. Has anyone done anything like this? If yes, what size effort was it?

Are there other suggestions for managing secured static files? We also looked at placing the secondary doc root on the web server but then we would have to manage with a different security model. We use WEM 8.1 and Portal 8.1.1

Find more posts tagged with

Comments

Francisco_Chicharro

Hi,

The way I usually implement this kind of requirements is creating a deployment type in WEM (using the config console), called for instance "Secured files". When you upload or edit static file in WEM, you can assign a deployment type to it. For files that are considered secured, users would assign them the new deployment type "Secured Files".

Then you would create a new deployment agent in the application server host, create a docroot resource in config console setting the path to the folder where you want to copy secured files, and subscribe the deployment agent to the static files of "secured files" deployment type, setting the resource you've just created as docroot for deployment.

Once you have the files in the application server host, if you want to secure them using Portal groups, probably the best option would be to create a Secondary Page in Portal to run the secure logic and serve the file. Keep in mind that you won't have access from the portal context to the DPM one, therefore you won't be able to use the DPM API to get the file placement path from the ID. There are two options here: either the request to the secondary page receives the placement path as a request parameter, or your secondary page performs a cross context request to DPM in order to retrieve the file placement path.

The effort to do this depends on the your experience with WEM deployment configuration, the complexity of your secure logic, and your experience developing secondary page. I would say it could be done in a day or a day an a half, for somebody with the appropiate skills.

Hope this helps.

Kind Regards,

Francisco

De: eLink Entry: Discussion Group - Web Experience Management [v7webcontentmanagement@elinkkc.opentext.com]
Enviado el: jueves, 21 de marzo de 2013 22:48
Para: eLink Recipient
Asunto: Static Files - Manging Access with Portal Security

Static Files - Manging Access with Portal Security

Posted by lori.l.lofstrom@wellsfargo.com (Lofstrom, Lori) On 03-21-2013 17:44

Our static files doc root (placement path) is permissioned for everyone to acces and we need to keep it that way. We need to create a secondary root for secured document which can be locked down. We would prefer to use Portal Security Groups to do this so considering a solution that places the static file for the placement path on the Application server so we can apply portal security groups to access the files. This method would require that we create a listener so that the file upload places the file into the correct placement path and a servlet to stream the file when access thru the portal display. Has anyone done anything like this? If yes, what size effort was it? Are there other suggestions for managing secured static files? We also looked at placing the secondary doc root on the web server but then we would have to manage with a different ! security model. We use WEM 8.1 and Portal 8.1.1

[To post a comment, use the normal reply function]
Forum:	Discussion Group - Web Experience Management
Content Server:	Knowledge Center

Evan_Bench

Yes, excellent idea Franciso: definitely use a second file source (defined on the resources folder for your mgmt state) then a deployment type and might I also suggest using a script-based handler for the deployment type subscription that looks at the portal group ( (to automate this task instead of having to select the type manually during upload). I agree a secondary page is a great solution but if you don't have development cycles, might I suggest using the ootb cam portlets. The advantage to this is having easy access to Portal Group Security (in the security tab of the CAM portlet).

In CAM create an uploader that 'listens' to the static resource created according to Francisco's suggestion
Using the Content Explorer Portlet configure it with the the new 'folder' as a starting point
Configure security settings in the Content Explorer Portlet to use the appropriate Portal Groups
Configure addtional CAM portlets (Content Search and Story Publisher for example) with Portal Group Security and point them at the WEM File Source folder defined in Step 1

This will allow you to have your second file source that is managed completely using Portal Group Security! Editors (who have permissions on the Explorer and Search Portlets) can add, remove, edit, etc. static content. Users can work with and see the content using the ootb Story Portlets (all configured with the default Portal Security Groups)

You can find details on configuring CAM portlets here: https://knowledge.opentext.com/knowledge/piroot/wcprt/v080200/wcprt-aca/docovw.xml

Additional security:

May I also suggest putting the new file source under the control of a seperate DA (and possibly a seperate CDS!). This would allow additional physical and logical seperation between the 'default' file source and the 'Secured Files' file source. And also please generate new certs (OpenSSL, etc.) so that the second "Secured Files" DA is encrypted using a different key.

Content Access manager

Quoted Francisco Chicharro on 2013-03-22 09:41:

Hi,

Hope this helps.

Kind Regards,

Francisco

Static Files - Manging Access with Portal Security

Posted by lori.l.lofstrom@wellsfargo.com (Lofstrom, Lori) On 03-21-2013 17:44

[To post a comment, use the normal reply function]
Forum:	Discussion Group - Web Experience Management
Content Server:	Knowledge Center

Lori_Lofstrom

Thanks to both of you for responding. We will be looking at both of these ideas. The CAM piece is very interesting because it's out of the box for security purposes.