0

I'm trying to understand how Spring Security works in a three-tier architecture.

Assuming the system is composed of:
WEB <--> APP <--> DB

And that the users are defined in the DB tier.

How would I implement it in the application?
From my understanding I should do the following:

  1. Create my own Authentication Provider in the WEB tier.
  2. The Authentication Provider will call a service on the APP tier to actually validate the credentials against the DB.
  3. After the user passes the Spring Security module on the WEB tier, there are no more authentications and every WEB-->APP call is actually unauthenticated.

The last bullet makes no sense to me - so I assume I missed something in the documentation.

My question - is this the Spring way to implement security in a three-tier'd web app? Or is there a better way?

RonK
  • 9,472
  • 8
  • 51
  • 87

1 Answers1

0

That's pretty standard. Keep most of the authentication logic in the APP but the WEB becomes the client/provider.

After the call is made the further calls are not unauthenticated, the Authentication is retained using a session. So long as you declare all of your endpoints to require authentication in your security xml then none of the endpoints can be accessed unless the user has been authenticated (and will be kicked out to the path specified if they are not or their login has expired).

And also I'd argue that thinking in terms of 3-tiers for a cross cutting concern like this doesn't apply. The DB piece is irrelevant and the other division is for re-usability purposes which amount to separation of the repository and the integration.

Matt Whipple
  • 7,034
  • 1
  • 23
  • 34
  • From my understanding I protect URLs in SpringSecurity - so I do it in the `WEB` layer only. I don't understand from your answer what should be the manner in which the application will work. – RonK Sep 11 '12 at 11:28
  • I added the `DB` here since in my case the users kept there and so the `APP` layer must access it to authenticate the user - but you are right - it is irrelevant to the question. – RonK Sep 11 '12 at 11:32
  • The URLs would be the points of access for your application and therefore a place where you would secure it. Maybe the confusion is that by endpoints I meant URL endpoints (with no SOA implications)? Any other ways to access your application can be secured as needed, but if URLs are the only way, then that's the only way you need to worry about. – Matt Whipple Sep 11 '12 at 11:32
  • Our company policy is to prevent unauthenticated interfaces, and in your suggestion anyone with access to the `APP` server may perform unauthenticated activities. That is why I need to perform authentication on the `APP` side as well. – RonK Sep 11 '12 at 11:38
  • If it's distributed or otherwise open then `APP` should be secured also and limited so that only few known users (of which `WEB` would be one) can access it. – Matt Whipple Sep 11 '12 at 11:49
  • The `WEB` layer is a conduit - it delegates all activities to the `APP` layer. The `APP` layer is the one that should check that the user (e.g. **Admin**/**User**/**Guest**/etc.) is authorized to perform a certain activity. Do you suggest I do all authorization on the `WEB` layer and create an authenticated communication between the `WEB` and `APP` layers via another mechanism? (e.g. certificates) – RonK Sep 11 '12 at 11:55
  • _Authentication_ should be done in the `WEB` layer if that is the way to access your application. _Authorization_ should be done wherever is most sensible. The easiest way is normally control it through the functionality available in URLs (and then it becomes a simple Spring Security mapping); if your needs are more complex then something like AOP in multiple levels using the Identity from Spring Security may be a better fit. If `APP` is there to provide an API for limited clients like `WEB`, then any simple secure mechanism. If users are to access `APP` directly, then some form of SSO. – Matt Whipple Sep 11 '12 at 12:08