Find JSRs
Submit this Search

Ad Banner

JSRs: Java Specification Requests
JSR 85: Rules-based Authorization and Audit

This JSR has been Rejected
Reason: This JSR was not approved by the SE/EE Executive Committee in the JSR Approval Ballot.

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Title: Rules-based Authorization and Audit

Define an API for managing and accessing a rules-based authorization and audit trail service.

Section 1. Identification

Submitting Member: Entegrity Solutions

Name of Contact Person: Hal Lockhart

E-Mail Address:

Telephone Number: 508-624-9600 x260

Fax Number: 508-229-0338

Specification Lead: Hal Lockhart

E-Mail Address:

Telephone Number: 508-624-9600 x260

Fax Number: 508-229-0338

Initial Expert Group Membership:
Entegrity Solutions

Section 2: Request

2.1 Please describe the proposed Specification:

Define service which propagates credentials of requesting party and allows authorization and audit decisions to be made by evaluation of rules which consider not only simple identity aggregators like group and role, but environmental factors, such as time, location and communication protection used and application specific information, such as approval limit. Also define API for administering rules and other elements.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)


2.3 What need of the Java community will be addressed by the proposed specification?

More flexible, consistent and fully specified model for remote authorization and audit trail

2.4 Why isn't this need met by existing specifications?

Current JAAS and EJB security specifications conflict and overlap. Both are based only on simple permissions model.

Current Java RMI Security specification implies an authorization model in which applications specify security policies "on the fly". We believe a superior approach is to move security policy out to an external non-volatile store which can be modified by applications and/or management tools. This has a number of benefits.

? It allows developers to get the benefits of strong, flexible security mechanisms without having to write a lot of security code

? It gives organizations the flexibility to evolve security policies without having to modify source code

? It allows security specialists to define and verify security policies as apposed to requiring developers to also be security experts

? It allows organizations to more easily implement sound and consistent policies across all applications.

2.5 Please give a short description of the underlying technology or technologies:

Mostly traditional mechanisms for authorization, audit trail. Key component is authorization engine which underlies a number of commercial products, including Entegrity's AssureAccess.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)


2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?


2.8 Are there any security issues that cannot be addressed by the current security model?

Yes, see comments above.

2.9 Are there any internationalization or localization issues?


2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

JAAS, EJB Security, J2EE Security Requirements, JSR 76 (RMI Security)

2.11 Please describe the anticipated schedule for the development of this specification.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

Entegrity AssureAccess API Specification

3.2 Explanation of how these items might be used as a starting point for the work.

Provides a model of such a service, which has been implemented.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.

JSR-000085 Rules-based Authorization and Audit javadoc

We are seeking the advice of the Java Community as to the best way to proceed. We strongly feel this type of rules-based authorization is needed. We have implemented the current EJB security model in our products. Our customers are asking for JAAS, but we have not been able to resolve the conflicts between it and EJB. There may be a relationship between this and the RMI security work, but we are not sure. We also feel that the "managed policy store" model is superior to the "on the fly" model for authorization.