The Internet originally interconnected a small number of computers at universities and research labs. It was used to share resources and to send e-mail - an incidental application that over time grew into one of the major uses of the network. Everyone knew everyone else, and security was far from the priority that it is today. All this has now changed....
These days, security is a top priority for ISPs and consumers alike. Hundreds of millions of people are now connected to the Internet and items of tremendous value are at risk daily - from stocks and bonds to military and government secrets.
Security comes to mind as the topic for this month's CORBA Corner because every spring the Object Management Group hosts a workshop on Distributed Object Computing Security, or DOCSEC. This year's conference was also cosponsored by the National Security Agency (NSA) - which has been involved in every workshop since their inception - and by Concept 5 Technologies. Because so many vendors and serious security users get together to describe their experiences at this workshop, it provides an excellent opportunity to sum up the state of distributed object security. I'm starting this column with descriptions of a few standard distributed-security architectures to establish a base; then I'll summarize key points from the conference.
Security in Java and EJB
In Java, network security is commonly provided by the Secure Sockets Layer, which adds a secure network connection to the Java "sandbox." The SSL implementation - depending on the cipher suite - provides identification and authentication (primarily authenticating the server to the client), and may protect messages against interception (by encryption), modification (with a checksum) and replay (with a timestamp).
Chapter 15 of the Enterprise JavaBeans 1.1 specification defines a somewhat richer security architecture, albeit with a looser set of rules. Fundamentally, it places responsibility for security on the container (and therefore on the container provider), removing the burden from the application developer and allowing security policies to be set and changed at assembly or deployment time rather than development time. Security functionality includes individual privileges, group privileges and delegation, although the details are left to the container, which in addition defines the principle and its format. Because the EJB security model is defined in terms of a single container environment, it doesn't define a network protocol nor does it tell how to spread a security umbrella over containers from multiple vendors.
CORBAsecurity
CORBAsecurity defines a much richer security architecture. As with SSL, it starts with identification and authentication of the client, the user (without restricting the authentication mechanism, which might be a password, code card or a biocharacteristic such as thumbprint or retina scan) and the server to ensure that the client isn't talking to a "Trojan horse." It also places a checksum on the message to protect against modification, encrypts it to protect against interception and includes a timestamp to protect against replay.
