ClientAuthentication questions
Mark Brouwer <[email protected]>
| Newsgroups | gmane.comp.java.sun.jini |
|---|---|
| Message-ID | <[email protected]> |
In case of secure JERI I wonder when you specify ClientAuthentication.YES uniform for all methods as part of the server constraints whether a cipher suite is enforced by the server that demands the client to authenticate, I admit I don't even know whether there is a cipher suite that enforces this (was not that obvious from the TLS RFC), if not is there another mechanism used that enforces client authentication. I have the feeling that client authentication is not enforced in this way because you might 'reuse' a secure server endpoint for multiple exports and sometimes you can have methods for which client authentication is not required. I'm aware that ClientAuthentication.YES can be enforced on the proxy by the server constraints, but this can be by-passed by a malicious client by communicating directly to the ServerEndpoint. Therefore I assume that access control is the only 'real' protection, however that introduces a problem for what I'm trying to accomplish. I understand access control can be disabled (in case of BasicInvocationDispatcher) by granting an AccessControlPermission for all protection domain. Also you can grant AccessPermission for a particular principal that is part of the client subject. However I miss the way to say "I grant permission to invoke a particular method for *any* trusted principal". In some cases you don't know all the principals in advance (PKIX TrustManager) or it doesn't scale very well if you have hundreds of thousands of clients (which is not quite uncommon in a PKI infrastructure) and you have to grant permissions for each of them. In case I'm correct would be the path to follow is extending BasicInvocationDispatcher and override checkAccess() and then do whatever I need to do to express that kind of permissions, which probably means that I will bypass the usage of a security policy based access control mechanism altogether and also go for access permissions that can work on a more granular level, i.e. can differentiate between methods that have the same name but differ in parameters[1]. [1] anyone felt the need to control access permissions on a more granular level than what is currently available through AccessPermission, if so please let it know. -- Mark -------------------------------------------------------------------------- Getting Started: http://www.jini.org/wiki/Category:Getting_Started Community Web Site: http://jini.org jini-users Archive: http://archives.java.sun.com/archives/jini-users.html Unsubscribing: email "signoff JINI-USERS" to [email protected]