Topics

Java EE Security.Next


Arjan Tijms
 

Hi,

Without an EG being active and with the EE transfer in progress so that there's being little chance of starting an EG now or before long, I wonder what the best way forward is at this moment for JSR 375.

Working with the spec I noticed a couple of (small) inconveniences myself:

* We forgot to include annotation literal instances/builders such as done by CDI 2.0: http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#built_in_annotation_literals
* We forgot to spec and make the SecurityContext bean @Named, making it more difficult to use on JSF views than it should be
* Java EE Security 1.0 being Java EE 7 dependent doesn't take advantage of the CDI interception factory, making it more difficult than it should be to apply @RememberMe to the build-in mechanisms; http://arjan-tijms.omnifaces.org/2017/08/dynamically-adding-interceptor-to-build.html

I'd like to work towards a small release (a MR?) to address these and perhaps a small number of other issues that came up after release and/or were already identified before.

A number of options to consider:

* Do an MR release - these are typically low overhead and can be done without too much process, but will Oracle sponsor that at this time?
* Wait for everything to be transferred to EE4J - could take a year or more
* Incubate something within MicroProfile - can we actually incubate a next version there, or only do add-on stuff? I think the latter
* Create a branch in Soteria and API, incubate proposed features there like Weld did for Weld 3 - Problem, Will still has the JSR 375 API project closed
* Create an open source fork of Soteria, incubate proposed features there - may be quite confusing to users
* Create an open source add-on project (like OmniFaces for JSF) - already discussed this with Rudy before, but can not change API classes
* Something else?

Thoughts?

Kind regards,
Arjan Tijms


reza_rahman <reza_rahman@...>
 

Obviously an MR is the best route if Oracle has the appetite. If not I suggest an RI specific extension. The last resort could be a fork.

Sent from my iPhone

On Nov 26, 2017, at 12:33 PM, Arjan Tijms <arjan.tijms@...> wrote:

Hi,

Without an EG being active and with the EE transfer in progress so that there's being little chance of starting an EG now or before long, I wonder what the best way forward is at this moment for JSR 375.

Working with the spec I noticed a couple of (small) inconveniences myself:

* We forgot to include annotation literal instances/builders such as done by CDI 2.0: http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#built_in_annotation_literals
* We forgot to spec and make the SecurityContext bean @Named, making it more difficult to use on JSF views than it should be
* Java EE Security 1.0 being Java EE 7 dependent doesn't take advantage of the CDI interception factory, making it more difficult than it should be to apply @RememberMe to the build-in mechanisms; http://arjan-tijms.omnifaces.org/2017/08/dynamically-adding-interceptor-to-build.html

I'd like to work towards a small release (a MR?) to address these and perhaps a small number of other issues that came up after release and/or were already identified before.

A number of options to consider:

* Do an MR release - these are typically low overhead and can be done without too much process, but will Oracle sponsor that at this time?
* Wait for everything to be transferred to EE4J - could take a year or more
* Incubate something within MicroProfile - can we actually incubate a next version there, or only do add-on stuff? I think the latter
* Create a branch in Soteria and API, incubate proposed features there like Weld did for Weld 3 - Problem, Will still has the JSR 375 API project closed
* Create an open source fork of Soteria, incubate proposed features there - may be quite confusing to users
* Create an open source add-on project (like OmniFaces for JSF) - already discussed this with Rudy before, but can not change API classes
* Something else?

Thoughts?

Kind regards,
Arjan Tijms


Guillermo González de Agüero
 

Just thinking out loud... Perhaps Will could open for us an API branch and non official snapshots of development work could be used by servers?

Work would be done when the time for an MR arrives (or the donation is finished).


Regards,

Guillermo González de Agüero

El dom., 26 nov. 2017 18:33, Arjan Tijms <arjan.tijms@...> escribió:
Hi,

Without an EG being active and with the EE transfer in progress so that there's being little chance of starting an EG now or before long, I wonder what the best way forward is at this moment for JSR 375.

Working with the spec I noticed a couple of (small) inconveniences myself:

