How to restrict "reports" option on Certificate Operations workbench for vettors on Registration Manager
Originally Published: 2015-01-20
Last Modified: 2023-10-06
Article Number
000067731
Applies To
RSA Registration Manager 6.9
Issue
By 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').
Tasks
Creating 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?
Resolution
Here 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

Related Articles

Trending Articles

Don't see what you're looking for?