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.
Related Q&A from Randall Gamby
Enterprise SSO products have matured over the years, so what's the state of eSSO today? Expert Randall Gamby discusses.continue reading
Enterprises need a full understanding of the FIDO authentication framework before switching to its technology. Expert Randall Gamby looks at the most...continue reading
A self-managed HSM appliance may be the safer external key management system to use with your organization's encryption keys. Here's why.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.