6 Replies Latest reply on Feb 7, 2008 7:35 AM by ataylor

    moving SecurityAspect to be an interceptor

    ataylor

      It makes sense to remove the handling of security from the endpoints themselves and handle them transparently to make things cleaner. Currently, however, the username and password are only available on the ServerConnectionEndpoint. One way to solve this is to associate a user with a connection on the client side and pass it with the Packet on send. Does anyone have any thoughts on this?

        • 1. Re: moving SecurityAspect to be an interceptor
          timfox

          That would be exploitable since a rogue client could just send (guess) someone else's user id.

          Instead you could maintain a map of packet target id to user id in the server side filter and use that.

          • 2. Re: moving SecurityAspect to be an interceptor
            ataylor

             

            That would be exploitable since a rogue client could just send (guess) someone else's user id.
            Is that different from how the createconnectionrequest works now.

            Instead you could maintain a map of packet target id to user id in the server side filter and use that.

            That was my first solution but the interceptors wouldnt get called if the connection was removed by the server and we would end up with an ever growing map.

            • 3. Re: moving SecurityAspect to be an interceptor
              timfox

               

              "ataylor" wrote:
              That would be exploitable since a rogue client could just send (guess) someone else's user id.
              Is that different from how the createconnectionrequest works now.


              Yes.

              Creat connection request takes a user id, *and* a password. The password is hard to guess.

              If you authenticate and then allow the same user id to be used in subsequent operations without a password, then that's exploitable, since authentication is already done by that point.

              • 4. Re: moving SecurityAspect to be an interceptor
                ataylor

                 

                Yes.
                
                Creat connection request takes a user id, *and* a password. The password is hard to guess.
                
                If you authenticate and then allow the same user id to be used in subsequent operations without a password, then that's exploitable, since authentication is already done by that point.


                of course!

                Instead you could maintain a map of packet target id to user id in the server side filter and use th
                at.


                Ok, so adding and removing the users from the map on creating a connection and closing a connection is fine. If the server closes the connection via the connection manager on client fail, the interceptor wouldn't get called and the user would remain in the map.

                • 5. Re: moving SecurityAspect to be an interceptor
                  timfox

                   

                  "ataylor" wrote:

                  Ok, so adding and removing the users from the map on creating a connection and closing a connection is fine. If the server closes the connection via the connection manager on client fail, the interceptor wouldn't get called and the user would remain in the map.


                  Good point. When I think about it, I don't really see what's wrong with having the username/password on the ServerConnectionEndpoint. After all they're just attributes, as long as the security logic itself is not there but in the interceptor then that should be ok IMHO.

                  • 6. Re: moving SecurityAspect to be an interceptor
                    ataylor

                     

                    Good point. When I think about it, I don't really see what's wrong with having the username/password on the ServerConnectionEndpoint. After all they're just attributes, as long as the security logic itself is not there but in the interceptor then that should be ok IMHO.

                    Can you clarify! I'm not sure i follow, the interceptor has no access to the ServerConnectionEndpoint.