|
Re: doubt about the web.xml
>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
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 MemberGitHub: https://github.com/Daniel-Dos Linkedin: http://br.linkedin.com/in/danieldiassantosTwitter: http://twitter.com/danieldiasjava Em qua, 29 de ago de 2018 às 11:31, Guillermo González de Agüero <z06.guillermo@...> escreveu:
Hi Daniel,
|
|
|
|
Re: doubt about the web.xml
Guillermo González de Agüero
Hi Daniel,
toggle quoted messageShow quoted text
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ó:
|
|
|
|
Re: doubt about the web.xml
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 MemberGitHub: https://github.com/Daniel-Dos Linkedin: http://br.linkedin.com/in/danieldiassantosTwitter: http://twitter.com/danieldiasjava Em qua, 29 de ago de 2018 às 02:14, Rudy De Busscher <rdebusscher@...> escreveu:
Hi Daniel,
|
|
|
|
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
Hello people,
I have a question regarding web.xml.
Is it mandatory to use?
I have seen some examples that use it and others do not. in https://github.com/eclipse-ee4j/soteria/tree/master/test , https://github.com/javaee-samples/javaee8-samples/tree/master/security and https://github.com/javaee-samples/jakartaee8-samples/tree/master/soteria
|
|
|
|
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, -- 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
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!
toggle quoted messageShow quoted text
El mié., 21 feb. 2018 20:10, Will Hopkins <will.hopkins@...> escribió:
|
|
|
|
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
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
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
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.
toggle quoted messageShow quoted text
Werner Keil wrote on 02/14/18 10:23 AM:
All,
|
|
|
|
Re: Dependency Bug in Soteria 1.0
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
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
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
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
|
|
|