The authorization from jakartaee

Add support for Servlet deny uncovereed method flag

In Servlet Security Constraint configuration, HTTP methods may be left uncovered in the following
three ways:

1. a security constraint names one or more HTTP methods in http-method elements.
All methods other than those named in the constraint are uncovered.

2. a security constraint names one or more HTTP methods in http-method-omission elements.
All methods that are named in the constraint are uncovered.

3. a @ServletSecurity annotation includes one or more HttpMethodConstraint objects,
each naming an HTTP method, and the top level HTTPConstraint that applies to all other
methods is indistinct from the default value which defines no protection requirements.
This case is analogous to case 1, and all methods other than those named in the
HTTPMethodConstraint objects are uncovered by the annotation.
fwiw, The setServletSecurity api can be used to achieve an analogous effect.

Servlet has proposed the definition of an optional flag in web.xml that when set for an app,
will cause, following constraint combination, any remaining uncovered methods (resulting from
any of the above causes), to be configured as denied. This conversion is consistent with the
recommendation that all methods be covered in constraint definition.

For JACC the issue is to enhance the Policy Configuration contract to perform the processing necessary to support the new Servlet flag

Adjust groupId with authentication and security-api

I saw the case for jakarta.security.enterprise in Security API for the root package, to tell it apart from this, but the GroupId here sounds a little inconsistent. It matches the package for Jakarta Security but here it's just jakarta.authorization.
Could we either have all of them with "jakarta.security" like the package, so jakarta.security.authorization?

PolicyConfigurationFactory.getPolicyConfigurationFactory() is not thread safe.

As this method is responsible for creating the singleton PolicyConfigurationFactory if it is called more than once concurrently multiple instances can be created.

PolicyConfigurationFactory too eager to catch ClassCastException

There are multiple lines which could throw an Exception whilst creating and casting the PolicyConfigurationFactory:

https://github.com/eclipse-ee4j/authorization/blob/2.0.0-RC1-RELEASE/api/src/main/java/jakarta/security/jacc/PolicyConfigurationFactory.java#L125-L139

If a ClassCastException is thrown creating the instance of the PolicyConfigurationFactory then the reported error will claim the class instantiated is no a PolicyConfigurationFactory which is not true.

Build failure with missing dependency

Hi,

was reviewing for Jakarta EE 9 and wanted to build it all from scratch but looks like it's failing for me.

Steps

rm -rf ~/.m2/repository
git clone [email protected]:eclipse-ee4j/authorization.git
mvn clean install

This gives me

