Multilayer security concept

Question

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.

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

Answer 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?

Answer 2

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.