3

We have an SSO system for authenticating users.

We have a debate between these 2 options:

  1. Should we centralize the authorization of each application to one database (or any other single solution) and retrieve the information within the SSO request

  2. Each web application client should manage it's own authorization logic in it's a local database / scheme.

David Brossard
  • 13,584
  • 6
  • 55
  • 88
rayman
  • 20,786
  • 45
  • 148
  • 246
  • Please read the description of the "authorization" tag you added to your question. Is that what you mean when you use that word? Or do you really mean "authentication"? – Daniel Hilgarth Oct 24 '13 at 14:18
  • I was talking about authorization. If I should centralize that information(like authentication) or letting each app to manage it independently in our organization. – rayman Oct 24 '13 at 14:26
  • 1
    IMO authorization is application specific. I fail to see how you would do that centrally? – Daniel Hilgarth Oct 24 '13 at 14:58
  • It's known that with SSO providers (Like cas) you can set attributes for example in ldap and retrieve the user object within the SSO request. Alternatively you could have DB which will handle all authorization data for your various web applications. – rayman Oct 24 '13 at 15:17
  • @DanielHilgarth I disagree - authorization like any other non functional requirement (authentication, logging...) should be decoupled from app logic / business logic and maintained in a layer of its own – David Brossard Oct 25 '13 at 12:16
  • @DavidBrossard: It still is application specific. This is not about the layers of one application. It is about having one centralized "thing" for *all* applications. I think what the OP talks about is really claims based authorization. In that you would centrally store the claims of the user but your application would still need to specify which claims are required for which operation. – Daniel Hilgarth Oct 25 '13 at 12:17
  • @DanielHilgarth it's not app-specific but rather either framework-specific or put into a centralized service such as a XACML authorization server. – David Brossard Oct 25 '13 at 12:31

2 Answers2

4

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:

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!

David Brossard
  • 13,584
  • 6
  • 55
  • 88
  • Thanks for your response. I a using CAS as my SSO provider. And having all my users' data within LDAP. The CAS retrieves the user's information from LDAP and authenticate against it. – rayman Oct 27 '13 at 08:19
  • I am trying to understand how I could integrate my Spring security app to use XACML for authorization purpose. Because right now our spring security application integrated to CAS for authentication purposes. How could you combine the two? thanks. – rayman Oct 27 '13 at 09:15
  • " you can extend your SSO layer with XACML" How would you do that. some example would help – rayman Oct 27 '13 at 09:39
  • Example: your SSO solution intercept the original HTTP request via its agent. The HTTP headers and URL are sent to the SSO server which issues/validates the identity of the user. THe SSO server can then send a fine-grained authorization request based on the URL and headers to a XACML policy server for a decision. Note that if you want finer-grained access e.g. enable/disable UI widgets, then integrating with an SSO is not good enough. Axiomatics have a whitepaper on how they extend SSO (based on CA SiteMinder) to achieve fine-grained authorization. – David Brossard Oct 27 '13 at 14:01
3

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,

  1. Existing applications, their implementation languages, platforms, modification overheads and existing authorization mechanisms used.
  2. What exactly should be centralized (logic, data)?
  3. Is the complexity of the centralized authorization justifiable?
  4. Network communication overhead and added latencies
  5. How does this affect the testability of systems and parts?
  6. ... This list would not end easily...