This is my understanding of ACL Templates vs Policies. Anyone else, feel free to shoot me down in flames if you think I've got this wrong.
Prior to 7.6 (or was it 7.5?) and the introduction of ACL Policies, if for example you had a role which was assigned a default ACL Template, with certain permissions included in it, every object a user created using that role would be assigned the relevant permissions as defined in the default ACL Template.
Some time later you come along and decide to add another permission to the role, and update the ACL Template accordingly. You then had the annoying and time consuming task of having to revisit every object ever created by that role and manually update the permissions by reapplying the ACL Template. Of course the clever among us would have had a blcli script to do this
Anyway, ACL Policies are dynamic. So you still create your ACL Templates as normal to control the initial permissions newly created objects are given etc etc, and then you can build an ACL Policy containing the relevant ACL Template(s) and assign that policy to a group or depot objects for example.
Now when you then decide to add a permission to a role and it's associated ACL Template, the ACL Policy which includes the ACL Template that you just updated will see to it that all of the objects it is applied to automatically get their permissions updated.
Or something like that.
So, in short, you'll want to use both I suspect.
Hope that helps.
Someone has been reading the user guide . Yes - that's good.
I don't like ACL Policies because you can't tell by looking at an object what permissions are applied to it. I find this very annoying. ACL Policies are useful if you want to put in maintenance windows where users cannot execute jobs against severs during a time windows (i have only read about this). The good and bad thing about the ACL Policy is that if you change the policy it changes all objects linked to it. the problem i find w/ this is that if you want to you use the policy for dev/test/prod promotion you can't because you usually only want to promote one object at a time, not all so you are back in the 'find object, apply acls' boat. the acl policy is useful as a fixup mechanism - it's an easy way to fix acls for objects as a failsafe, w/o having to go into rbacadmins.
so i find them a mixed bag. what would be really useful is folder permission inheritance, like you get on windows.
Yes, that would be a great feature....I smell an RFE
Put it in ☺
One thing that I've noticed is that when you apply an ACL template to a server, there is no way of knowing that the template has been applied to it (it just pulls out permissions relevant to that object). This could be an issue for security, depending on your implementation. ACL policies, however, you always know what has been applied.
There has been much deliberation about which to use in the implementation I'm working on.
To be honest - I can't really see why templates are still there now policies are around?!
The ACL Template is a way to assign a group of ACLs easily, it was not designed to maintain a connection w/ the object. There is not a security issue that i can see - the acls are on the object and that's the access a role has to it. it shouldn't matter what ACLT they came from.
ACL policies maintain their connection to the object when applied which is not always desired.
But can't a policy assign a group of ACLs just as easily?
Maybe not an issue as such, but possibly a concern.... For instance, if you had numerous permissions from numerous roles in a template, you'd never really know what had been applied to a server without looking in depth at the individual permissions - however an ACL policy applied to that server would be immediately obvious and you could examine the policy to check what has and hasnt been added to it. I'm not sure if that makes sense?!
Why would a connection not always be desired? I'm only just starting to scrape the surface with this RBAC business and it's quite a mission!
Sure, the policy can, but then that policy is associated w/ that object and any other object you apply the policy to. So if you change the acls in the policy it changes acls on all objects the policy is associated with. You may not want to do that. if you only use policies, how do you setup unique acls on objects? If you say to remove one aclp then apply another aclp, that’s the same amount of work to use a acl template.
You are right – if I look at an object, I need to see all the permissions on the object to understand who has access. But you need to do the same thing w/ the policy – I need to now got an find the policy in another area of the gui and look at the acls there instead of looking right at the object itself.
Hmm... I guess there are two sides to every coin. I would argue that in a structured environment there shouldn't really be any cases where you would setup an object with a unique acl?
This is true - but what about reporting? You would be able to produce a report, for example, with a header of "ACL Policy" followed by a list of servers that it has been applied to which you could present to your security team for audit purposes - you couldn't do this with templates as there is no intrinsic link between the template and server?
Sorry if I appear to be fussy, I'm just trying to map out every avenue that RBAC could take!
Boys….boys…. You’re both momma’s favorite. ☺
Haha! I'm currently helping to implemend RBAC in my place of work so it's nice just to see the flip side of the coin and have a discussion about it
You could generate such a report, but you can also generate a list of Authorizations and the objects they apply to as well I think. The ACLT and ACLP can accomplish the same think, but in different ways.
Maybe a real-world example would help?
(Disclaimer - I started with BL 7.3 where only ACLT's existed, so that's my starting point, then upgrade to v7.4.6, still no ACLP, then upgrade to BL 8.0 where we have this new, alien object - ACLP)
We have about 2600 target servers split among 4 OS platforms (managed by platform admins in 2 roles - UNIX versus Windows). ACLs needed do follow a basic pattern which then breaks down on the many "special cases".
- servers get a Server.* for the BLAdmins role
- servers get a Server.* for the appropriate platform admin role (automatic when platfom admins add the server, manual when BLAdmins adds the server)
- servers get Server.<specific auths> for every additional role that has an "every server" (InfoSec, Capacity Planning, 3rd party tool admins, etc.) type of role...
So, these auths are in the ACLT for each role allowed to add a server to BL (only a few roles actually have Server.AddServer) so they get applied to every new server added to BL.
Now for where that simple pattern breaks down... What do you do about DBA (and others), who should only have access to certain specific servers? There's no "simple", automatic way to assign the ACLs.
We ended up creating a boolean server property that serves as a "flag" to say this role is allowed to have access, and that roles' default ACLT contains their standard Server.<specific auths>.
So, basically, I get a Remedy ticket requesting access, and I have a job that sets the flag, and applies that roles' ACLT, and then pushes the updated ACLs to the server. I frankly don't see any way at all to use ACLP more effectively, since I'd need just as many, and I'd still have all of the shortcomings.
I have about 10 roles with this "issue" (and their own boolean properties to match), so a script to handle this automatically could be quite a challenge to get right and be reliable.
Worse is the problem you are describing...
1. Reporting on where any particular role has access?
2. How do I go about removing it should it's access no longer be appropriate?
You'd think #1 would be solved by the boolean server property, but there are continuing hiccups regarding flags not set when they should be, and auths missing even when the flag has been set (mostly from when this process was completely manual)... This doesn't even account for the really basic situation where a role says "how come I don't have access to this particular server", expecting that I'd magically know they needed and deserved access!
#2 is even worse... Scripting this has so far been painful, and isn't complete or reliable yet.
Did this help or hurt (or both)?
What scripting issues have you had getting the property and acl template application to work? maybe start a new thread on that.