[ERROR] Failed to execute goal on project jakarta.authorization-api: Could not resolve dependencies for project jakarta.authorization:jakarta.authorization-api:jar:2.0-SNAPSHOT: Could not find artifact jakarta.servlet:jakarta.servlet-api:jar:5.0.0 in central (https://repo.maven.apache.org/maven2)

Add methods to the PolicyConfiguration to read permissions

The current contract of the PolicyConfiguration only allows to add permissions to it, but has no standard facilities to read them back.

A Policy that just wants to use the configured permissions, without any assumption of a transformation having taking place (e.g. to a permissions file on disk), must therefor know the specific PolicyConfiguration being used.

Additionally, for use cases where permissions are added dynamically, being able to read the permissions to see what's already been added would be a great benefit.

Proposal is to add 3 straightforward methods as follows:

    public Permissions getExcludedPermissions();
    
    public Permissions getUncheckedPermissions();
 
    public Map<String, Permissions> getPerRolePermissions();

Why not simply drop Jakarta Authorization in favor of new features in other specs?

We have very little usage of Authorization in Wildfly and EAP. With the need to completely revamp this spec do to JEP 411 changes, why not simply deprecate and remove JACC from the platform? Other cloud friendly authorization schemes can be developed as part of Jakarta Security.

incompatible change to PolicyContext.getHandlerKeys

PolicyContext.getHandlerKeys was changed to return Set<String> instead of Set.
The TCK signature test considers this an incompatible change to the signature
of the method:

Missing Methods
---------------

javax.security.jacc.PolicyContext:      method public final static java.util.Set javax.security.jacc.PolicyContext.getHandlerKeys()

Added Methods
-------------

javax.security.jacc.PolicyContext:      method public final static java.util.Set<java.lang.String> javax.security.jacc.PolicyContext.getHandlerKeys()

This change needs to be reverted.

Jakarta EE 8 TCK job

To test Jakarta EE 8 compatibility we need to create a Jenkins job on project's Cloud Jenkins instance formally testing the API against the relevant TCK and as needed, relevant CTS subset tests.

For projects that do not already have automated testing, there is provided parameterized Jenkins job that can be invoked to perform these tests. User provides a link to an Eclipse GlassFish test build and sets the test sub-set parameters:

For CTS -- https://ci.eclipse.org/jakartaee-tck/job/jakartaeetck-certification/
For Stand-alone TCKs -- https://ci.eclipse.org/jakartaee-tck/job/standalonetck-certification/

Additional instructions and guidance for using and directly running TCKs is available on this wiki. Also in the jakartaee-tck project repository.

Add rupport for ** role to represent any authenticated user

Add support to the Policy configuration and enforcement contracts (of both Servlet and EJB) to support the use of ** is Policy Configuration and Policy Enforcement (is[User/Caller]InRole("**") to return true if the {User/caller] is authenticated (and false otherwise)

Update EFSL for Specifications and Javadoc

Per the discussions on the Spec Committee and Platform Dev mailing lists, it's been discovered that many of the Javadoc and Spec references to the EFSL need updating. Please reference the following required updates and keep them in mind as your Spec Project is updating the files for Jakarta EE 9.

Note: Some Spec Projects have already started or even completed these updates. If so, just kindly return/close this Issue. Thanks!

Required EFSL updates for Javadoc

For javadoc, the EFSL.html located in src/main/javadoc/doc-files should be modified as follows:

the <<url to this license>> needs to be replaced with efsl.php link[1]
the [title and URI of the Eclipse Foundation specification document] needs to be replaced with the Specification Name and URL (Reference [2] for an example.)
The javadoc footer copyright year needs to be updated to 2018, 2020 as defined in the pom.xml

Required EFSL updates for Specifications

For specification, the license-efsl.adoc located in src/main/asciidoc should be modified as follows:

Update copyright year to 2018, 2020 from 2019. Add link to EFSL.
the <<url to this license>> needs to be replaced with efsl.php link[1]
the [title and URI of the Eclipse Foundation specification document] needs to be replaced with the Specification Name and URL (Reference [2] for an example.)

[1] https://www.eclipse.org/legal/efsl.php
[2] https://jakarta.ee/specifications/enterprise-beans/4.0/

Policy Context Handler property keys do not appear to have been Jakarta'ized in spec.

These are the few that I have seen, but there may be others:

javax.security.auth.Subject.container
- Perhaps does not need to change since javax.security.auth.Subject is JavaSE class
- See 4.6.1.1. Container Subject Policy Context Handler
javax.ejb.EnterpriseBean
- See 4.6.1.4. EnterpriseBean Policy Context Handler
jakarta.ejb.arguments
- Already changed
javax.xml.soap.SOAPMessage
- Removed from Java SE 11, assume new package will be jakarta.*
- See 4.6.1.2. SOAPMessage Policy Context Handler
javax.servlet.http.HttpServletRequest
- See 4.6.1.3. HttpServletRequest Policy Context Handler

Change Maven coordinates

All current API libraries shipped must be distributed to Maven Central under a sub-package of the jakarta groupId. Before the first release Maven coordinates of this project must be changed as it's described here.

URLPatternSpec.setURLPatternArray invalidates two prefix patterns that have a common prefix

If two patterns in the URL pattern array are of the prefix type (/blablabla/*) and are of the form:
/pattern/* and /patternblablabla/*, PatternSpec throws IllegalArgumentException indicating a prefix pattern in pattern list:
https://github.com/eclipse-ee4j/jacc/blob/master/api/src/main/java/javax/security/jacc/URLPatternSpec.java#L307

Design and implement replacement for Policy

The java.security.Policy class is currently deprecated for removal as part of https://openjdk.java.net/jeps/411 that deprecates the entire security manager.

Jakarta Authorization uses Policy as an entry into its authorization modules; meaning the container calls methods on Policy in order to interact with these. As Policy is going to be removed, this has a big impact on this API.

The best course of action is likely to create a replacement class for Policy containing exactly the methods a container would normally call. These are essentially the implies method and the "getPermissions" method.

Remove usage and references to SecurityManager

As per the Jakarta EE 11 plan all usage of the SecurityManager should be removed.

Convert "Eclipse Project for JACC" into a specification project

In order to prepare this project to engage in specification work, we need to convert it into a specification project as defined by the Eclipse Foundation Specification Process (EFSP). As part of this work, we will change the project name and the scope.

We'll use this issue to capture the work that needs to be done as part of this effort.

Resolve #25
Resolve #24
Successful complete a restructuring review
Designate the project as a specification project of the Jakarta EE Working Group
Change project name

Start a Release Review

Passing Release Review is a required step before making a first public release. Deadline for passing the review is Nov 30th, 2018. Release review takes some time to complete, so it makes sense initiating it as soon as possible.

Start Release Review
Update Release Review Tracker

Additional information:

Build CI/CD pipeline

This task is for creating a basic build CI/CD pipeline for this project on Eclipse infrastructure. More information is here: https://ci.eclipse.org/.

Release pipeline and first release

We need to create a release CI/CD pipeline for this project and release the first version from Eclipse.

Use these documents as a reference:

Add generic to PolicyContext.getContext

jakarta.security.jacc.PolicyContext.getContext(String) returns type Object, which is thereafter always casted. We can simply this by introducing a generic return type here:

public static Object getContext(String key) throws PolicyContextException {

to

public static <T> T getContext(String key) throws PolicyContextException {

Release API to OSSRH staging repository

Uptake new Eclipse versions of dependencies (if any). Use GlassFish 5.1 Release Tracker wiki to find components versions to use.
Release to OSSRH staging repository
Update GlassFish 5.1 Release Tracker with released version number.

Rename project to authorization

The name of this GitHub project should be "authorization", i.e. https://github.com/eclipse-ee4j/jacc should become https://github.com/eclipse-ee4j/authorization

Need draft PR for EE10

Hello, the deadline for individual component specifications to create a draft PR in the https://github.com/jakartaee/specifications project with candidate final API and specification is Feb 28. There does not need to be a complete PR with a compatible implementation. All that is required is to have the final candidate API staged, and to have a PR that include the candidate final specification. If your project cannot meet this deadline, it is possible it will miss the EE10 release train. Let the platform dev team([email protected]) or the EE10 release coordinator ([email protected]) when you will be able to create the PR, or if the EE10 platform should release with the previous version.

Complete the Release of Authorization 2.0

These are the remaining steps as per the spec-committee guide for the project team to complete to finalise the release of Authorization 2.0:

Promote api staging release (the specification api jars) to maven central. An example release job script can be found here https://wiki.eclipse.org/MavenReleaseScript.
Go through the merged jakarta.ee specification website page to verify all the links are valid.
Approve the compatibility request.
The compatible implementation project/vendor MUST send an email to [email protected] for approval of the compatible implementation for trademark usage.
Merge any final release branch as appropriate for the branch management for the project.

Add tests for new 2.1 features to TCK

The TCK sub-tree for Jakarta Authorization tests is located here:

https://github.com/eclipse-ee4j/jakartaee-tck/tree/master/src/com/sun/ts/tests/jacc

New features:

https://github.com/jakartaee/authorization/issues?q=is%3Aissue+is%3Aclosed+milestone%3A2.1

Features used in practice by an impl:

https://github.com/eclipse-ee4j/exousia/blob/2.1.0-M1/impl/src/main/java/org/glassfish/exousia/modules/def/DefaultPolicy.java#L55

Ignore me

Compatibility certification request for Exousia 2.1.0-M1

TCK Challenge: com.sun.ts.tests.jacc.provider.TSPolicy performs getPolicyConfiguration() without subsequent pc.commit()

Challenged Tests:
The tests implicitly added in jakartaee/platform-tck#939, which because they were added into Authorization provider code, result in the following 14 failures:
[javatest.batch] FAILED........com/sun/ts/tests/jacc/ejb/mr/Client.java#ADM_InRole_from_ejblitesecuredjsp
[javatest.batch] FAILED........com/sun/ts/tests/jacc/ejb/mr/Client.java#EjbIsAuthz_from_ejblitesecuredjsp
[javatest.batch] FAILED........com/sun/ts/tests/jacc/ejb/mr/Client.java#EjbNotAuthz_from_ejblitesecuredjsp
[javatest.batch] FAILED........com/sun/ts/tests/jacc/ejb/mr/Client.java#EjbSecRoleRef_from_ejblitesecuredjsp
[javatest.batch] FAILED........com/sun/ts/tests/jacc/ejb/mr/Client.java#excludeTest_from_ejblitesecuredjsp
[javatest.batch] FAILED........com/sun/ts/tests/jacc/ejb/mr/Client.java#InterMediateBean_CallerPrincipal_from_ejblitesecuredjsp
[javatest.batch] FAILED........com/sun/ts/tests/jacc/ejb/mr/Client.java#MGR_InRole_from_ejblitesecuredjsp
[javatest.batch] FAILED........com/sun/ts/tests/jacc/ejb/mr/Client.java#TargetBean_CallerPrincipal_from_ejblitesecuredjsp
[javatest.batch] FAILED........com/sun/ts/tests/jacc/ejb/mr/Client.java#uncheckedTest_from_ejblitesecuredjsp
[javatest.batch] FAILED........com/sun/ts/tests/jacc/web/containerContracts/Client.java#IsUserInRole
[javatest.batch] FAILED........com/sun/ts/tests/jacc/web/containerContracts/Client.java#WebUserDataPermission
[javatest.batch] FAILED........com/sun/ts/tests/jacc/web/principal2role/Client.java#PrincipalToRoleMapping
[javatest.batch] FAILED........com/sun/ts/tests/jacc/web/providerContracts/Client.java#PermissionsToRole
[javatest.batch] FAILED........com/sun/ts/tests/jacc/web/providerContracts/Client.java#WildCardAuthConstraint

Test Source: com.sun.ts.tests.jacc.provider.TSPolicy

TCK Version:
Jakarta Platform 10.0.0

Tested Implementation:
Open Liberty

Description:
The new testing added in EE 10 to cover the API's new getPolicyConfiguration() methods has some unintended side effects.

Per section 3.1.1.1 of the Authorization 2.1 specification, "A policy context in the inService state must be transitioned to the open state when it is returned as a result of a call to getPolicyConfiguration."

However, per section 4.9 of the Authorization 2.1 specification "a Policy provider must return that a tested permission has not been granted if ... the inService method of the PolicyConfigurationFactory associated with the provider would return false." In other words, the policy has to be in the inService state in order to actually test a permission.

Unfortunately, the new testing added these getPolicyConfiguration() calls (setting the state to open) immediately prior to running the pre-existing logic to test the permissions. This can't possibly work because the policy will never be in the necessary inService state, and all checks will be rejected. Section 3.1.1.1 states that "a policy context is transitioned to the inService state by calling the commit method, and only a policy context in the open state may be transitioned to the inService state," so this could be easily fixed by adding a call to commit the PolicyConfiguration prior to continuing with the permissions testing.

PolicyConfigurationFactory needs getPolicyConfiguration without open requirement

The current version of getPolicyConfiguration requires the returned policy to be in the open state. This is useful for when the PolicyConfiguration is being written to, but not useful when a Policy needs the PolicyConfiguration to read the permissions from.

Proposal is to add a method to get a PolicyConfiguration without a state transition and without an option to clean it automatically, e.g:

public PolicyConfiguration getPolicyConfiguration(String contextID);

vs the existing:

public PolicyConfiguration getPolicyConfiguration(String contextID, boolean remove) throws PolicyContextException

Of course, for this to make really sense the PolicyConfiguration needs to be extended with methods that allow reading of the stored permission. For this see #52

Prepare Jakarta Authorization for Jakarta EE 8 Release

Instructions

Update text files
Generate "boilerplate" specification project
Make a staging release
Generate Stand-alone TCK test results
Create a PR to jakartaee/specifications repository
Update the Jakarta EE API jar by submitting a PR to the jakartaee-api project

See here for detailed instructions.

Update Eclipse GlassFish

Update Eclipse GlassFish to use the new version of your API (and implementation, if applicable) by submitting a PR to GlassFish.

Although a new version of GlassFish will not be released for Jakarta EE 8, we hope to release an update sometime later.

Design and implement replacement for PolicyContext

PolicyContext inherently depends on checkSecurityPermission to satisfy the requirement of configuration security:

The Application server must bundle or install the PolicyContext class, and the containers of the application server
must prevent the methods of the PolicyContext class from being called from calling contexts that are not authorized
to call these methods. With the exception of the getContextID and GetHandlerKeys methods, containers must restrict
and afford access to the methods of the PolicyContext class to calling contexts trusted by the container to perform
container access decisions. The PolicyContext class may satisfy this requirement (on behalf of its container) by
rejecting calls made from an AccessControlContext that has not been granted the "setPolicy" SecurityPermission, and
by ensuring that Policy providers used to perform container access decisions are granted the "setPolicy" permission.

Given it's a final class container don't have much means of satisfying this requirement. We therefore need to decouple the security decision from the class, or separate the API based on its security requirements. We might need to combine some of these approaches:

ServiceLoader-backed implementation instead of final class

Similar to MicroProfile Config, or Rest's RuntimeDelegate, the application server should be responsible to provide implementation of PolicyContext via service loader, where it can implement necessary security/context checks for modification methods.

Separation of contracts

The API of the class could be reduced to only support unprotected methods (getContextId, getHandlerKeys) and other means defined for interacting with the context, that would be passed from trusted context to related classes. Though such API change could be quite disruptive.

Security Best Practices

Hi,

I’m a member of the Eclipse Foundation Security Team. I’ve analyzed this repository with Scorecard and StepSecurity to check if it was applying some supply chain security best practices.

The following issue(s) has(ve) been detected:

Properly use a dependency update tool, like Dependabot

As a result, you will see some PRs coming both from me and/or the StepSecurity bot to provide fixes for those issues. This issue will serve as the parent for those PRs.

Thanks!

Kind Regards,
Francisco Perez

Finalize Jakarta Authorization 2.1

Please complete these steps to finalize the release:

promotes api staging release promotes the specification api jars to maven central. An example release job script can be found here https://wiki.eclipse.org/MavenReleaseScript.
go through the merged jakarta.ee specification website page to verify all the links are valid.
if XML Schemas are published on https://jakarta.ee/schemas, send a PR to update the status from Draft to Final.
approve the compatibility request.
The compatible implementation project/vendor MUST send an email to [email protected] for approval of the compatible implementation for trademark usage.
merge any final release branch as appropriate for the branch management for the project.

Place holder issue for Pull Request 5

This is a place holder issue for Pull request from javaee/jacc-spec#5

Place holder issue for Pull Request 4

This is a place holder issue for Pull request from javaee/jacc-spec#4

Method URLPattern.getPatternDepth always returns 1 and does not throw on //

As shown in #92, in the method
https://github.com/eclipse-ee4j/authorization/blob/6d88b79d72142139716c954aca2d8a0ecbc68784/api/src/main/java/jakarta/security/jacc/URLPattern.java#L181-L200

local variable depth is never modified,
with that, condition at line 191 is always false and IAEx is not thrown and:
https://github.com/eclipse-ee4j/authorization/blob/7925d26a9988f8d2d7893ce57e8a462c643b3cfc/api/src/test/java/jakarta/security/jacc/URLPatternTest.java#L50 passes,
with above this method always returns value of 1, after wasting time in while loop 😞 (and the remaining tests pass).

I might be wrong in my assessment, but for me there is bug there.

Register a policy provider programmatically per application

Current a policy provider can only be added at the system/jvm level. This doesn't play well with cloud deployments, and for those use cases with the authorization rules are application specific.

Add a method to register a policy provider with the PolicyConfigurationFactory, so that this policy provider can be used for a single application.

Change project name to Jakarta Authorization

Background information:
https://waynebeaton.wordpress.com/2019/04/04/renaming-java-ee-specifications-for-jakarta-ee/

Checklist:

GitHub
README file
CONTRIBUTING file
Eclipse Project under https://projects.eclipse.org/projects/ee4j

Compatibility certification request for EE4J implementation of Jakarta Authorization 2.0

Update CONTRIBUTING.md for Specification Project's repositories

Create/Update CONTRIBUTING files

Per input from the Eclipse EMO, each Specification Project needs to ensure that a CONTRIBUTING.md or CONTRIBUTING.adoc file exists in each specification-related repository maintained by Specification Projects.
In addition, the CONTRIBUTING.md or CONTRIBUTING.adoc file needs to include the following text:

## Eclipse Development Process

This Eclipse Foundation open project is governed by the Eclipse Foundation
Development Process and operates under the terms of the Eclipse IP Policy.

The Jakarta EE Specification Committee has adopted the Jakarta EE Specification
Process (JESP) in accordance with the Eclipse Foundation Specification Process
v1.2 (EFSP) to ensure that the specification process is complied with by all
Jakarta EE specification projects.

* https://eclipse.org/projects/dev_process
* https://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf
* https://jakarta.ee/about/jesp/
* https://www.eclipse.org/legal/efsp_non_assert.php

Please do this at your earliest convenience.
Thank you!

-- EE4J PMC ([email protected])

Do we need the parent?

The Parent POM

 <groupId>org.eclipse.ee4j.jacc</groupId>
    <artifactId>jacc-parent</artifactId>
    <version>2.0.0-SNAPSHOT</version>
    <packaging>pom</packaging>

isn't used by either Spec or API, so is it of use anywhere?

Additional context
Jakarta EE Specification Process
Eclipse Project Handbook
Eclipse Release Record for Jakarta EE 9

ToDo

jakartaee / authorization Goto Github PK

authorization's People

Contributors

Stargazers

Watchers

Forkers

authorization's Issues

Instructions

ServiceLoader-backed implementation instead of final class

Separation of contracts

Recommend Projects

Recommend Topics

Recommend Org