Security - K2


	Overview
	Technical Features
	Clustering
	Load Balancing
	Fault Tolerance
	Security
	Management
	Deployment
	Benefits
	Reviews and Comments
	Developers Forum
	Contact
	Order Now

Unique Features of K2

Integration with Legacy

The K2 Deployment Architecture allows also deploying of legacy applications using the same package and descriptor approach described previously.

More Details

Inter-working between CORBA and EJB components

For application development in an EJB environment, EJB-CCM Bridge allows an EJB client to communicate with CCM component through an EJB view. The process of implementing EJB-CCM Bridge

More Details

The current security implementation of K2 is based on SSL inclusive client and server authentication (see Figure). A client that wants to gain access to the server must authenticate itself using an ID that is signed by a Certificate. The K2daemon and the associated server process must trust that certificate. Usually this certificate is a K2 certificate but it is possible to configure multiple trusted certificates within the server.

In the same way the client might request server authentication, in which case the client can deny of working with a server whose certificate is not authentic.

This security implementation is a coarse grained model that either grants or denies access to the server. There are no fine grained security policies.

Figure 6 K2 Security Implementation