From a provider-centric approach, you have to have consistent security policies, processes and access across all systems. Having an identity management environment where access to the same information across different systems has different privileges causes the risk of exposure to go up. In the same way, not knowing what accesses and privileges an individual has can increase the risk of missing accesses the user may not need to do his or her job.
Regulations also require both. Some regulations cover how to manage an individual's access/denial to authorized and unauthorized information -- such as HIPAA or PCI DSS --, while other regulations are concerned about loss and/or exposure of information from applications and services, like state identity disclosure laws. For identity management I stress equal efforts for both: I personally maintain two identity management architectures. The first is what I call the Identity Management Architecture, which takes on the provider approach; this is where systems and services for pre-defined access workflows and information storage are defined. The other architecture is the User Access Architecture, which takes the user-centric real-time access approach and defines how consistent access and monitoring is defined. The two architectures use about 60-70% of the same components, but of course the views are quite different. By having these two architectures synched up, I can address either provider- or user-centric issues.
As to which is more secure, I'd have to say, if I didn't have both, user-centric would be the best option, just because of the scope of the risk. If I mis-configure a user, I affect only one person. If I mess up system access controls, it affects major population groups. So always lead with a provider-centric approach, then follow up with a user-centric approach: Besides, you have to know what resources you're securing before you figure out how someone will access them.
As a parting thought, role-based access can be used as the bridge between the two. By matching user responsibilities and functions to services provided, roles are easier to define and can be the pivot point between the two architectures.
This was first published in May 2010