|
Java security, Part 1: Crypto basics
The Java platform, both its base language features and library extensions, provides an excellent base for writing secure applications. In this tutorial, the first of two parts on Java security, Brad Rubin guides you through the basics of cryptography and how it is implemented in the Java programming language, using plenty of code examples to illustrate the concepts.
|
|
Java security, Part 2: Authentication and authorization
This tutorial explains the use of the Java Secure Socket Extension (JSSE) packages included in JDK 1.4. The complexity of using JSSE is not in the communication itself, but rather in the configuration. Before you can run your client/server software, you must create the keys needed by the encryption algorithms, and these keys must be properly loaded by your software before it can create secure sockets. This tutorial provides cookbook-style instructions for creating and installing JSSE encryption keys in a client/server application environment.
|
|
Using JSSE for secure socket communication
The Java platform, both its base language features and library extensions, provides an excellent base for writing secure applications. In this tutorial, Part 2 of 2, Brad Rubin introduces the basic concepts of authentication and authorization and provides an architectural overview of JAAS. Through the use of a sample application, he'll guide your understanding of JAAS from theory to practice. By the end of the tutorial you will have a good foundation for working with JAAS on your own.
|
|
How to lock down your Java code (or open up someone else's)
Whether you're patching in code from one of the many open-source libraries on the Web or making calls to common operating system routines, you inevitably spend some part of your week crunching code that you didn't write, and for which you may not have the source.
|
|
Java security evolution, Part 1
In this two-part series on Java security, Sing Li shows developers that even though the community might have to rethink security designs with the release of JDK 1.2, a unified evolution has taken place that can only serve to benefit developers and their needs.
|
|
Java security evolution, Part 2
In part 2 of this series, Sing Li continues his discussion of the Java security model by exploring the totally new, fine-grained control security model unifying applet and application security in JDK 1.2.
|
|
Java security evolution and concepts, Part 5
In Parts 1 through 4 of this series on Java security, Raghavan N. Srinivas discussed network and Java security concepts; Part 3 took a detailed look at applet security and optional packages. In this article, Raghavan introduces J2SE (Java 2 Platform, Standard Edition) 1.4's new security packages for certificate chain manipulation, along with Generic Security Services, which includes a single sign-on framework over the network
|
|
Understanding the keys to Java security -- the sandbox and authentication
Security concerns are important for Java (and other systems for executable content, like ActiveX). When new flaws like the recently announced code-signing hole are discovered, the press often covers the story without much depth. We think it is important to explain Java security holes and antidotes in their proper context.
|
|
In Java we trust
The Java Security API makes it a simple matter to add security and authentication to your application. The result is an application that knows what and whom it can trust. This month, Todd delves into the Java Security API and demonstrates how to generate message digests, keys, and digital signatures
|
|
Java security evolution and concepts, Part 4
In Parts 1 through 3 of this series, Raghavan Srinivas discussed network and Java security concepts, including a detailed look at applet security. In this article, the fourth and last in the series, he details the optional, yet important, packages that enhance Java security. Bonus: A working applet to demonstrate this article's concepts
|
|
Java security evolution and concepts, Part 3: Applet security
In Parts 1 and 2 of this series, Raghavan Srinivas discussed concepts of network and Java security. In this third installment, he'll take a look at the challenges of security for, and the deployment of, applets. Get lots of popcorn and beer and work with the article patiently, since rough terrain lies ahead. It's assumed that you are familiar with the concepts presented in the first two parts of this series
|
|
The evolution of Java security
This paper provides a high-level overview of the development and evolution of Java security. Java is a maturing technology that has evolved from its commercial origins as a browser-based scripting tool. We review the various deployment environments in which Java is being targeted, some of its run-time characteristics, the security features in the current releases of the base technology, the new Java Development Kit (JDK) 1.2 policy-based security model, limitations of stack-based authorization security models, general security requirements, and future directions that Java security might take.
|
|
Trusting your e-mail with Java security
Internet transactions, especially messages, are the lifeblood of e-business. Ensuring their security is a requirement, not a luxury, for sensitive transactions.
|
|
JavaTM Security Evolution and Concepts, Part 4:
Optional Packages
In Parts 1 through 3 of this series, Raghavan Srinivas discussed network and Java security concepts, including a detailed look at applet security. In this article, the fourth and last in the series, he details the optional, yet important, packages that enhance Java security.
|
|
Java Security
Java is a new programming language from Sun Microsystems (currently in beta release). The Java language has a number of interesting properties. One property is that it is intended to be portable, even to the extent that programs can be dynamically loaded over the network and run locally.
|
|
Java security: How to install the security manager and customize your security policy
One of the primary reasons Java technology is a "good fit" for networks is that it has a comprehensive security model designed into its architecture
|
|
Java's security architecture
One of the primary reasons Java technology is a "good fit" for networks is that it has a comprehensive security model designed into its architecture
|
|
Java security evolution, Part 1
In this two-part series on Java security, Sing Li shows developers that even though the community might have to rethink security designs with the release of JDK 1.2, a unified evolution has taken place that can only serve to benefit developers and their needs
|
|
Java security evolution, Part 2
In this two-part series on Java security, Sing Li shows developers that even though the community might have to rethink security designs with the release of JDK 1.2, a unified evolution has taken place that can only serve to benefit developers and their needs
|
|
Java security evolution and concepts, Part 3: Applet security
In Parts 1 and 2 of this series, Raghavan Srinivas discussed concepts of network and Java security. In this third installment, he'll take a look at the challenges of security for, and the deployment of, applets. Get lots of popcorn and beer and work with the article patiently, since rough terrain lies ahead. It's assumed that you are familiar with the concepts presented in the first two parts of this series.
|
|
Java Security Models
The new category of Web content: dynamically loaded executable code run on client's local CPU, raises new security concerns in the Internet community.
|
|
Applet Security
The goal for the JDK is to enable browsers to run untrusted applets in a trusted environment. Our approach is to be conservative at first, and to add functionality when it can be added securely. The intent is to prevent applets from inspecting or changing files on the client file system. Also, the intent is to prevent applets from using network connections to circumvent file protections or people's expectations of privacy.
|
|
Low Level Security in Java
The Java(tm) language allows Java-compatible Web browsers to download code fragments dynamically and then to execute those code fragments locally. However, users must be wary of executing any code that comes from untrusted sources or that passes through an insecure network.
|
|
Java Security: From HotJava to Netscape and Beyond
The introduction of Java applets has taken the World Wide Web by storm. Information servers can customize the presentation of their content with server-supplied code which executes inside the Web browser. We examine the Java language and both the HotJava and Netscape browsers which support it, and find a significant number of flaws which compromise their security
|
|
Java Security: Web Browsers and Beyond
The introduction of Java applets has taken the World Wide Web by storm. Java allows web creators to embellish their content with arbitrary programs which execute in the web browser, whether for simple animations or complex front-ends to other services. We examined the Java language and the Sun HotJava, Netscape Navigator, and Microsoft Internet Explorer browsers which support it, and found a significant number of flaws which compromise their securit
|
|
Java Security Joseph A. Bank Approach
Java is a new programming language from Sun Microsystems (currently in beta release). The Java language has a number of interesting properties. One property is that it is intended to be portable, even to the extent that programs can be dynamically loaded over the network and run locally. In particular, small programs called applets can be loaded and run by a user's WWW browser while the user is ``surfing'' the Web (HotJava is such a browser written in Java, and Netscape2.0 will support Java applets). While this idea is very powerful, it is also an invitation to security problems. The Java language and runtime system (which includes libraries, the compiler, and the bytecode interpreter) attempt to address these security issues, with the result that Sun claims Java will be secure.
|
|
Security Reference Model for
the Java Developer's Kit 1.0.2
The model first defines the classes of model components; that is, a Java applet, Java-enabled application, Java Virtual Machine (JVM), client platform, server platform, and server. Each of these components is trusted in varying degrees to preserve overall system security
|
|
A Comparison between Java and ActiveX Security
ActiveX and Java have both been the subject of press reports describing security bugs in their implementations, but there has been less consideration of the security impact of their different designs. This paper asks the questions: "Would ActiveX or Java be secure if all implementation bugs were fixed?", and if not, "How difficult are the remaining problems to overcome?".
|
|
Secure a Web application, Java-style
The string of recent denial-of-service attacks has renewed interest in the security of Internet-based applications. As the Web matures and program functionality increases, the security needs of applications are becoming exceedingly important. Spanning from online brokerage firms to grocery delivery via the Web, applications must allay the privacy and security concerns of the customers who use them. This article explores the major concepts of security and develops a pattern through which you can secure your applications.
|
|
AS/400 Java Application Models
This document describes four primary AS/400 Java Application Models. Each model represents a different runtime execution environment for server Java applications. The purpose of this document is to give you a mental framework for the structure of your application and to provide a point of reference for discussions on performance, security, and interoperability.
|
|
Enhance Java GSSAPI with a login interface using JAAS
In this article, software engineer Thomas Owusu builds on his introduction to Java GSSAPI and describes how a Java GSSAPI can be enhanced with a login interface using the Java Authentication and Authorization Service (JAAS), a pluggable, modular authentication and authorization Java infrastructure. Using a Java GSSAPI Kerberos mechanism as an example, Thomas discusses a Kerberos JAAS login module that provides an interface for a Java GSSAPI principal to log into a Kerberos system. He also discusses how Java GSSAPI can use the JAAS Subject as a central repository for credentials including server secret keys.
|
|
Single Sign On Support in WebSphere Portal Server 1.2
WebSphereŽ Portal Server is a rendering and run-time environment that presents a dense but organized and filtered user interface. The WebSphere Portal Server supports the integration of applications into this user interface through "portlets," which can be thought of as executable agents within the portal for applications. A portlet is responsible, among other things, for interacting with its "backend application" in order to produce a rendering (in HTML, WML, or other markup) suitable for inclusion in the encompassing portal page. In other words, a portlet may be seen as a Web application for the WebSphere Portal Server. And rather than it taking up the entire page, the portlet may share the page with other portlets or applications.
|
|
Securing systems, Part 1: Using Java technology in high-stakes systems
As J2EE-based systems become more prevalent, and sensitive data is more commonplace, the ability to effectively secure and manage Internet-accessible systems ceases to be a luxury and becomes a necessity. This general overview -- the first in a series of articles -- examines how Java technology can be used to secure systems in which the consequences of mistaken identity can be particularly destructive. Later articles will discuss methods to secure information in transit, the need for mechanisms to prevent repudiation of transactions, and techniques for establishing and verifying identity to minimize the chance of accidental or deliberate misuse.
|
|
Securing Systems: A three-pronged solution for identifying users
The problem of system security starts with discovering the identity of the user on the other end of the communications link. In this article, Joseph Sinclair discusses three familiar approaches for identifying users, highlights their strengths and weaknesses (alone and in combinations), and provides some examples of each.
|
|
Make your software behave: Security by obscurity
Many businesses choose to hide their code in an attempt to keep software secrets out of the hands of hackers. But keeping this information hidden isn't always as easy as it seems, and even if the information is successfully obscured, there are plenty of other ways for hackers to find security vulnerabilities.
|
|
Unshackling key management in Java security
As part of building a Web of trust in the unsecured world of the Internet, users and developers need to utilize public and private key pairs. These unique key pair combinations give users the ability to sign and encrypt data in an authenticated, verifiable, and secure fashion. Public keys are typically stored in certificate objects, rather than alone. Users and developers may deal with many certificates and may have more than one private key that they use to sign and encrypt or decrypt data. This article reveals an important vault of information in Java security, the KeyStore, which allows users and developers to consolidate and manage their various certificates and keys.
|
|
The practice of peer-to-peer computing: Trust and security in peer-to-peer networks
As soon as a P2P application grows to the point where it becomes interesting, the issues of trust and security appear on the horizon. Trust and security are seldom problems in small applications where every user knows every other user. Useful P2P applications seldom remain that small, however. This month, Java architect Todd Sundsted explores issues of trust and security in P2P applications, and introduces you to the tools that make trust possible in distributed applications.
|
|
Extensible Security Architectures for Java
Mobile code technologies such as Java, JavaScript, and ActiveX generally limit all programs to a single restrictive security policy. However, software-based protection can allow for more extensible security models, with potentially significant performance improvements over traditional hardware-based solutions.
|
|
Extensible Security Architectures for Java
Mobile code technologies such as Java, JavaScript, and ActiveX generally limit all programs to a single restrictive security policy. However, software-based protection can allow for more extensible security models, with potentially significant performance improvements over traditional hardware-based solutions.
|
|
Exploring Java and Internet security
This technical article was originally published a previous issue of the IBM DeveloperToolbox Technical Magazine. Subscribe to the IBM developerWorks journal for the latest technical articles on open standards-based technologies that are available to you offline in a printed publication.
|
|
Securing Linux for Java services
Enterprise Java expert Dennis Sosnoski starts with his view of how Java server technologies fit with Linux, then gives pointers on setting up the Tomcat Java servlet engine on Linux -- securely.
|
|
Software security for developers: One-time pads
In this installment, Gary and John examine the one-time pad, which, if used properly, is an unbreakable encryption algorithm. The one-time pad has proven popular with spies, and its history predates World War II -- but does it actually make sense for real software applications?
|