0

I'm working on a security concept of a bigger project. It will be done with Spring,but that's actually not relevant right now.

The whole system is a hierarchical tree of computer nodes that run a custom platfrom software, whereas layer 1 nodes connect to a node on layer 2, layer 2 nodes connect to a node on layer 3 and so on.

enter image description here

The idea is that the whole system has a master node which will be the root of the tree. The whole user management including authentication will be done there. Meaning a login request from a lower layer node will be forwarded to the root node. The concept for this is pretty much done and looks good.

The difficult part right now is the authorization. The system should give a top down SingleSignOn feeling. Meaning if I've signed on on a layer 3 node, I will not have to sign on on any lower layer node again. Currently I imagine it like this:

Sign on

  1. User signs on on an upper node
  2. User gets the session key stored in a cookie
  3. User access a platform on a lower node
  4. Lower node's authorization module does not know the session key provided
  5. Authorization module ask upper node if session key is known
  6. An upper node instance knows session key and responses with an OK
  7. Authorization module on the node with attempted access creates a new local session for this user.
  8. Session key gets added to cookie.
  9. User uses local session key for further access of this node.

Sign off

  1. User signs off on a random node
  2. Node on which the user signed off informs the node with the stored original session key, that the session is not valid any more.
  3. The node with the stored session original session key send a broadcast down to inform all clients that this session is now invalid.

The whole inter layer communication will be secured of course.

This concept would technically work, I guess. As I never had to create a complex security concept like this, I really d'like to hear another opinion. Maybe I'm overseeing a major issue. Can you see a fatal hole in the story, or should I go with that?

UPDATE

An important detail I missed, is that a lower layer does not necessarily have direct network access to the top layer. It can happen that the layers are in different networks and only will have direct network connection to next higher layer. Therefore I will not have the possibility to make a central login server as usually used with SSO.

UPDATE

Sequence diagram explaining the whole process and need of keys

enter image description here

  • 2
    I don't know how many nodes and layers do you have but, the solution seems to me a hell of latencies. The idea of using upper layers as reverse proxy is good, but all the network hops required to reach the root is what I don't buy. I wonder if the problem with networks communications could not be solved with ip tunneling or something similiar, for instance implementing VPNs – Laiv Jul 1 '17 at 17:06
  • @Laiv Thanks for your comment. It will not be that deep. Max 3-4 layers. It mainly will be wide. Up to a couple thousands nodes within a layer are possible. The idea with the VPN tunneling is reasonable but causes a security issue, as the lower layer is running 'critical' productive hardware. With this subnet concept, they are only accessible form the very upper layer. VPN tunneling would expose them to the regular network on which the root is running. – Herr Derb Jul 3 '17 at 11:25
  • 1
    Well, the idea is to make the whole topology of the network "flat" with the adequate mechanisms instead of giving that responsibility to your software. It does not mean your solutions is bad, Once implemented pay attention to the latencies. How long takes for lower layers to reach the upper layer and get the response back. Be very Conscientious with the failovers, the eventual consistency is going to be painful to track. I would suggest allowing specific endpoints on each layer for testing visibility from layer to layer. – Laiv Jul 3 '17 at 12:00
  • Am I the only one who thinks, this is an overly complicated hairball? I find it too abstract to say, whether this even makes sense at all. – Thomas Junk Oct 2 '17 at 12:21
1

Your layer 1, and especially layer 2, seem to do very little beyond offering connectivity. No validation to reject DoS, no caching.

A Kerberos-style TGT & Service Ticket relies strictly on symmetric crypto, no RSA. In your setup it seems natural for layer 3 to produce signed statements that other layers + client verify and trust. Layer1 could use HMAC to cheaply verify client hasn't tampered with a cookie.

Do this: write down a Story of what some demanding high-performance user does on a typical day. He logs in, 500ms later he accesses this, 2000ms later he accesses that other secured resource, and so on. Now look at the story and write down predictions of latencies experienced by user, and operations-per-second seen by higher layer nodes across giant population of similar users. Could layer 3 anticipate next likely transaction, and proactively populate relevant caches beforehand? Perhaps using messages that are bit-for-bit identical, so there is comm. overhead but no additional crypto overhead?

0

The way I see it a session key would be enough, with this key you got all the information you got: user id, session expiration date and you can authorize on demand. A way to handle this is request access to a resource and reply with the list of privileges granted for the user.

In the other other hand I'll consider if it's worth making all this from scratch when you got some open source solutions to implement this kind of security such as OpenAM.

  • An important detail I missed, is that a lower layer does not necessarily have direct network access to the top layer. It can happen that the layers are in different networks and only will have direct network connection to next higher layer. Therefore I will not have the possibility to make a central login server as usually used with SSO. – Herr Derb Mar 2 '17 at 9:17
  • But layer 1 is handling authentication so I'm guessing that if an application on layer 3 is trying to authentication is doing so through layer 2. Right? If so you sould be doing the same with the authorization. – Zalomon Mar 2 '17 at 9:22
  • I think I'm on the that way. I'm just on a couple diagrams. I'll update as soon as they're done. – Herr Derb Mar 2 '17 at 16:18
  • I've added a sequence diagram that show for what the different keys are used. – Herr Derb Jul 3 '17 at 11: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.