* We forgot to include annotation literal instances/builders such as done by CDI 2.0: http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#built_in_annotation_literals
* We forgot to spec and make the SecurityContext bean @Named, making it more difficult to use on JSF views than it should be
* Java EE Security 1.0 being Java EE 7 dependent doesn't take advantage of the CDI interception factory, making it more difficult than it should be to apply @RememberMe to the build-in mechanisms; http://arjan-tijms.omnifaces.org/2017/08/dynamically-adding-interceptor-to-build.html

I'd like to work towards a small release (a MR?) to address these and perhaps a small number of other issues that came up after release and/or were already identified before.

A number of options to consider:

* Do an MR release - these are typically low overhead and can be done without too much process, but will Oracle sponsor that at this time?
* Wait for everything to be transferred to EE4J - could take a year or more
* Incubate something within MicroProfile - can we actually incubate a next version there, or only do add-on stuff? I think the latter
* Create a branch in Soteria and API, incubate proposed features there like Weld did for Weld 3 - Problem, Will still has the JSR 375 API project closed
* Create an open source fork of Soteria, incubate proposed features there - may be quite confusing to users
* Create an open source add-on project (like OmniFaces for JSF) - already discussed this with Rudy before, but can not change API classes
* Something else?

Thoughts?

Kind regards,
Arjan Tijms


Rudy De Busscher
 

If possible, an MR is the best option.

