Implementing the GSS with Initiators and Acceptors
Listings 17-1 and 17-2 contain the code for both the initiator and acceptor. There are two major differences between the initiator and acceptor in the listings: the credential set and the peer that is initiating the security context. The credential set is different simply because the initiator will use the credentials of the client or other initiating authentication such as JAAS. The acceptor credentials could be a delegation of the initiator's credentials, or the server's principal and credentials, depending on the resources' permissions. Server principals are normally needed when the client principals are restrictive , such as when accessing an organization's database. As mentioned before, it is up to the application to use any additional functionality to transport the messages such as Java sockets. The GSS-API handles the following, but not the transport mechanisms other than byte arrays and Java streams:
The preceding is the basic functionality of the GSS-API, and the how the Java stream or byte array is transported is independent of the GSS-API itself. The GSS-API could be transported through files, sockets, or even JSSE.
The initiator starts the security context by establishing the user 's credential, the server's name for identification, and the authentication mechanism for creating the security context. After the security context is created, the context tokens must be passed between the initiator and the acceptor, which is normally accomplished in a context loop. The initiator creates an initialization token with the initSecContext method and writes the token to the acceptor. The acceptor, in turn , reads the token and checks to see if the token is acceptable with the acceptSecContext method. If the token is not acceptable, a GSSException is thrown. If the token is acceptable from the acceptor, the acceptSecContext method modifies the token with the server's credentials and the acceptor sends the token back to the initiator to confirm initialization. After the token has been processed by the initiator and the acceptor methods for initializing and accepting the token, the isEstablished flag in both security contexts is set to true to state that the security context has authenticated and is ready to wrap and unwrap messages. Once the security context has been authenticated, only the security context between the peers can wrap and unwrap the messages. In other words, only the security contexts that are authenticated can access, or unwrap, the encrypted message. Once a message is wrapped, the token with the message in it is passed to the peer. Part of the wrap is not only the message but also information about the message and the security's context passed between peers. Only the established peers can unwrap the message. By providing the confidentiality, the GSS-API provides authorization for authenticated security contexts to access the plaintext message after it is wrapped.
 Java Security Solutions ISBN: 0764549286
EAN: 2147483647 Year: 2001
Pages: 222 Authors: Rich Helton, Johennie Helton
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |
