Home · About · A-Z Index · Search · Contacts · Press · Register · Login

Security Forum

Return to Security home page

Current work:

- Managers Guides

- MGIS

- Data Privacy

- PKI

- Guide to PKI

- Identity Mgt

- Access Control

- Security Patterns

- Secure Messaging

Strategy/Roadmap

Useful links:

Security topics

Info sources

Liaisons

How we work

Open Group Security Standards/Guides

Historically, Java™ security has been considered in terms of providing a sandbox, or virtual machine, restricting the capabilities of downloaded "applet" code in order to limit the potential damage that code could cause.  Java is now increasingly being used in other environments – while the concept of mobile code is still an important one, Java code is also used in stand-alone application programs, on both sides of client-server applications, and as part of distributed service architectures. 

The Java security model has evolved along with this wider usage to include several factors in access control decisions, such as the origin of object classes (both physical location and originator/author), the execution context (which other classes were involved in invoking the operation) and the principals (such as a human user's identity).

The foundation of the Java security model is that objects are themselves responsible for protecting resources which they encapsulate, by defining a permission class to represent the access rights, and invoking a shared security manager object to determine if a caller has been granted access rights to a specific resource instance.  This type of programmatic access control has been complemented in the Java 2 Platform Enterprise Edition (J2EE™) by the notion of declarative security, that is access control of reusable application components enforced by object containers according to security roles defined when the application is deployed.  Declarative security removes the need for application component providers to implement their own security controls, and allows a consistent security policy to be defined even for applications constructed from multiple vendors' components.

Recent developments in Java security include a specification effort to unify the enforcement mechanisms used by objects to protect their own resources and by containers to protect application components, allowing third-party security policy engines and security management tools to be used.   That specification is being developed within the Java Community Process^SM (see http://www.jcp.org/jsr/detail/115.jsp).  

The Open Group Security Forum is not currently engaged in any work items focused specifically on Java security, although Java security classes will be covered in several of the "Known Implementations" sections in the Guide to Security Patterns.

Java Security Links

• Java 2 Security Guide
• Java 2 Security Tutorial
• Java Security Coding Guidlines
• Java Authentication and Authorization Service (JAAS)
• Java Secure Socket Extension (JSSE)

Recommended Books

• Li Gong:  Inside Java 2 Platform Security - Architecture, API Design, and Implementation
• Jaworski & Perrone:  Java Security Handbook

Java Security Discussion Groups

• Mailing List Archive:  java-security@discuss.develop.com (open list)
• Mailing List Archive:  java-security@sun.com (closed list)
• News Group:  comp.lang.java.security
• Java Forum:  Security General
• Java Forum:  Security Managers

Java and J2EE are trademarks of Sun Microsystems, Inc.
Java Community Process is a service mark of Sun Microsystems, Inc.

Craig Heath, 22 Oct 2001

Events

Next meeting
Past meetings

Other Conferences and Shows

Members Only

Enter Here

Who to Contact

Enter Here