RMI protocol is pure stateless. It means that every remote call should contain some additional information about the caller and its credentials, if we would like to support authentication and authorization on the server side. By using this information, the server side security interceptor and server side security manager provide authentication (comparing the income actual caller/credential information with the correspondent information from the internal cache), and authorization (comparing acceptable roles for caller and for remote method, which is being called). In case, the internal cache does not contain the data for actual caller, the server side Login Module is asked for desired information.
So, during the authentication (in common sense) it is necessary to provide caller credentials to Login Module (or place, from which this Login Module will fetch this information). In order to do it, and avoid transferring the actual password value on the wire, you can use some kind of asymmetric key exchange protocol (SRP for example). It means that your client side login module (complaint to JAAS ) will communicate to some server side component (for example JBoss service, or something else) and perform this work. By the end of this process, both sides will hold a unique session key (this caller private credentials), which are actual only until the caller session is alive. This is similar to login to windows domain, when you get some key, which is actual until you logout, or shut down your host, or something like that. This session key will be transferred by every call from client to server and used for authentication purposes, as I described in the first paragraph. It does not mean however, that the data, which is transferred on the wire is encrypted. So, somebody could hack/debug the invocation (in theory), extract the session key, end use it maliciously for for sending his own commands to the server. This could continue until this session is not void. In addition, authorization is not bypassed in any case. Returning to you case: > I am a little puzzled by your comment on the ?not really secure?. I think that in this context it means that the RMI call is not encrypted. You can do it by yourself, or use third party ?tool? (which is preferable, I think), like SSL. > - If I understand correctly something like Kerberos, the authentication > process is secure without requiring an encrypted channel. What I mean is that > someone can not pretend to be someone else without knowing its credentials, > and you cannot determine the client credential by watching the data exchanged > on the wire. Yes. But only during the authentication process. After the end of this process, during the ordinary work it is possible to intercept the ?session key? and use it for you own goals. > - After the authentication process, I agree that without a secure channel, > someone can see (and potentially alter) the data being transferred. But this > is a different ?issue? and SSL is the answer if you want data privacy on the > wire. I think yes. > - Final possible risk that I see is, since the channel is not secure, someone > can see the data being exchanged and manage to impersonate the client (create > other messages for the server making it believe that it is the original > client). If such risk exists, could we imagine just ?signing? the message > instead of completely encrypting it? This should hopefully still be faster > than full SSL, shouldn't it? I think it will be faster. But the message is ?signed? in any cases (caller/credentials information is added to every invocation). So, such signing will not prevent impersonating the original client. > But GSS-API with Kerberos and the corresponding Login module seems to be able > to provide a few nice things: >- Single sign-on capabilities. The credentials of the user running the client >process can be ?automatically? used to authenticate against the server without >having to re-enter user/password. I am not sure that I understood this point. I think that SSO capabilities are something from different area. If you are speaking about using windows domain user credentials, I think that the SSO (in your meaning) could be achieved (the client side JAAS login module will use windows domain session key/ticket, the server side login module will validate it against windows domain controller during the first authentication, use this ticket from it's own cache on the further calls authentication). But how GSS-API with Kerberos corresponds to it? > - In such single sign-on context the password of the user is not transmitted > on the wire (only a ticket is), so it is already more secure than any other > solution that do not use an encrypted channel. No, it is not so. It is not more secure then any other solution. There are a lot of other mechanisms based on the similar algorithms (and SRP is an example of it). > - If you want bullet proof security, nothing prevents you to configure SSL > between your client and server on top of this authentication mechanism. I think yes. Alexander View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3856411#3856411 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3856411 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
