Security with Java Cryptography Architecture
In the last week I was going through some discussions on how to provide security on our new application we are building at Scali AS. In our architecture the server is a C deamon which uses OpenSSL for security where as the client is a Java RCP which uses JSSE.
One observation I had in working with java security frameworks is that Java has lot of Security components, but most of the developers has no very clear understanding of where those components fits in to the application requirement they have. So I thought of having a blog post which introduces the Java security components and their usage.
Here we go... Broadly there are several components belonging to the Java Cryptography Architecture (JCA) (or simply Java Security). JCA can be divided in to several sub categories as follows :
a) Java Authentication and Authorization Services (JAAS)
b) Java Secure Socket Extension (JSSE)
c) Java Cryptography Extension (JCE)
d) General Security Services (Java GSS-API)
e) Java Certification Path API
f) Java Simple Authentication and Secure Layer (Java SASL)
JAAS is the Java solution (framework) for authenticating and authorization uses and services. JAAS provides user-centric as well as code-centric access control mechanisms. JAAS can be considered as a framework and an API focused mainly for non-connection oriented (stand-alone) application security. It is not about encrypting data but it is a implementation neutral API for authentication and authorization (For an example if we decide to move our usernames/passwords from a properties file to a database, still JAAS wil allow us to do this with out changing application code).
JAAS authentication mechanism is pluggable so vendors/users may write there own ‘login modules’ to read/validate authentication credentials from their preferred source (e.g. database, directory service). As I know, JDK does not provide many default ‘login modules’ but generally application servers come-up with several reusable login modules such for reading “prop-files”, “simple database tables”, etc...
JSSE provides a framework and implementation for securing your data in network communications by introducing security later on top of TCP/IP. J2SDK 1.4 onwards supports SSL 3.0 and TCL 1.0 protocols. The most popular SSL model used on internet is to authenticate only the server identity and use encryption on data. Client identity is authenticated using username/password provided by the client (e.g. a typical e-commerce web-site) JSSE provides a convenient API on top of java sockets for enabling your TCP connection security.
JCE consists of a framework defining java security components such as data encriptors, key generators, etc… Sun has provides a default implementation called “SunJCE” for this framework (For example RSA, DES encryption algorithms, DES key generators are provided with the ‘SunJCE’ provider). We may use this default SunJCE (any other third party provider) to provide some cryptographic operation such as encrypting a data stream using “DES symmetric key” encryption.
Java GSS-API allows java developers to make their programs to work with Kerberos based authentication. Similar to JSSE, GSS-API provides authentication, encryption and integrity protection on your data. The underline mechanism used is the widely known Kerberos security model. Kerberos provides strong token based security and supports single sign-on capabilities for the applications. (GSS API mechanism is defined as a Internet Standard under RFC2853)
Java Certification path consists of abstract framework classes which allows user to create, validate, manipulate ‘Certification Chains’. Certification chain is a ordered list of certificates which will establish a trustable mapping from ones identity to his ‘public key’. Java Certification Path API also consists of a default implementation for working with X.509 certificates.
Java SASL is the java implementation of the SASL internet standard defined under RFC2222. As the name suggest the SASL standard also provides authentication and secure transmission of data (so it also can be categorize with GSS and JSSE). SASL is defined to be a light weight protocol and used by LDAP and IMAP implementations. Thus any application intended to work with those applications may need Java SASL API for security integration.
Thus the bottom line is that, we should decide on the technology to be used based on our application context. As a rough example if my application is TCP socket based I may go for JSSE, if my organization security is Kerberos based then I go for GSS-API, if I need to communicate with a LDAP service I may need to consider Java SASL API and so on…