This proposal has been approved and the Eclipse Exousia project has been created.
Visit the project page for the latest information and development.

Eclipse Exousia

Wednesday, March 10, 2021 - 18:45 by Arjan Tijms
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Working Group
Proposal State
Created
Background

Many Jakarta specifications have a standalone implementation, but not all. Jakarta Authorization is a spec that does not have a standalone implementation. Instead an implementation is embedded within GlassFish, which is for the advancement and maintenance of the spec suboptimal. As project lead of Jakarta Authorization and as a GlassFish committer I've created an initial standalone project based on the GlassFish embedded code, which can be used to seed the new project with.



As that code comes from the GlassFish project, which is already at Eclipse, this is largely a restructuring review. We will split the implementation out from the existing GlassFish project into its own separate Eclipse open source project. Specifically, the directory containing the implementation code for the default authorization module (https://github.com/eclipse-ee4j/glassfish/tree/master/appserver/security/inmemory.jacc.provider) and the algorithms (https://github.com/eclipse-ee4j/glassfish/tree/master/appserver/security/core-ee/src/main/java/com/sun/enterprise/security/authorize among others) will be split from the GlassFish project into a separate repository managed by the new project.

Scope

Eclipse Exousia provides an implementation of the Jakarta Authorization specification.

Description

Eclipse Exousia implements Jakarta Authorization, a technology that defines a low-level SPI for authorization modules, which are repositories of permissions facilitating subject based security by determining whether a given subject has a given permission, and algorithms to transform security constraints for specific containers (such as Jakarta- Servlet or Enterprise Beans) into these permissions.



Eclipse Exousia provides default implementations of these authorization modules and algorithms, as defined and mandated by the Jakarta Authorization specification.

Why Here?

Eclipse EE4J is the home of GlassFish. The restructured code should remain in the same community, just in a separate project.

Project Scheduling

The initial contribution will be made immidiately after the project has been approved. The first build will be expected in a few weeks, after which the intention is to remove the code that was moved to this project from GlassFish, and add a dependency from GlassFish to this project.

Future Work

The functionality to add will follow the requirements of the Jakarta Authorization specification, which on its turn will largely follow the requirements and direction set by the Jakarta platform specification and the Jakarta Security specification.

Community growth around the project is thought to be faciliatated by the fact that the standalone implementation will also work on servlet containers like Apache Tomcat, Piranha Cloud and potentially Eclipse Jetty. The project will not intend to provide features not covered by the Jakarta Authorization specification, but instead will make sure that it integrates well with servers like GlassFish and Tomcat.

Project Leads
Mentors
Initial Contribution

The project's existing code will come from https://github.com/omnifaces/exousia This repositry on its turn has been created from a combination of my own code and the above mentioned code from the GlassFish project. For instance, see files such as these: https://github.com/omnifaces/exousia/blob/master/src/main/java/org/omnifaces/exousia/permissions/RolesToPermissionsTransformer.java

Source Repository Type

If this is being extracted from GlassFish then some additional GlassFish committers should be added as committers otherwise we will be unable to maintain the core authorisation code in the server.