blcli_execute BlAclPolicy showPolicyPermissions <policyName>
should dump what's in the acl policy.
and then some sed/awk/etc to switch out the role names.
as far as a better way...
1 - get away from the explicit permissions and use the authorization profiles to group together specific types of access, etc 'create a package' or 'browse a server'. then you can update one object and affect everything it links to.
2 - maintain something outside of bsa w/ the information you need and then script the creation of the roles and such. you could also script a check that all the rbac objects match your source of record so that adding some perms in to a class of roles - eg <SITE>_WIN_ADMINS is a single update to a csv and then a run of the script.
3 - w/ #2 the objects are created from scratch so no chance for something you forgot to clean up.
The three blcli commands are:
blcli -r RBACAdmins BlAclPolicy showPolicyPermissions <policyName>
blcli -r RBACAdmins BlAclPolicy createAclPolicy <policyName> "<description>"
blcli -r RBACAdmins BlAclPolicy addPolicyPermission <policyName> <roleName> <authName>
As Bill said, there is a bit of manipulation between, but it is very straightforward once I had all three commands.
I can add Role permissions with
blcli addAuthorizationToRoleByName <Role> <Type.Permission>
But how do I get the list of Authorizations from an existing role to copy them across?
I found a back-door that works for now.... If I open the source Role then the Summary tab has a table with the Authorizations in one column, and (at least in our setup) the word Direct in the second column. I suspect the second column is because we set the Authorizations directly rather than using the more sensible Authorization Profiles. The table is text, so I can cut and paste it. It seems like there out to be a programmatic way though, so that I can script the whole thing.
but are you sure that you want to grant the same permissions w/ the acl policy that the role has ? for example - the role has sever.*. do you need to grant them server.* via the acl policy you are creating ? or maybe only server.read and server.browse, because on the servers the acl policy is associated w/, that's all this role needs?
to do the equivalent of the copypasta i think you can use RBACRole.getSetupSummary and scrape that for the authorizations.
Precisely, that's why I need a way to dump the Role permissions, like I do the ACL Policy permissions.
I had noticed the RBACRole.getSetupSummary command, but hadn't clicked that that would show the same thing I was cut and pasting from. I'll look into that. Thanks!
I got a couple of mails asking for more detail and clarification. I'm replying back here to log the whole conversation, in case anyone else is in a similar situation.
I work for a large computer consulting firm. We have commercial, Federal, multiple State, and some US Military clients. Each of them needs to keep data separate from the others. One State client has multiple agencies that need their data segregated. We manage servers in both our own and client data centers. Some of the servers are owned by us and run infrastructure (such as BladeLogic). Many of the servers are owned by us but are dedicated to specific clients. Some are owned by clients, but they pay us to manage them. All in all it is quite an involved mix of ownership and access.
We are beginning to use BladeLogic to manage servers. Most of the clients are content to use the MyCompany Global BladeLogic Server instance, and use ACLs to make sure that only people authorized for that client can see their servers, ie, ClientA server and Role ACLs line up, ClientB server and Role ACLs line up, etc. (Yay ACLs!) But that means that we have a great many very similar roles:
And so on.
The Global roles manage infrastructure, and the Client roles have ACLs that limit access to only servers pertaining to that client. Each Global role is the definitive example of what that role should look like. So when we extend BL management to a new client I have to copy the Operator and multiple Admin Roles to set up that client's ACLs.
Further, some clients require an air gap between their servers and anyone else's servers. So we have multiple BladeLogic Server instances. (Where a "server instance" is a database server, a management head, and two or more application servers.) Most of the unique server instances needs further segregation, for example the State with multiple agencies. Frequently when we set up a new server instance we can use the same sort of ACL configuration the Global instance uses, just on new hardware. So I not only copy Roles and ACL policies (with many lines of permissions) to clone them in the Global instance, sometimes I copy them to completely new servers.
Obviously, the more we can automate this the better, both to save time and to reduce typing errors.
i did something like this for a customer a long time ago. they have multiple lines of business and then multiple projects w/in each lob that needed rbac separation. but each lob and each project had the same set of roles. a rbac role to manage all of the objects in the 'project', deployer, admin, etc. so we setup auth profiles to map out all the functions (edit software, deploy, patch, etc), then each 'template' role was some collection of the auth profiles. then we had a script that would read some properties files that defined the 'template' objects (they didn't exist in bsa) and then you'd provide a csv w/ the project name and some other stuff and it would build out a workspace folder structure, property dictionary class structure, create users and setup all the roles. at one point i think we stored the 'template' stuff in the property dictionary so you just needed the script and the csv of what you needed to create.
you might want to think about something like this if you need to make this portable between bsa installs. one source of 'truth' that defines your roles (you could even have it reconcile all your roles that already exist if you need to make changes) and a script to enforce that truth in your envs.