I am looking for a viable design/architecture pattern for securing several web applications. Here is the situation:

  • Multiple web applications must enforce roles and permissions at Java service method level

  • Roles and permissions have to be stored centrally, in a separate component

  • How the roles and permissions are enforced (i.e., the behavior to be applied to roles and permissions) are also to be enforced centrally. This is important because we would like to standardize how methods are secured and how roles and permissions are enforced in order to avoid the risk of clients messing it up.

The options I am considering are:

  1. Write a java client which would apply the behavior using some annotations - then individual web applications just need to include this jar file and use the annotation (cons for this approach: jar file rollout, dependency management)

  2. Provide a web service which the methods can utilize (cons: it may not scale as calling an external service for a cross cutting concern would not scale)

How can I best solve this problem?

  • 2
    Your approach #1 sounds like reinventing Spring Security, Apache Shiro or something similar. Also, if roles and permissions are stored somewhere else in a network, this would still require calls to some external web API, wouldn't it? What exactly do you mean by "stored centrally"? Does it mean "in a single repo" or "on some kind of web server"? – scriptin Nov 12 '15 at 17:05
  • In approach#1, we might even leverage Spring security ourselves. The reason for thinking "centrally" is this: in practice, it has been very difficult so far to enforce different client teams to secure critical methods properly. Either they forget or they just implement it wrongly. Storing roles and permissions centrally has to be done anyway. This is a configuration which can be cached. – senseiwu Nov 12 '15 at 17:13
  • 2
    If they can forget and make mistakes now, what would prevent them to do that with this centralized approach? They still can forget to put an annotation or make a call to an API, or do it improperly. It sounds like you're trying to find a architectural solution a human-factor problem. I think the better solutions here are code inspection, acceptance testing, etc., possibly done by another team. – scriptin Nov 12 '15 at 17:21
  • 2
    My understanding is that authorization always has to involve a non-client machine, because you can't trust the client (and you obviously don't or you wouldn't be asking), so...I would think it has to be #2. – Ixrec Nov 12 '15 at 21:03

What you are looking for is called externalized authorization. There are different ways of doing it and like some of the commenters point out, Apache Shiro, Spring Security, Microsoft Claims are all ways of externalizing authorization.

If you look at the broader access control picture, you will see there are different acccess control models:

  • access control lists (ACL),
  • role-based access control (RBAC), and
  • attribute-based access control (ABAC)

All of these can be used to externalize authorization though typically ACLs are not.

Apache Shiro and Spring Security achieve role-based access control i.e. you define users, roles, and permissions. You assign users to roles and roles to permissions. The information is stored centrally e.g. in an LDAP and the applications consume those. This will let you achieve coarse-grained access control. How the apps consume the roles and permissions and what the apps do with these is all up to the app developer. So in a way it is not fully externalized.

ABAC goes further. ABAC defines:

  • an architecture
  • a policy-based approach
  • a request/response scheme to query for authorization

ABAC is typically implemented using a standard called XACML, the eXtensible Access Control Markup Language.

In ABAC's architecture you will find the following components:

  • the policy enforcement point (PEP): this is the piece inside your app or in front of your app that you will use to query for authorization. This is the piece that externalizes your authorization. In your app for instance, you will use the PEP to create a request of the type Can Alice view document #123? The PEP will send that to the central authorization engine
  • the policy decision point (PDP): this is the central authorization engine. It is configured with policies. Those policies are built using attributes. For instance doctors can view the medical record of a patient if they have a care relationship with that patient. Attributes can be retrieved from databases, web services, and LDAPs. The PDP receives the request from the PEP and evaluates it. It eventually reaches a decision e.g. Permit or Deny which it returns to the PEP.
  • the policy information point (PIP): the PIP is the source of additional attributes the PDP might need e.g. a user's role or department, a document's status...
  • the policy administration point (PAP)

The diagram below summarizes the architecture.

XACML Architecture Flow - Axiomatics

Have a look at either:

  • David, very good answer (+1). After checking the solutions, I will consider it marking as the accepted answer. Thanks – senseiwu Dec 6 '15 at 9:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.