But we can already start experimenting with additional + proposed features outside JCP and EE4J (I don't think Microprofile is a good place for it), and even play with some new API.

That way, we are prepared and can go faster/further at the moment we can start with our work within the Eclipse Fdn.

I already created some add-ons for handling Tokens (JWT and (Google) OAuth2). See (1) and (2)

regards
Rudy


On 26 November 2017 at 19:57, Guillermo González de Agüero <z06.guillermo@...> wrote:
Just thinking out loud... Perhaps Will could open for us an API branch and non official snapshots of development work could be used by servers?

Work would be done when the time for an MR arrives (or the donation is finished).


Regards,

Guillermo González de Agüero

El dom., 26 nov. 2017 18:33, Arjan Tijms <arjan.tijms@...> escribió:
Hi,

Without an EG being active and with the EE transfer in progress so that there's being little chance of starting an EG now or before long, I wonder what the best way forward is at this moment for JSR 375.

Working with the spec I noticed a couple of (small) inconveniences myself:

* We forgot to include annotation literal instances/builders such as done by CDI 2.0: http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#built_in_annotation_literals
* We forgot to spec and make the SecurityContext bean @Named, making it more difficult to use on JSF views than it should be
* Java EE Security 1.0 being Java EE 7 dependent doesn't take advantage of the CDI interception factory, making it more difficult than it should be to apply @RememberMe to the build-in mechanisms; http://arjan-tijms.omnifaces.org/2017/08/dynamically-adding-interceptor-to-build.html

I'd like to work towards a small release (a MR?) to address these and perhaps a small number of other issues that came up after release and/or were already identified before.

A number of options to consider:

* Do an MR release - these are typically low overhead and can be done without too much process, but will Oracle sponsor that at this time?
* Wait for everything to be transferred to EE4J - could take a year or more
* Incubate something within MicroProfile - can we actually incubate a next version there, or only do add-on stuff? I think the latter
* Create a branch in Soteria and API, incubate proposed features there like Weld did for Weld 3 - Problem, Will still has the JSR 375 API project closed
* Create an open source fork of Soteria, incubate proposed features there - may be quite confusing to users
* Create an open source add-on project (like OmniFaces for JSF) - already discussed this with Rudy before, but can not change API classes
* Something else?

Thoughts?

Kind regards,
Arjan Tijms



Arjan Tijms
 

On Sun, Nov 26, 2017 at 11:23 am, Rudy De Busscher wrote:
But we can already start experimenting with additional + proposed features outside JCP and EE4J (I don't think Microprofile is a good place for it), and even play with some new API.
Indeed, so wondering what the best place for such shared experimenting could be. Maybe a branch such as Guillermo mentioned, or now that I think of it, a fork (as-in, a GitHub fork) for doing experiments in, and then from there do PRs back if/when possible.

Kind regards,
Arjan Tijms


Arjan Tijms
 

p.s.

I checked the githib/javaee repos, and the branches still seem to be open to be created.

So for the mentioned experimental next API, shall I create two branches in https://github.com/javaee/security-soteria and https://github.com/javaee/security-api or shall I fork both to a new org that's open to all previous committers?


Rudy De Busscher
 

I think a 'fork' to a new organization is safer. It indicates better that is an initiative of some of the EG members and associate members (or anyone else who wants to drive this forward)

On 26 November 2017 at 20:50, Arjan Tijms <arjan.tijms@...> wrote:
p.s.

I checked the githib/javaee repos, and the branches still seem to be open to be created.

So for the mentioned experimental next API, shall I create two branches in https://github.com/javaee/security-soteria and https://github.com/javaee/security-api or shall I fork both to a new org that's open to all previous committers?



Guillermo González de Agüero
 

We should definitely wait for Will/Oracle input beforr creating a new branch for thid on the official repo. But if they are ok with that, I prefer it over the external organization.


El dom., 26 nov. 2017 20:50, Arjan Tijms <arjan.tijms@...> escribió:
p.s.

I checked the githib/javaee repos, and the branches still seem to be open to be created.

So for the mentioned experimental next API, shall I create two branches in https://github.com/javaee/security-soteria and https://github.com/javaee/security-api or shall I fork both to a new org that's open to all previous committers?


Werner Keil
 

Now that several existing JSRs like 374 started with proposals to EE4J, I wonder what keeps this JSR from doing the same?
Obvious bugs or smaller improvements without introducing whole new API elements are usually natural for MRs, and based on what we heard, Oracle and other vendors should upgrade their Java EE products to use Java EE 8, so they will use 375 and Soteria in all relevant  profiles (Full and Web according to http://www.oracle.com/technetwork/java/javaee/tech/index.html) so if say SAP Cloud (https://blogs.sap.com/2017/07/27/sap-cloud-platform-is-java-ee-7-web-profile-certified/ seems using mostly TomEE 7) wants to certify against Java EE 8 then we should see either TomEE or even SAP utilize JSR 375 via its Identity Management for the Cloud to do so ;-)
Same for other Java EE 7 compatible vendors who wish to upgrade. It is possible one or the other might skip it and aim directly at EE4J but there is no definitive answer as to whether it'll offer a similar compatibility assurance or certification. 

So for important fixes or problems there should be at least one or the other MR of JSR 375, but similar to what other JSRs did, it should be very easy to fork/contribute a project to EE4J, too.
Ed who's been in charge of many things here already is one of the project leads for JSON Processing: https://projects.eclipse.org/proposals/eclipse-json-processing
So he is at Eclipse/EE4J, Ivar another EG member who also spread the word about JSR 375 is currently the PMC Chair, David also another EG member represents Tomitribe in the PMC. So does Arjan's company Payara. It should be easy to find additional contributors and project leads, if the model of sharing it among 2-3 contributing members is also found appropriate for this project. Given Arjan's contribution to 375 so far, he seems like a good candidate to do this for Payara. Almost every current EG member(company) is involved in either EE4J, MicroProfile or other Eclipse projects and committer already. Others at least signed the ECA which is what current contributors would need to contribute in this new environment. 

Regards,
Werner


Werner Keil
 

Yes, nobody should bother creating another Java EE Security API organization on GitHub again ;-)
Some JSRs have already been contributed, a few others are pending, but already mentioned. Mostly those that already have an Eclipse RI like EclipseLink.
It's odd, Security has not been mentioned, but people at Oracle like Dmitry, Ed or Will if he's involved can only do some of these at a time. The whole of Glassfish is not yet migrated and it may take longer due to a larger code base. 375 is relatively new, but dependencies like JASPIC could be a little more complex than e.g. JSON-P with zero external dependencies. 
While JSF was contributed, Servlet itself wasn't, so it's not the only EE 8 relevant JSR that has not been touched yet.

Werner