000029447 - How to restrict "reports" option on Certificate Operations workbench for vettors on Registration Manager

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 4Show Document
  • View in full screen mode

Article Content

Article Number000029447
Applies ToRSA Registration Manager 6.9
IssueBy default, the Web ACLs are preconfigured based on workbenches. So a vettor would have access to all operations under the 'Certificate Operations' workbench, including 'reports' option. The Web ACLs can be tweaked to disallow vettor access to 'reports' operation (so only 'administrators' and/or certain vettors have access to run 'reports').
TasksCreating a new Web ACL for /ra/cert-ops/cert-report.xuda with the following two rules, will disallow vettor access to 'reports' operation (and only allow administrators to run 'reports'):
( admin-type = admin ) -read$
( sn = /* ) !none?

This Web ACL can be tweaked slightly to ALLOW some vettors to be able to access 'reports' operation, for example:
( | ( admin-type = admin ) ( md5 = <md5-of-vettor-who-should-have-access>) ) -read$
( sn = /* ) !none?
ResolutionHere are detailed steps on configuring the Web ACLs on RSA Registration Manager (RRM):



1.  Generate two new vettor certificates for RRM.  RRM administrator is required to update the Web ACLs (/, /ra/, /scripts/) on RRM to allow the new vettor access to the admin interface.  For example, if MD5 new vettor1 cert is f4bcc9134c92e8c0256b0470b0faa6ae and that for vettor2 is 758b2e7a80bf1723729dcf6034e00a1b, the Web ACLs are updated as follows:

 
a. Update ACL for / (screenshots before and after shown below):


Web ACL for /, before update
updated Web ACL for /
 

b. Update ACL for /ra/ (screenshots before and after shown below):


Web ACL for /ra/, before update
updated Web ACL for /ra/
 

c. Update ACL for /scripts/ (screenshots before and after shown below):


Web ACL for /scripts/, before update
updated Web ACL for /scripts/
 

2. Validate that the new vettors have appropriate access to RRM admin interface



3. As an RRM administrator, create a new Web ACL for /ra/cert-ops/cert-report.xuda as shown below:
 
a. If ALL vettors should NOT have access to 'reports', create the new Web ACL with two rules as follows:

( admin-type = admin ) -read$
( sn = /* ) !none?

The Web ACL on RRM admin interface should look like the following:

New Web ACL for /ra/cert-ops/cert-report.xuda
 

b. If only some, but not all, vettors should have access to 'reports', create the new Web ACL with two rules as follows:
( | ( admin-type = admin ) ( md5 = <md5-of-vettor-who-should-have-access>) ) -read$
( sn = /* ) !none?

For example, say, only vettor2 (created in step #1) should have access but other vettors (including vettor1 should NOT have access), the Web ACL on RRM admin interface should look like the following:

Web ACL for cert-report.xuda


NOTE:  When creating each new rule for the ACL, you can copy the string “( admin-type = admin ) -read$”, and similarly “( sn = /* ) !none?”, directly in the text box just above the button ‘Commit rule changes’.

 

4. Test with vettor1 cert, the vettor should NOT have access to 'reports'

5. Test with vettor2 cert, if step 3-b was followed then the vettor should have access to 'reports'


6.  Test with an admin cert, 'reports' should work fine

Attachments

    Outcomes