Proposal
This JSR has been Rejected.
Reason: This JSR was not approved by the SE/EE Executive Committee in the JSR Approval Ballot.
Identification |
Request |
Contributions |
Additional Information
Title: Rules-based
Authorization and Audit Summary: Section 1. Identification Submitting Member: Entegrity Solutions Name of Contact Person: Hal Lockhart E-Mail Address: hal.lockhart@entegrity.com Telephone Number: 508-624-9600 x260 Fax Number: 508-229-0338 Specification Lead: Hal Lockhart E-Mail Address: hal.lockhart@entegrity.com Telephone Number: 508-624-9600 x260 Fax Number: 508-229-0338 Initial Expert Group Membership: Section 2: Request Server More flexible, consistent and fully specified model for remote
authorization and audit trail 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. Mostly traditional mechanisms for authorization, audit trail. Key
component is authorization engine which underlies a number of commercial
products, including Entegrity's AssureAccess. TBD No Yes, see comments above. No JAAS, EJB Security, J2EE Security Requirements, JSR 76 (RMI Security) Section 3: Contributions Entegrity AssureAccess API Specification Provides a model of such a service, which has been implemented. Section 4: Additional Information
(Optional) 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.
Define an API for managing and accessing a rules-based authorization and
audit trail service.
Entegrity Solutions
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?
2.4 Why isn't this need met by existing specifications?
2.5 Please give a short description of the underlying technology or technologies:
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?
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?
2.11 Please describe the anticipated schedule for the development of
this specification.
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.
3.2 Explanation of how these items might be used as a starting point
for the work.
4.1 This section contains any additional information that the
submitting Member wishes to include in the JSR.