问题
We have an SSO system for authenticating users.
We have a debate between these 2 options:
Should we centralize the authorization of each application to one database (or any other single solution) and retrieve the information within the SSO request
Each web application client should manage it's own authorization logic in it's a local database / scheme.
回答1:
You should strive to decouple your business logic from non functional requirements such as authentication, logging, and of course authorization.
You already implemented SSO and surely you use a user directory as the backend for the SSO to store user identities. This shows you've successfully externalized authentication from the applications you protect. Would you ever consider having a username/password database per app? Would you ever consider writing logic to manage passwords, hashes, etc...? Of course not! The same applies to authorization.
Gartner, the analyst firm, defines the area you are considering as Externalized Authorization Management. You can find more here if you are a Gartner customer.
There are 2 main models to achieve externalized authorization: either you use a role-based access control model (RBAC) or you strive for attribute-based access control (ABAC). NIST provides definitions and more for both:
- NIST RBAC
- NIST ABAC
Many application frameworks provide some form of externalization. Take Java Spring: it comes with Spring Security and Access Decision Managers (more on the Spring architecture here). PHP, Ruby, Python, and .NET to name but a few all have their own ways too.
So, if you can, do not implement authorization logic within the app but rather leverage the frameworks you are being given.
Going further, you can even consider standardizing your externalized authorization. Much like SSO has its standard (SAML), externalized authorization has XACML (eXtensible Access Control Markup Language), a standard defined by OASIS much like SAML and backed by the likes of IBM, Oracle, and Axiomatics - which is where I work.
XACML gives you a policy-based approach to externalized, fine-grained authorization. You can write policies and apply them to any number of applications. And of course you can extend your SSO layer with XACML.
The benefits of using externalized authorization - and in particular standardized on XACML - are:
- consolidation of authorization logic: it's easier and cheaper to maintain
- better security: XACML is more expressive and you now have one place to go to to check whether security is correctly implemented.
- ability to expose new business: some of the customers I deal with want to expose apps to the web / 3rd parties. Using fine-grained authorization lets them control who can do what and under which circumstances.
- compliance: look at the world we live in today. We have to comply with many regulations depending on our field of work (banking, insurance, medical...). These regulations are hard to implement in code but easy to express as policies which is exactly what XACML delivers.
If you want to know some more, I delivered a presentation on Java and XACML at JavaZone 2013. The slides are here.
What SSO solution do you use? SiteMinder gives you an authorization API (ActivePolicy) to implement finer-grained authorization. Have a look at that.
I hope this helps!
回答2:
I would distinguish between the logic and data needed for authorization.
If you are looking at the authorization logic, it's more specific to an application. Why would you want to centralize the logic? Possibly, you have a case where the same authorization logic is used across multiple applications and such authorization logic is subject to change. Many applications will not need this though and the development of an application to externalize all authorization logic might not always be a viable option due to the time and cost needed. Some policy specification language is needed for this purpose and an interpreter should be used with each client app.
Centralizing data needed for authorization is a much simpler task and possibly a more frequently needed feature than the above. However, when the data needed depends on domain objects than the subjects, then again you end up with the above mentioned case. I guess when you have a suite of applications where same user roles or attributes are applied similarly, there's more value of doing this (and may possibly be needed as well). Another case might be the need to have centralized authorization management by a single group of people - this may or may not apply to your applications.
Prescribing one solution over the other is not something I like to do. If ever I need to come up with a yes/no answer for a question of this nature, I would evaluate other aspects as well. For example,
- Existing applications, their implementation languages, platforms, modification overheads and existing authorization mechanisms used.
- What exactly should be centralized (logic, data)?
- Is the complexity of the centralized authorization justifiable?
- Network communication overhead and added latencies
- How does this affect the testability of systems and parts?
- ... This list would not end easily...
来源：https://stackoverflow.com/questions/19568435/should-authorization-logic-be-centralized-or-decentralized