Hi there,
Security Labels: Can't really help you there, I've never used them, but we've got a fairly robust customized system and everything is running relatively smoothly so if security labels were critical for functionality we would likely have put them in by now.
Adhoc ACLs: Context-specific or object-specific access control rules that are a pain to see system-wide, they're too hidden. Don't use them.
ACLs: Done through the Policy Administrator, these can do everything that Adhoc ACLs can do yet you can see and set them system-wide, so far more consistent and easier to maintain. This is the "central core" of the access control systems in PDM, but there are in fact several others that interact/overlap with it. Very flexible.
Profiles: Set directly on a user Account, is not actually separate from the ACLs but interacts/overlaps with them. This mainly controls which action buttons a user will see in their menus. KEY NOTE: If someone sees such a button through their Profile but an ACL prevents them/their role from doing the action they'll still be blocked as they'll get an access error message. Likewise, if an ACL gives them access but their Profile hides the relevant button they won't be able to do it in the first place. Make sure both of these match. I've heard some people claim that you shouldn't use Profiles but I've directly seen people with no-profile accounts have significant access issues, and on top of that the action button for one more key access control system that you didn't list is only controlled via Profiles. Having one profile for your general userbase and another for yourself (the Site Administrator) should cover most of what is needed.
Configure Actions for Roles: You didn't mention this one but it is also important. It goes context by context and works quite a bit like a Profile but with some alternate options, controlling what a user can see. Note, access to this very function itself is not controlled within the Configure Actions for Roles screen so you have to control access to it via Profiles. Also note, whatever context Template you use to create a new context, the settings in Configure Actions for Roles are also by default set based on what is in the template.
Server-Side Coding: You also didn't mention this one but it is worth noting. Several access controls are hard programmed on the server, such as the restrictions on the Guest context role. These can be a real pain to mess with, I wouldn't recommend trying.
All in all, make ACLs, Profiles and Configure Actions for Roles consistent with what you want each context role to do, be aware of some hard restrictions on the Server, don't use Adhoc ACLs and Security Labels I can't help with but I wouldn't think help much given how long my company has been working with PDM just fine without using them.
Daryl
