Date   

Re: doubt about the web.xml

Arjan Tijms
 

>The @RolesAllowed annotation is not defined by JSR 375 and there was sadly not enough time to better integrate with it or provide a better alternative.

Indeed, we should really address this for JSR 375.Next

>For now, @RolesAllowed are only portable on EJB components, although some servers such as Payara support them on any CDI bean AFAIK. 

We have a duo solution in place. @RolesAllowed is by default supported on any JAX-RS resource, and is "http facing", means that if the user is not authenticated it triggers the configured authentication mechanism.

For business beans we have an annotation in the Payara API called RolesPermitted (https://github.com/payara/Payara/blob/master/api/payara-api/src/main/java/fish/payara/cdi/auth/roles/RolesPermitted.java#L64) That one is backed by a regular CDI interceptor.

For JSR 375.Next we should probably have a combination of these two.

Kind regards,
Arjan


Re: doubt about the web.xml

Daniel Dias
 

Hi Guillermo, 

Thanks for the explanation, I think I got a little better understanding of how it works.
--
Daniel Dias dos Santos
Java Developer
SouJava & JCP Member
Linkedin: http://br.linkedin.com/in/danieldiassantos


Em qua, 29 de ago de 2018 às 11:31, Guillermo González de Agüero <z06.guillermo@...> escreveu:

Hi Daniel,

The @RolesAllowed annotation is not defined by JSR 375 and there was sadly not enough time to better integrate with it or provide a better alternative.

For now, @RolesAllowed are only portable on EJB components, although some servers such as Payara support them on any CDI bean AFAIK. The simpler way to use it is to annotate your resources @Stateless, or creating an interceptor and a CDI extension to tranform @RolesAllowed into an interceptor binding annotation.

Creating such extensions was greatly simplified on CDI 2.0.

El mié., 29 ago. 2018 16:12, Daniel Dias <daniel.dias.analistati@...> escribió:
Hello, Rudy, 

was what I choosed, but when I use with Jax-RS the same does not work.

was what I thought of, but when I use it with Jax-RS it will not work when I remove the web.xml and add the annotation @RolesAllowed ({USER, ADMIN}) as shown in this section:


--
Daniel Dias dos Santos
Java Developer
SouJava & JCP Member
Linkedin: http://br.linkedin.com/in/danieldiassantos


Em qua, 29 de ago de 2018 às 02:14, Rudy De Busscher <rdebusscher@...> escreveu:
Hi Daniel,

web.xml is optional. The Java EE Security API spec didn't change that.

You can define for example the roles and security constraints for URLs within the web.xml, but also with annotations within code.

Regards
Rudy


Re: doubt about the web.xml

Guillermo González de Agüero
 

Hi Daniel,

The @RolesAllowed annotation is not defined by JSR 375 and there was sadly not enough time to better integrate with it or provide a better alternative.

For now, @RolesAllowed are only portable on EJB components, although some servers such as Payara support them on any CDI bean AFAIK. The simpler way to use it is to annotate your resources @Stateless, or creating an interceptor and a CDI extension to tranform @RolesAllowed into an interceptor binding annotation.

Creating such extensions was greatly simplified on CDI 2.0.

El mié., 29 ago. 2018 16:12, Daniel Dias <daniel.dias.analistati@...> escribió:
Hello, Rudy, 

was what I choosed, but when I use with Jax-RS the same does not work.

was what I thought of, but when I use it with Jax-RS it will not work when I remove the web.xml and add the annotation @RolesAllowed ({USER, ADMIN}) as shown in this section:


--
Daniel Dias dos Santos
Java Developer
SouJava & JCP Member
Linkedin: http://br.linkedin.com/in/danieldiassantos


Em qua, 29 de ago de 2018 às 02:14, Rudy De Busscher <rdebusscher@...> escreveu:
Hi Daniel,

web.xml is optional. The Java EE Security API spec didn't change that.

You can define for example the roles and security constraints for URLs within the web.xml, but also with annotations within code.

Regards
Rudy


Re: doubt about the web.xml

Daniel Dias
 

Hello, Rudy, 

was what I choosed, but when I use with Jax-RS the same does not work.

was what I thought of, but when I use it with Jax-RS it will not work when I remove the web.xml and add the annotation @RolesAllowed ({USER, ADMIN}) as shown in this section:


--
Daniel Dias dos Santos
Java Developer
SouJava & JCP Member
Linkedin: http://br.linkedin.com/in/danieldiassantos


Em qua, 29 de ago de 2018 às 02:14, Rudy De Busscher <rdebusscher@...> escreveu:

Hi Daniel,

web.xml is optional. The Java EE Security API spec didn't change that.

You can define for example the roles and security constraints for URLs within the web.xml, but also with annotations within code.

Regards
Rudy


Re: doubt about the web.xml

Rudy De Busscher
 

Hi Daniel,

web.xml is optional. The Java EE Security API spec didn't change that.

You can define for example the roles and security constraints for URLs within the web.xml, but also with annotations within code.

Regards
Rudy


doubt about the web.xml

Daniel Dias
 

Hello people,
 
I have a question regarding web.xml.
 
Is it mandatory to use?
 


New mailing list: es-dev@eclipse.org

Guillermo González de Agüero
 

Hi,

Justs heads up that we already have a new mailing list at Eclipse: es-dev@...

This list has 41 subscribers while the new one has only 7! Please subscribe there and if you are an Eclipse Commiter for that project, don't forget to list yourself as subscribed on https://github.com/eclipse-ee4j/security-api/issues/81


Regards,

Guillermo González de Agüero


Re: Remove Liberty Support from Soteria Testing for Eclipse Move

Will Hopkins
 

Thanks, all.

On 02/21/2018 02:44 PM, Arjan Tijms wrote:
Hi,

It's an easy change to swap the test dependency from Closed- to Open Liberty. I incidentally just did the same the other day here: 

https://github.com/javaee-samples/microprofile1.2-samples/commit/a0abc87826f465e5a03202b175dd0afbbf13b790

But as removing is always easier I'd say go for it.

Kind regards,
Arjan

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803


Re: Remove Liberty Support from Soteria Testing for Eclipse Move

Arjan Tijms
 

Hi,

It's an easy change to swap the test dependency from Closed- to Open Liberty. I incidentally just did the same the other day here: 

https://github.com/javaee-samples/microprofile1.2-samples/commit/a0abc87826f465e5a03202b175dd0afbbf13b790

But as removing is always easier I'd say go for it.

Kind regards,
Arjan


Re: Remove Liberty Support from Soteria Testing for Eclipse Move

Guillermo González de Agüero
 

Seems reasonable!


El mié., 21 feb. 2018 20:10, Will Hopkins <will.hopkins@...> escribió:
Hi All,

The Soteria project depends (for testing purposes) on IBM's commercial version of Liberty. This is a problem for the Eclipse migration, as Eclipse won't accept contributions not governed by an open source license.

Oracle proposes to simply remove this dependency, to expedite the migration, on the theory that testing based on OpenLiberty can be added back, if needed, once the project is moved over to Eclipse.

Any objections?

Thanks,

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803


Remove Liberty Support from Soteria Testing for Eclipse Move

Will Hopkins
 

Hi All,

The Soteria project depends (for testing purposes) on IBM's commercial version of Liberty. This is a problem for the Eclipse migration, as Eclipse won't accept contributions not governed by an open source license.

Oracle proposes to simply remove this dependency, to expedite the migration, on the theory that testing based on OpenLiberty can be added back, if needed, once the project is moved over to Eclipse.

Any objections?

Thanks,

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803


Re: Dependency Bug in Soteria 1.0

Werner Keil
 

That is good to know, thanks.

Will try it probably on Monday when I get to that demo for security I have to do.

Werner


Re: Dependency Bug in Soteria 1.0

Rudy De Busscher
 

Werner,

Workaround from Arjan works, I have used it already some months ago for a demo. Works for any Java EE 7 server which doesn't contain Soteria already.

Rudy



On 14 February 2018 at 21:06, Werner Keil <werner.keil@...> wrote:
If the hints for build-time by Arjan work (deployment in Payara 4 build 174 or above should be fine) I guess that'll do for the client I'm helping with security and identity management right now. For many others that also cannot use a snapshot repo a patch within a few weeks would be good.



Re: Dependency Bug in Soteria 1.0

Werner Keil
 

If the hints for build-time by Arjan work (deployment in Payara 4 build 174 or above should be fine) I guess that'll do for the client I'm helping with security and identity management right now. For many others that also cannot use a snapshot repo a patch within a few weeks would be good.


Re: Dependency Bug in Soteria 1.0

Werner Keil
 


Will try those in the POM of the dev environment tomorrow. Would be great if it works to show them Soteria in the security PoC, 
but nevertheless it would be as great if Oracle or someone else could release a patch. Like it was done for the JSON-P RI at least once before that moved to EE4J.


Re: Dependency Bug in Soteria 1.0

Bill Shannon
 

The project proposal for Soteria should be submitted to the Eclipse Foundation this week.  Then it takes a few weeks for Eclipse to vote on and approve the proposal.  Then the repository and issues need to be migrated.  Then the build infrastructure needs to be set up.  My guess is that it will probably be 4 - 6 weeks before a bug fix can be published from the Eclipse project.  No changes are being made to the existing Java EE Soteria project while this work is in progress.

Werner Keil wrote on 02/14/18 10:23 AM:

All,

I just found a very bad bug in Soteria 1.0 as it's out there in MavenCentral since August 2017 ;-/
I can't even set labels like "bug" but it is clearly a major bug and showstopper from using Soteria unless you run Maven/Gradle etc. in a public web or cloud where Snapshot repositories are available:
https://github.com/javaee/security-soteria/issues/206

When I switch the Java EE dependency to Java EE 8, it seems to work, but the container I'm supposed to use is not Java EE 8 compatible yet nor do any productive Java EE containers out there support EE 8. At most you get betas like Payara 5. 

Without such fix I may be able to abandon Soteria in the actual PoC for now and stick to APIs in JAX-RS with similar functionality (like SecurityContext) 
Hope this can be fixed in the org.glassfish.soteria groupId rather than having to wait for the new EE4J project to release something eventually?

Regards,
Werner


Re: Dependency Bug in Soteria 1.0

Arjan Tijms
 

Payara 174 has Soteria as well. The war only has to depend on the API, not on Soteria itself. The 1.0 API is available from Maven central:

<dependency>
    <groupId>javax.security.enterprise</groupId>
    <artifactId>javax.security.enterprise-api</artifactId>
    <version>1.0</version>
    <scope>provided</scope>
</dependency>

Alternatively, I think it should work with any other server if you depend on Soteria indeed, but exclude the API from it. See:

https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html

Then include the 1.0 API dependency.

Something like:

<!-- API -->
<dependency>
    <groupId>javax.security.enterprise</groupId>
    <artifactId>javax.security.enterprise-api</artifactId>
    <version>1.0</version>
</dependency>

<!-- Impl, without Api -->
<dependency>
    <groupId>org.glassfish.soteria</groupId>
    <artifactId>javax.security.enterprise</artifactId>
    <version>1.0</version>
    <exclusions> 
        <exclusion> 
          <groupId>javax.security.enterprise</groupId>
          <artifactId>javax.security.enterprise-api</artifactId>
        </exclusion>
      </exclusions> 
</dependency>


Re: Dependency Bug in Soteria 1.0

Werner Keil
 

I know but the client currently only uses Payara 174 at most, and the WAR still must be built against a valid Maven repo, no snapshots allowed there.
If Payara has public (Final) Maven JARs I could use here instead, that might work.


Re: Dependency Bug in Soteria 1.0

Arjan Tijms
 

On Wed, Feb 14, 2018 at 10:23 am, Werner Keil wrote:
When I switch the Java EE dependency to Java EE 8, it seems to work, but the container I'm supposed to use is not Java EE 8 compatible yet nor do any productive Java EE containers out there support EE 8. At most you get betas like Payara 5. 
One other option is Payara 4.181, which includes Soteria and is fully supported, as well as publicly available.


Dependency Bug in Soteria 1.0

Werner Keil
 

All,

I just found a very bad bug in Soteria 1.0 as it's out there in MavenCentral since August 2017 ;-/
I can't even set labels like "bug" but it is clearly a major bug and showstopper from using Soteria unless you run Maven/Gradle etc. in a public web or cloud where Snapshot repositories are available:
https://github.com/javaee/security-soteria/issues/206

When I switch the Java EE dependency to Java EE 8, it seems to work, but the container I'm supposed to use is not Java EE 8 compatible yet nor do any productive Java EE containers out there support EE 8. At most you get betas like Payara 5. 

Without such fix I may be able to abandon Soteria in the actual PoC for now and stick to APIs in JAX-RS with similar functionality (like SecurityContext) 
Hope this can be fixed in the org.glassfish.soteria groupId rather than having to wait for the new EE4J project to release something eventually?

Regards,
Werner

1 - 20 of 736